基于微服务架构的运营商CRM 系统升级方案*

刘沛强，黄巧洁

（1.华为技术有限公司，广东 广州 510627；2.广州梦海信息技术有限公司，广东 广州 510665；3.广东农工商职业技术学院，广东 广州 510507）

0 引言

移动通信业务经过这些年的高速发展，已经非常成熟。客户关系管理（Customer Relationship Management，CRM）系统作为运营商的业务运营系统，曾经为移动业务的高速发展作出了巨大贡献。一方面，由于4G 和5G 技术的全面普及以及智能终端的快速发展，人们获取和应用信息越来越便利，成本也越来越低；另一方面，近十年来互联网高速发展，而电信运营商由于升级转型缓慢，在信息应用方面难以与互联网厂商竞争。随着移动用户数量逐年趋于饱和，依靠扩大用户数量实现增收的方式难以维持，因此运营商不得不通过业务转型以扩大市场份额，这对CRM 已有的架构体系提出了更高的挑战。

当前CRM 系统的多项关键技术已经落后于互联网企业[1]，并且随着开户人数逐年增加，老旧的单体式系统架构早已不堪负荷，继续扩容也难以从根本上解决问题。因此，需要对运营商的CRM 系统进行数字化升级，灵活支持各种商品和营销方案，以便更好地满足人们对通信产品的多元化需求，进而继续拓展移动业务的销售增长点。综上所述，CRM 系统的升级换代能够更好地支撑运营商的转型[2]，是运营商分享移动互联网发展红利重要的一环。

本文首先提出CRM 系统升级改造的目标，其次以需求为驱动分析升级涉及到的关键技术，再次通过升级前后的架构对比在理论上分析新架构的优势，最后通过实际的压力测试数据验证了新架构下的系统对旧系统的比较优势。

1 CRM 系统升级改造的目标

CRM 系统的升级改造，通过以下6 个方面解决运营层面的困难。

（1）建设系统总线和服务集成：解决随意访问外部服务的问题，系统对外和对内提供统一标准协议的接口，为电商等第三方提供良好的交互能力。

（2）去中心化：将单体服务重构为微服务，拆分为客户、订单、系统管理和商品管理等几个微服务，并通过集群部署以加强系统的动态扩展能力，增加系统的弹性和健壮性。

（3）采用分布式数据库架构重构数据库访问：使用元数据对库表进行管理，以增强数据治理能力，同时使用读写分离、延迟写和分库技术，提升数据库访问效率。

（4）商品模型重构：将运营商能提供的服务能力抽象为产品，在此基础上增加价格、优惠、使用周期和营销方案等并打包成商品，为用户提供多种商品选择。

（5）增强系统管理能力：使系统能够灵活调整用户的角色和权限，并具备强大的商品管理能力和订单追踪能力。

（6）界面设计互联网化：采用简洁的设计，提升用户体验。

2 架构升级的关键技术

新的CRM 系统采用分布式系统总线、微服务集群、分布式数据库、重构商品模型、系统管理、服务调用链及界面互联网化等多种关键技术，达成上述目标。

2.1 分布式系统总线和统一的对外接口标准

分布式系统总线用于CRM 内部不同模块之间的互相通信。各个模块通过总线注册和发布服务，同样地，也通过总线发现和调用其他模块的服务。分布式总线系统，不管从稳定性，还是易扩展性都远优于集成总线。

统一的对外接口标准，是指限制系统内的服务随意调用外部接口。不管调用外部接口和外部调用本系统接口，都集成在同一模块内，便于集中管理。

2.2 微服务集群

微服务集群，是指将传统的单体服务改造为微服务并进行集群部署。具体地，将服务通过Zookeeper 注册到系统总线上，通过Zookeeper 强大的服务管理能力，对各服务进行负载的均衡动态调解。在微服务治理架构下，通过部署多个服务和反向代理，不仅能实现动态扩展，而且能大大提高服务的可靠性，从而当一个服务出现故障或者拥塞时，负载均衡会自动把新的请求指派到其他可用的服务。以用户到营业厅进行一次商品订购业务为例，完整的服务调用时序如图1 所示。

图1 商品订购服务调用时序

2.3 分布式数据库设计

分布式数据库是指每个微服务都只能访问各自的数据库，将以往的单体数据库拆分为多个数据库，这些数据库可以部署在不同的服务器上，达到缓解数据库压力的目的。当然，也可以将负载较小的数据库部署在同一台服务器上。

此外，使用Coherence 实现分布式数据库集群的协同管理，对于修改频率较低且访问频率较高的库表，通过它的内存数据库进行读写分离。当内存中某个数据发生改变时会加互斥锁进行保护，并延迟写入数据库，但读取Coherence 内存数据库时并不需要加锁，大大提高了数据库的访问效率。

2.4 重构商品数据库的设计

已有系统的数据模型对商品的支持能力比较弱，难以支撑千变万化的商品销售。本次升级改造的重点之一，就是通过重构商品数据库的设计，实现灵活的配置，支持日益多变的商品销售。

将运营商提供的各种服务定义为产品，叠加上各种附加属性和优惠折扣，打包成一个商品，商品模型见图2。对于同一个产品（如手机），使用不同的属性（如最低消费、折扣、捆绑周期等），就可以成为不同的商品，以满足不同的客户群体。商品表数据模型见图3。属性需要预先定义，并配置到特定的产品下。用户可以通过前台的选择框和输入框，将属性进行不同数值的实例化，存入到用户的商品订购关系表和属性表中。

图2 商品模型

图3 商品表数据模型

2.5 强大的系统管理能力

系统管理不仅能实现菜单、操作员、角色和权限等常规操作，还能实现强大的商品管理能力、缓存管理能力、服务调用链追踪能力。商品管理可以配置商品的基本信息和扩展属性。数据字典、商品配置、角色和权限等是读取频率很高但修改频率很低的信息，非常适合使用缓存数据库进行读写分离。系统管理可以提供上述信息的缓存查询、刷新和同步能力。

2.6 服务调用链

传统的单体服务，在生产环境上运行时只产生少量日志，对定位极为不便。采用服务调用链之后，可以很方便地展示每次操作调用了哪些服务。当出现故障时，能够清晰地分析故障的传递路径，进而分析故障控制点。如图4 所示，通过对服务调用的大数据统计分析[3]，了解用户的操作行为轨迹，分析用户的潜在需求[4]，以便有针对性地对商品进行推荐。

图4 大数据下的服务调用链

2.7 界面互联网化设计

界面互联网化设计是指改变CRM 朴素的传统界面，尽可能减少界面元素，人机交互采用极简的设计，简化用户操作。按钮采用醒目的大图标，便于用户聚焦。对用户输入使用拦截器进行实时校验，对于错误的输入采用流行的冒泡提示进行温馨提示。部署静态缓存服务器，对静态的js,html,css 等静态资源文件优先加载展示到客户端，既能改善用户体验，又能缓解高并发访问的压力，只有对动态数据才访问后台服务器。

3 升级前后的CRM 架构对比

3.1 已有的CRM 架构

已有的CRM 架构如图5 所示。客户端（CRM前台、移动商城、电子渠道、App、第三方等）通过Nginx 负载均衡访问CRM 后台，后者通过数据管理层（DataBase Management，DM）访问同一个数据库。这样的架构，虽然可以通过增加后台服务器的部署数量来增加系统容量，但单体服务中系统内部各模块之间耦合度很高，调用繁杂。更为严重的是，在这种架构中所有后台都集中访问同一个数据库，给数据库造成了极大的压力，在许多时间段几乎是满负荷运行，在某些情况下甚至需要进行限流，这给运维工作带来了极大的挑战。

图5 旧的CRM 架构

CRM 中存在较多业务模块，如产品管理、订单管理和客户管理等。这些模块都存在一个单体服务中，各业务互相耦合，导致开发效率较低，且容易造成风险。这时只要有一个接口发生阻塞，就很容易造成雪崩效应，导致整个服务瘫痪。

此外，单体服务要求提供极端稳定的服务，对服务器的可靠性和性能要求极高，因此通常采用价格相对较高的国际商业机器公司（International Business Machines Corporation，IBM）的小型机+易安信（EMC）的高端存储。

3.2 新架构带来的优势

新的架构如图6 所示。在新的架构中，CRM划分为客户管理、订单管理、家庭管理、集团管理、商品管理和系统管理等多个微服务模块。

图6 新的CRM 架构

每个模块可以将对外提供的多个服务注册到Zookeeper，由后者对服务进行管理，并提供服务发现功能。模块内是高内聚的服务，模块之间通过服务调用减少耦合，每个模块都有各自的前端和后端的微服务，可以独立发布，并且当某个微服务出现问题时自动下线，此时负载均衡将请求动态分配到其他微服务。由于所有服务均为无状态服务，因此即使是同一个会话的处于不同的操作步骤，也可以访问不同的微服务，这就带来一个好处：当某些微服务访问量激增时，可以通过增加这些微服务的数量，达到弹性扩展的目的。

由于每个微服务都有自己的数据库，因此数据库可以进行分布式部署，减轻了数据库集中访问的负载。

由于每个微服务独立部署，因此每个微服务的负载相比单体服务要减少很多，从而对硬件的要求比单体服务器要低。相对于旧架构采用的IBM 小型机，新架构采用普通X86 架构的PC Server 即可满足要求，这也符合业界当前CRM 系统的转型要求[5]。

由于使用了读写分离、延迟写和分库等技术，相比旧的系统架构，数据库访问效率大大增加。

通过在基线版本预埋扩展点的方式，在不同省份的版本中通过扩展点进行定制，以满足不同省份的定制需求。

4 新架构的层次关系

新架构主要包含接入层、业务处理层、元数据处理层、数据存储层。

4.1 接入层

接入层是面向用户访问或连接的部分。CRM的接入层包含营业前端、电子渠道、网站、客服和第三方门户等访问。接入请求通过Nginx 进行负载均衡，根据各个微服务的在线流量和Zookeeper 注册的服务，动态调节需要访问的后台逻辑服务。

4.2 业务处理层

业务处理层主要接收并处理来自接入层的请求，它包括商品管理、客户管理、订单管理、系统管理等多个微服务。微服务发布到Zookeeper 后，由后者分配到特定的微服务进行处理。

4.3 元数据处理层

元数据处理层主要管理微服务各个库表的数据，对数据单元进行查询、插入、修改、删除操作。以元数据取代已有架构的DM 层，使用统一的元数据进行管理。在绝大多数情况下，业务层不必关心数据处理单元的具体实现，同时也避免了对原有的库表进行各种交叉访问的情况。只有在少数复杂场景下，才需要进行不同库表的联合查询。

4.4 数据存储层

数据存储层主要是接收元数据的访问并进行处理，使用Oracle 进行数据存储。此外，由于每个微服务使用不同的数据库，因此使用Coherence 进行分布式数据库管理，并对高并发且修改频率较低的数据库（如商品库）采用读写分离和延迟写技术。如图7所示，利用读写分离技术，当访问为读操作时，直接访问Coherence 的内存数据库；当访问为写操作时，先写入Coherence 的内存库，再定时集中写入Oracle 数据库，可大大提高数据库的读写效率。

图7 数据存储层的读写分离

用1 000 000 笔主要业务分别对新旧架构进行压力测试，结果如表1 和表2 所示。其中：第2 列的平均处理时长指标是单笔业务调用该模块的微服务消耗的平均时间；第3 列的内存占用指标是每间隔10 s 抽样每个模块的微服务运行时占用的内存大小的均值。从表1 和表2 中可见，即使模块之间的微服务调用有一定的时间开销，但由于数据库采用了读写分离，且采用了分布式架构，平均每笔业务的办理时间，仍然从旧架构的2.33 s 减少到新架构的2.15 s，性能提升9%。由于微服务可以按照调用频繁程度灵活调整部署，对订单管理、商品订购和开户销户等业务量大的模块和单体服务部署数量相同，减少商品管理、系统管理、客户管理等调用频率较低的模块部署，在集群部署的情况下，可以比单体服务节约一定的内存。当然，实际运用时比较复杂，还需要为每个进程设置最大和最小的内存。

表1 旧架构测试结果

表2 新架构测试结果

5 结语

综上所述，由于当前运营商主要承担基础管道提供商的角色，系统难以支撑灵活的商品和应用，面临着增产难增收的困境。通过对老旧的CRM 系统进行重新升级，新的CRM 架构支持运营商使用更加灵活多变的商品销售策略。此外，使用微服务架构，不仅提高了CRM 系统的扩展性和健壮性，也降低了系统部署和维护的成本，有效支撑运营商进行数字化转型。