江苏公司第三代支撑系统CRM云化实践经验.docx

江苏公司第三代支撑系统CRM云化实践经验构建组件库，采用灰度割接策略，保障系统平滑过渡1. 项目背景4G时代，加速中国移动由语音业务向数据业务全面转型，围绕互联网化业务模式的需求日益旺盛，在此大背景下，江苏公司面临全新的业务及技术挑战。为应对移动互联网蓬勃发展、4G时代流量经营、云计算和大数据的转型挑战，江苏公司第三代业务支撑系统围绕系统X86云化改造、多中心解耦、软件组件库建设、技术架构全面升级，提升系统并发处理能力与快速响应市场能力，实现系统低成本高效率运行，保障江苏移动在4G时代的业务、技术先进性与市场竞争力，支撑4G时代的业务创新与转型、强化线上线下渠道融合能力、强化互联网商业模式和互联网营销模式的支撑能力，提升客户体验与业务运营能力。江苏公司作为集团公司首批试点省，于2014年初启动第三代业务支撑系统项目的规划、建设工作。根据公司总体要求，项目采取“技术和业务双驱动、架构云化、多中心解耦、平滑过渡”的建设原则，逐步实现CRM系统向互联网云化架构演进。2. 现状分析江苏公司虽然在2014年上半年前已完成CRM系统WEB层100%X86云化改造，但是应用层和数据库仍然以小型机为主要基础设施，扩容成本高，建设周期长，水平扩展困难。现有的传统架构制约了公司互联网转型业务的发展，以江苏公司世界杯期间抢红包为例，瞬时业务并发量增长2000%，导致接口堵塞，业务订购失败。另外，我省虽然CRM和BOSS系统完全解耦，但是CRM系统内部各模块之间的耦合性仍然很高，无法支持按照模块轻量改造发布上线。我省的架构，采用点对点集成为主，服务共享不足，接口复用性不足，支撑效率较低。为此，我省积极参与集团公司第三代CRM云化试点项目，进行系统X86云化架构改造，建立一套松耦合、高并发、低成本，快速响应市场需求的轻量化支撑系统。在CRM系统云化改造和割接过程中，项目团队遇到诸多困难和挑战。江苏公司CRM系统经过多年的建设和沉淀，系统非常庞大、复杂，业务规则、服务缺乏统一管理，服务和接口缺乏生命周期的管理机制，系统中存在大量冗余服务和接口，给系统平滑割接提出了新的挑战。我省在第三代CRM项目试点过程中除了满足集团公司规范和试点要求外，重点围绕我省系统支撑面临的困难，制定针对性的建设和割接方案。2.1、面临的困难一：软件组件服务缺乏统一管理，复用性不足，导致系统无序增长，梳理改造复杂原CRM系统中有成千上万个服务、方法、接口、进程等软件组件，这些软件组件之间的关联关系更是错综复杂，合理有效地继承割接到第三代云化架构存在诸多问题。问题1：“核心能力”缺乏有效的掌控手段。软件组件都是业务支撑系统核心能力，没有显性化的统一管理系统，开发商和移动方人员无法了解支撑系统的软件组件全局视图。在云化架构改造割接过程中，容易出现软件组件改造遗漏或错误。问题2：软件组件复用性不足。开发商在进行需求设计和开发过程中，明明已有现成的软件组件，或者只需要对原有软件组件稍作修改（例如：增加参数）就可以复用，但是往往为了规避风险或由于不熟悉系统的软件组件，不能确定原有的软件组件使用的场景，无法评估修改原有软件组件会带来什么风险，因此，为了保险起见，又新开发一个类似软件组件。长此以往，导致支撑系统越来越庞大，越来越复杂，经初步统计，原有CRM系统中仅后台服务就有10824个。如果把原系统中冗余的软件组件继承到第三代CRM系统中，会造成云化架构系统负荷增加，项目建设周期增长，增加后续云化系统的维护难度，同时增加开发成本。 问题3：当系统出现故障时，维护人员即使定位出是某个软件组件问题，但是如何进行修复，需要召集局方和开发商负责维护、开发、设计等多名人员进行修复方案和风险的评估，花费大量人力和时间。2.2、面临的困难二：第三代CRM系统云化架构和模型与原系统发生根本性变更，而公司要求系统平滑过渡，给项目割接带来重大挑战挑战1：江苏公司的CRM系统是由华为公司建设，虽然第三代CRM系统的开发商仍然是华为公司，但是开发团队不同，原有的系统是由华为山东团队建设，第三代CRM系统是由华为南研团队建设。第三代系统采用全新的开发框架、J2EE云化架构，数据模型也重新构建，本次项目基本上将CRM系统推翻重做。而公司要求本次项目系统割接保持平滑过渡，存在较大难度。挑战2：第三代CRM系统引入了服务总线（ ESB）、流程引擎（ BPM ）、规则引擎（ BRM）、分布式服务框架（DSF）、分布式数据访问服务（DDS）、搜素引擎（VSerch）等多项关键开源技术，这些新技术的性能、效果如何，与第三代整体架构是否能够完好地匹配，都要验证。挑战3：现有产品达到16000多个，业务规则和系统处理逻辑都非常复杂，很多业务规则、业务之间的依赖和冲突关系是在程序代码中实现，梳理起来很困难，难免出现个别梳理遗漏情况。3. 解决思路和方案3.1、构建软件组件库，实现组件服务显性化管理 江苏公司利用第三代CRM项目建设的契机，通过功能原子化，形成通用功能组件库，建设一套软件组件管理系统，将业务支撑系统使用的组件、服务、方法、进程等按类别、应用场景等统一纳入系统管理，实现了图形化全景展示。并结合日常开发管理办法，制定一套标准化的管理规范，实现软件组件的显性化管理、核心能力的回收、问题快速定位和风险评估，提高软件组件的复用度。CRM系统内部，软件组件可复用，降低CRM系统的开发工作量；对于CRM外部系统，通过软件组件服务的标准化封装，提供对外围的服务能力，同时可支持对外部系统的软件组件的统一维护，实现公司级的软件组件统一管理。一期系统已梳理维护组件72个、服务726个、操作3022个，并相应梳理维护了它们之间的关联关系，为系统的后续优化和维护打下了基础。3.1.1、构建软件组件管理平台，提升软件组件的可维护性，实现软件组件标准化管理。每个组件提供相应的属性信息管理和维护功能，包含：组件的名称、入参、出参、开放渠道、组件类型、能力应用说明、场景实例等。开发、设计、需求分析和维护人员可以根据组件名称查询组件的详细信息，可以通过组件查询归属模块信息。 3.1.2、建立组件、服务、操作等之间的依赖关系，实现软件组件图形化展示。实现根据一个组件、服务或操作，图形化、地图化全景展示其涉及的影响信息，让设计、开发人员能够全面评估组件的影响范围和改造风险，提升开发效率和开发质量；维护人员能够快速定位服务故障，快速制定解决方案。在“依赖关系查询”界面，点击组件、服务或者操作名称，可以进入“依赖关系查询XX明细日志页面”，显示详细的明细日志。也可以查询到此组件、服务或者操作的上下游关联关系。这样，在日常需求开发或者故障修复时，我们就可以根据该组件、服务或者操作的使用场景、关联关系，评估、判断该组件、服务或者操作是否可以复用和修改，修改的影响范围和风险也可以快速完成评估。3.1.3、建立一套软件组件管理规范，提升组件复用度。每次新需求的设计都由评审委员会对使用的软件组件进行评审，避免重复开发相同的组件，实现组件和系统的解耦，提升开发效率，降低成本。经梳理和整合，系统后台服务由老系统的10824个简化为3748个。 3.2、 引入灰度发布策略，实现系统分地市、分业务、分用户平稳割接上线3.2.1、 进行产商品的全面梳理和精简，完成调用量较低的接口整合下线 江苏公司NGCRM系统经过5年多的运行，新增了大量的产品和接口，但是由于缺乏生命周期管理，产品和接口只增不减，导致系统中遗留很多无效、冗余的产品和接口。为了对第三代CRM系统瘦身，我省不能把原系统中所有的产品和接口全盘继承到新系统中，因此，在系统改造割接前，先对系统中的产品和接口进行全面梳理和精简。（1） 进行产商品的梳理和精简产商品化涉及到组织、流程、业务模式的变革与优化，组织保障是基础，模板化是工具和手段。公司安排市场部牵头，集团客户部、数据部、数据业务运营中心、互联网中心、地市公司等多个业务部门参与，组成业务产商品梳理小组，开展专题工作。梳理了全省超过16532个产品精简到8212个，8320个无订购量的产品在3个月内分批下线，业务小组负责对这些业务功能进行整合，对订购量少、效能差的业务功能进行精简，对8320个3个月内无订购量的产品分在分批下线，最终精简到8212个。同时对全省300个营销活动配置精简为15个营销模板。（2） 接口整合下线项目接口小组牵头，联合业务部门、电子渠道对现网系统的接口进行全面梳理。共计梳理219个平台，其中一级BOSS 56个，省内平台即增值业务平台33个，外围平台131个。梳理落地发接口共8095个，有调用量3222个，最近半年调用量为0的4873个。优先安排调用量为0的接口前后4个月分批下线，同时对涉及现网适配改造的1125个接口进行整合改造。3.2.2、 版本灰度发布，降低系统上线风险为实现关键业务或专题先小规模试用，再批量上线，使用zookeeper、nginx构建灰度管理平台，部署灰度发布环境，多维度实现灰度发布能力（用户维度、地域维度、营业员维度）。同时，在管理上成立公司级的项目保障团队，优化割接上线流程，降低割接上线风险。3.2.2.1、总体割接思路（1） 高并发热点业务、安全加固、数据分发中心、共享内存、分布式缓存、读写分离等不涉及应用架构的专题直接在原系统上改造支撑，实施周期短。（2） 涉及应用架构在新架构中支撑，风险较大，利用系统的灰度发布能力，采用分业务/分用户/分渠道/分地市上线策略。 分业务：查询缴费业务-少量简单业务-前台业务-后台管理 分用户：友好用户-2-3万个人用户-地市全量用户 分渠道：实体渠道-电渠 分地市：小地市（镇江）试点-大地市逐步推广3.2.2.2、 在技术方面，引入灰度发布策略（1） 灰度发布方案 支持按用户灰度发布灰度发布规则配置使用灰度版本的用户白名单，可以是散号，也可以是号段。例如：灰度用户号13800000009。电子渠道：那么属于灰度用户范围的用户路由到灰度环境。其他用户路由到非灰度用户。电子渠道一般是最终用户发来的消息，所以建议按用户灰度在电子渠道上使用。支持按地域灰度灰度地域，指用户的归属地如：南京、苏州为灰度区域电子渠道：未输入号码之前访问的是非灰度版本，输入号码之后，根据该用户号码查询其归属地信息，如果属于南京或者苏州，则发送到灰度环境，如果不属于南京与苏州，则发送到非灰度环境。此处的地域信息与现网数据库保存的用户归属地一致，比如查询用户归属地查到的是市级名称，则灰度发布规则配置地域信息也要配置成市级名称。支持按操作员灰度发布按操作员灰度id：0001，0002营业厅：营业员0001or0002登录后路由到灰度环境，其他营业员登录后则路由到非灰度环境。营业员0001or0002办理的所有用户均路由到灰度环境，其他营业员办理的用户则路由到非灰度环境。营业厅系统一般营业厅操作员登录的时候就需要知道是灰度环境还是非灰度环境，建议使用操作员灰度方式在营业厅场景使用。配置灰度发布规则到zookeeper配置中心，该规则可后台配置。nginx实时监控zookeeper节点并缓存灰度发布规则，解析外部请求发过来的消息，并转发到灰度版本webserver或者稳定版本的web server 。MQ、DSF、eBus等相关组件遵循优先分发原则，即逻辑Set里的服务调用和消息订阅都优先分发给逻辑Set里面的节点，形成逻辑上的Set切割。基于江苏移动本次的项目范围未包含前端nginx，主要从第三代CRM统一接口框架eBus中完成灰度请求识别及灰度标识的传递。在系统割接过程中，电子渠道通过能力开放平台接入nginx，nginx实时监控zookeeper节点并缓存灰度发布规则，根据发布规则判断是否调用灰度版本。营业前台已割接业务同样通过nginx灰度发布规则，判断是否调用灰度版本。未割接业务不走灰度版本。（2） 灰度发布总体流程n 创建灰度发布规则灰度发布规则即哪些用户是灰度用户，灰度发布规则创建时包括规则编号、关键字、规则名称、规则对应的值。如下图所示，点击创建按钮即可开始创建规则，并给出该规则所对应的值。如：whitelis13800000009n 创建灰度发布任务灰度发布任务代表了本次灰度升级，本次灰度发布任务包含哪些规则，一个灰度发布任务可以有多个灰度发布规则，灰度过程中，规则可根据具体情况进行修改。n 灰度环境部署对灰度任务中选中的灰度节点进行升级。n 业务流程验证灰度发布过程中以及所有节点都灰度升级后均需要验证相关业务是否正常处理。3.2.2.3、 在管理方面，省市联动，优化割接上线流程由于第三代CRM系统采用全新的技术架构、引入多个新的技术组件，同时数据模型也发生了变更，为了保证系统平滑过渡，我省在制定割接方案时，由公司领导挂帅，协调业务部门和地市公司充分参与，进行UAT测试、并行测试用例的制定和评审，并组织验收测试，并对上线流程进行了优化。（1） 项目组织保障：公司领导挂帅，成立跨部门、跨地市两级项目组 u 成立公司副总经理挂帅的重大联合项目组（包括信息技术中心、规划部、市场部、品管部、采购部、工程部、客服中心、集客部、数据部、财务部、各地市公司等部门），保障各部门的人力投入，共同推进第三代业务支撑系统建设。 u 第三代业务支撑系统的建设不仅仅是技术平台的升级，同时涉及业务流程与产品的梳理、优化、业务测试与验证，因此业务部门的充分参与是保障项目成功的重要基础。u 项目团队建立多级沟通和预警机制，包括项目级别的会议制度、各执行组的会议制度，并明确了不同类别的项目汇报形式。同时制定了项目组织普通预警、中度预警和紧急预警的三级预警机制，明确了风险预警通报标准、问题上升的流程，以及预警问题沟通会制度。（2） 测试环节引入UAT测试和并行测试为提高测试可靠性，江苏公司采用预备上线的应用部署主机和容灾数据库构建并行环境，针对前台受理业务，参与并行测试的营业厅通过捞取前一日生产业务受理流水，进行业务回归并与生产库比较并行测试结果；针对电子渠道采用测试号码验证，通过灰度管理平台的白名单路由机制在并行环境完成测试号码业务受理。组织市场部、集团客户部、客户服务中心等业务部门和地市公司营业员进行UAT客户验收测试，所有UAT测试用例都由业务部门和营业员编写或评审。（3） 割接流程优化，降低割接风险以往的CRM系统项目割接上线，一般采用开发版本研发测试后，版本发布到江苏移动现场测试环境测试，测试通过后，版本发布到生产环境面向某个地市或者全省开放，同时进行数据割接。这样存在较大的风险，没有经过生产环境的实际体验和验证，系统割接上线后存在问题的概率较大；一旦上线后发现系统BUG或者割接数据存在问题，影响面较广。本次项目割接对原有的流程进行了优化：（1） 在原有的流程基础上，增加了并行环境灰度测试阶段，版本发布到并行环境，由开发商、第三方测试人员针对测试号码进行测试验证。（2） 增加生产环境灰度体验阶段，在并行环境测试通过率达标后，版本发布到生产环境，割接部分真实的友好客户到生产系统，利用灰度策略，面向部分工号开放权限，由开发商、第三方测试团队、地市公司营业员共同进行验证测试。（3） 生产环境灰度体验通过后，再进行全量用户数据的割接，面向某个地市或全省营业员开放权限。4. 实施效果4.1、 软件组件库建设后，问题定位、方案、风险评估效率大幅提升（1） 江苏移动业务支撑技术人员可以实时掌握业务支撑系统的核心技术信息，部门的需求、设计、开发、维护人员提升掌控CRM支撑系统核心能力水平，局方自有人员独立定位故障、评估风险的问题占比由10%提升到50%。（2） CRM业务支撑新需求的软件组件复用率由20%提升到33%。（3） 开发工作量评审有依据，总体工作量局方评审有效核减率由9%提升到11%。（4） 问题定位时间由原来的平均30分钟以上提升到10分钟以内，风险评估平均时间由原来的6小时，提升到目前30分钟。4.2、 引入灰度发布技术后，实现系统平滑过渡（1） 系统割接平稳，未引起地市波动，大面积故障率为0。分业务功能上线，大系统小做，降低项目改造和割接规模，降低项目改造和割接风险。目前已完成高并发热点业务、安全加固、数据分发中心、共享内存、分布式缓存、读写分离等6个不涉及应用架构的专题割接上线；完成查询缴费云化全省割接上线，完成CRM交易中心、新系统框架3个版本在镇江割接上线，上线过程和上线后，共计收到灰度用户反馈的问题单142个，发生1次系统性能的严重问题。由于采用灰度发布策略，及时进行了修复，未引起批量投诉和系统预警。专题灰度用户反馈问题单数量严重问题高并发热点业务3无安全加固12无数据分发中心8无共享内存0无分布式缓存28发现1个严重性能问题，系统上线后，系统性能不仅未提升，反而大幅下降，经核查主要是Conherence参数设置错误，经调优后恢复正常。读写分离0级2无查询缴费云化24无交易中心第一版本8无交易中心第二版本26无交易中心第三版本31无总计1421（2） 共计10个专题上线，未暂停前台一次。相比较5年前镇江NGBOSS割接，营业前台暂停2天业务，本次割接上线基本未给公司造成任何波动。4.3、 产品、接口梳理和精简，提升业务发布效率（1） 全省超过16532个产品精简到8212个，8320个无订购量的产品分在3个月内分批下线。（2） 落地发接口由8095个精简到3222个，完成4873个0调用量的接口下线。5. 后续思考5.1、 拓展软件组件服务管理系统功能，提升系统透明管理能力在现有软件组件服务管