1、中国移动浙江公司2015年订单中心建设方案1目录一、现状分析二、建设目标及范围三、系统架构四、核心业务设计五、割接策略与步骤六、实施计划与资源七、遗留问题2缺乏统一订单交易流程，各渠道间订单无法协同n 目前CRM的订单管理，仅仅是业务开通的订单，而对于业务受理的部分，包括下单、支付、物流等，由各渠道系统自行控制，CRM订单中无管理和对接，从而使得各渠道存在各自的客户业务受理订单，导致完整的业务环节割裂，无法协同和复用。合约机销售、流量销售营业厅销售移动网上商城天猫商城现场支付现场提货业务开通支付物流业务开通营业厅线下完成订单管理网上商城线上管理支付物流天猫线上管理业务开通人工导入人工导入爱奇艺
2、支付爱奇艺线上管理业务开通定制接口各渠道管理CRM订单管理各渠道系统自行生成订单、支付、物流，未进行订单统一接入与管理，导致渠道间无法协同进行业务处理3前端订单受理和后端订单业务实现流程串行处理，后端处理出现问题时，导致前端业务无法受理n 容错能力差：当后端处理（如送开通、送计费等）出现超时、上线异常等问题时，导致前端业务不能提交办理；n 并发能力差：业务逻辑串行处理，单笔业务处理基本上2秒以上，当出现秒杀等业务场景时，整个系统的压力大，影响普通业务正常受理。选产品选号码填资料提交订单支付发票打印开户流程后端前端订单存储卡/号资源占用增值策划处理客户信息处理账户信息处理转实例送开通用户信息处理
3、发短信送计费同步调用，2秒以上4业务处理逻辑实现复用能力有待提高n流程复用待提高：新业务很难基于现有的业务处理流程直接复用，导致存在多套雷同流程，维护困难；n业务组合不灵活：针对越来越多的营销推广组合业务，需要定制开发支撑或异步取数批量受理。融合业务流程GSM套餐变更流程融合业务GSM套餐变更子流程宽带开户子流程转实例送开通送计费发短信普通GSM套餐变更号码占用转实例送开通送计费发短信号码占用为子流程准备订单数据转实例送开通送计费施工复制，修改4G换卡送流量补换卡操作2G流量包产品调用补换卡操作地市异步取数批量订购2G流量包产品定制ESB接口补换卡服务接口产品订购服务接口现有流程复用方式现有业
4、务组合方式组合业务实现方式一实现方式二实现方式多样化、且需定制实现5CRM架构耦合，云化层次低，持续集成困难，线性扩展差6n功能耦合：融合CRM包括个人业务、集团业务、家庭业务、账务管理、销售管理、营销资源管理、营业开通、客户管理、统一规则、到期提醒等模块，各模块代码都在一个工程里进行管理，代码庞杂。业务开发需要关注全流程实现，并熟悉业务相互之间的影响，开发风险高；编译发布时间长，持续集成困难；n部署耦合：整个融合CRM作为一个应用进行部署，对外提供所有CRM功能，无法进行有针对性升级扩容，故障隔离实现困难，且仅支持EJB协议，服务集成需要重新代码定制HTTP适配层。n数据耦合：融合CRM数据
5、统一按地市维度拆分到4个数据库中，数据拆分不够灵活，且对应用影响大。n云化层次低：现在融合CRM系统仅实现部署X86化，且0中心问题导致应用无法实现真正的线性扩展，如跨地市业务与0中心紧耦合，随着跨地市业务增大，0中心压力比其他中心大。服务总线HTTP接入层CRM APP 集群 0中心CRM APP 集群 A中心CRM APP 集群 C中心CRM APP 集群 B中心CRM APP 集群 D中心A（杭州、湖州）B（衢州、宁波、金华）C（温州、丽水、舟山）D（嘉兴、绍兴、台州）6第三代技术规范要求中心化要求三代规范订单中心概述：订单中心是面向企业业务运营及运营支撑，可对外提供标准化订单服务、且独
6、立的一组订单服务的载体。订单中心具备高内聚的特性，且和其他中心低耦合，通过协同各中心形成一个完整的业务流程，订单中心可根据企业运营的需要动态调整及演进。1.中心化：实现订单中心中心化系统部署，中心需支持横向的集群扩展。2.服务化：实现订单中心标准化服务能力提供，通过统一集中的标准化服务提供，实现系统内部多中心、跨系统、跨渠道的能力交互。关键技术要求1.业务组件化：业务组件化是指为了提高系统可用性，将功能类似或者相近的能力聚合在一起。采用开放的组件化架构一方面可以提高组件复用性，另一方面方便了灵活部署，让运营商在硬件、软件上的投资更加经济合理，同时也提高了系统的扩展性和可维护性。订单中心关键组件
7、包括订单校验组件，订单送开通组件等。2.异常标准化：订单中心的异常标准化是指将系统的异常信息代码标准和异常信息提醒标准化。3.流程处理异步化：引入消息中间件通过消息方式，实现订单处理异步化，提高订单处理效率以及用户体验。4.工作流引擎：订单中心通过引入工作流引擎，可以对订单进行以流程为模版的调度处理。5.消息中间件：订单中心可使用消息中间件为异步订单提供支撑以提高系统的可靠性。7目录一、现状分析二、建设目标及范围三、系统架构四、核心业务设计五、割接策略与步骤六、实施计划与资源七、遗留问题8建设指标系统建设容量l用户量：支持6000万用户l业务量：3000万/天非充值订单量；充值5000万/天（
8、双11订单量 300万/天；充值550万/天）订单建设接收能力l响应能力：前台下单响应时间=0.5秒l接收吞吐处理能力：非充值类订单支撑10万/分钟，充值支撑50万/分钟（双11峰值 订单1万/分钟，充值5万/分钟)，不含资料查询。订单建设处理能力l响应能力：异步下单到业务完成的处理时间=1秒，l处理能力：具备10小时处理非充值类订单3000万笔；充值类5000万笔容错指标l隔离能力：后端业务处理异常时，订单接收服务能正常运行l异常处理能力：业务处理异常时，可以根据预定义处理机制自动进行异常处理主机部署容量运行指标l（正常）双机房支撑：CPU利用率50%/小时，MEM利用率60%，WIO10%
9、l（异常）单机房支撑：CPU利用率85%/小时，MEM利用率85%，WIO85%，进行主机扩展l扩容标准：本期订单中心建设，以设计目标按现网的10倍容量评估，容量按现网3倍容量部署9目录一、现状分析二、建设目标及范围三、系统架构四、核心业务设计五、割接策略与步骤六、实施计划与资源七、遗留问题1011总体应用架构蓝图IaaSSaaSISaaS应用层热线渠道能力集成平台计算服务弹性计算网络服务存储服务网络虚拟化网络设备虚拟化分布式块存储分布式文件存储分布式对象存储PaaSTPaaSDPaaSBDPaaS关系型数据库高速关系型数据库强一致性分布式内存数据库BSaaS基础能力业务能力客户中心订单中心支
10、付中心计费账务中心酬金结算中心渠道中心产品中心账户中心资源中心稽核中心开通中心通用业务能力中心营业厅电子签章远程写卡满意度调查培训考试智能终端接入同信GIS统一短信内容管理搜索二维码业务规则处理小I机器人消息推送业务到期处理界面组件库APP自有/代理商渠道电子渠道能力开放平台开发者/运营者管理计费/结算管理能力管理能力产品管理营销中心开通中心批处理交互式数据处理强一致性数据分析强一致性数据挖掘流计算数据交换分布式内存数据库负载均衡分布式数据访问总线消息中间件分布式缓存实体服务总线应用容器流程引擎资产管理服务路由器服务总线消息总线流程集成界面集成路由数据交换模块n订单中心在2015年业务支撑系统
11、规划中地位：订单中心作为SaaS层中业务能力中心，通过PaaS、IaaS实现订单中心能力，通过SaaS层的能力集成平台实现内部模块、与其他中心、系统的能力集成。11目录一、现状分析二、建设目标及范围三、系统架构1、技术架构2、功能架构 3、数据架构4、物理架构四、核心业务设计五、割接策略与步骤六、实施计划与资源七、遗留问题12新老系统比较1、垂直拆分 不同的业务数据拆分到不同的数据库中，把订单数据、客户资料数据等数据分离 不同的业务独立部署、发布，大大提升不同的业务组件的伸缩性2、水平拆分 通过分表分库，把同份数据拆分到不同的数据库，应用通过SQL的路由到具体操作数据的数据库。3、引入消息中间
12、件解耦服务调用 两个组件在不会有直接的业务联系，在所有的层次，把过程分解为阶段，将它们异步地连接起来,提高系统的伸缩性4、将处理过程转变异步的流 提升系统快速响应的能力，这样做从根本上减少请求者所经历的响应延迟，提升用户感知度5、引入软负载配置中心 解决服务上下线的感知，具备在线扩展能力6、平行化部署 解决0中心压力大的问题，具备服务线性扩展能力服务总线HTTP接入层APP0APP1APP3APP2APP4后台进程ABCD调整流程集成消息总线服务路由器服务总线订单交易集群订单处理集群订单进程集群数据库路由层数据库集群1、拆分方式不同 老系统只对数据库按照（营业、账务、渠道资源、报表）进行了垂直
13、拆分，但应用没有按照业务能力拆分 新系统应用会按照业务能力拆分2、业务处理不同 老系统业务处理调用链为同步处理，任何环节出现异常都会导致整体业务处理失败，处理环节强耦合，前端响应慢 新系统将处理过程转变成异步处理流3、系统扩展性能力不同 老系统所有应用集群的调用链关系是死的，没有在线扩展能力 新系统通过引入软负载配置中心，调用方和被调用方关系线上通知，并且支持线上扩容4、应用部署不同 老系统逻辑上共分5中心集群(数据源不同)，由开发人员需要显式设置中心的方式路由到中心集群，同时确定数据源，现网0中心比其他中心压力大。新系统所有应用并行，由定制表字段路由策略，路由到数据源 1、数据一致性挑战2、
14、面临故障独立性的挑战3、业务并发的挑战4、异常容错区别优势挑战13数据一致性挑战可靠消息最终一致性方案的正向流程（图1）1、业务处理应用首先把消息发给消息中间件，标记消息的状态为待处理2、消息中间件收到消息后，把消息存储在消息存储中，但不投递该消息3、消息中间件返回消息处理的结果(仅是入库的结果)，结果是成功或者失败4、业务收到消息中间件返回的结果并进行处理：a)、如果收到的结果的失败，那么就放弃业务处理，结束。b)、如果收到的结果是成功，则进行业务自身的操作。5、业务操作完成，把业务操作的结果发送给消息中间件。6、消息中间件收到业务操作结果，根据结果进行处理 a)、如果业务失败、则删除消息存
15、储中的消息，结束 b)、如果业务成功，则更新消息存储中的消息状态为可发送，并且进行调度，进行消息的投递最终一致性方案的补偿流程（图2）1、消息中间件询问状态为待处理的消息对应的业务操作结果2、应用（消息发布者）检查操作结果3、应用（消息发布者）发送业务处理结果4、消息中间件更新消息状态，业务成功，消息状态设置待发送；业务失败，消息删除应用(消息分布者)业务操作消息中间件消息存储本地事务域本地事务域123456图1应用(消息分布者)业务操作消息中间件消息存储本地事务域本地事务域24图213可靠消息交互：解决消息发送一致,如果业务操作成功了，那么由这个操作产生的消息一定要发送出去，否则就丢失消息，
16、针对消息积压的情况，消息中间件需要支持动态水平扩展，且对应用（生产者/消费者）无感知。总结：1、将分布式事务分解在两个本地事务中，不存在跨资源的事务；2、提交/回滚消息有可能失败，系统会处于短暂的不一致状态；3、消息总线通过主动check操作，确认消息是否提交或回滚，实现最终一致；4、应用系统需要额外实现check回调14面临故障独立性的挑战-日志接入(1/2)订单中心需要提供应用层每个请求的完整调用链路信息，BOMC收集调用链路上每个服务的性能数据n 日志埋点1、订单中心与服务总线、流程集成、消息总线交互2、订单中心与其他业务中心交互2、订单中心环节调用n 串接方式1、全局唯一的调用链ID(
17、TraceId)：埋点逻辑为这个应用层分配一个全局唯一的调用链ID2、调用上下文对象ID(RpcId)：RpcId 用于区分同一个调用链下的多个网络调用的发生顺序和嵌套层次关系。对于应用层收到请求，生成的 RpcId 固定都是0，比如应用层刚接到请求之后的 RpcId 是0，那么它第一次调用 RPC 服务A时，会把 RpcId 改成 0.1。n 框架实现1、通过切面和代理技术，在集成框架层面进行日志记入，对业务代码无侵入2、时效性，通过日志内容消息发送，做到日志计入实时发送n 对接方式 与日志中心对接，日志格式 调用链ID、RpcId、业务关键字（用户或业务订单号）、调用方IP地址、应用IP地
18、址、主机名、应用服务名、服务类型、状态、请求大小、服务/函数、开始执行时间、结束开始时间、总耗时等信息15中国移动通信集团浙江有限公司*日期中国移动通信集团浙江有限公司*日期面临故障独立性的挑战-日志接入(2/2)消息总线其他业务中心业务规则处理业务到期处理流程集成（定义环节接口）订单交易服务服务总线1、调用2、触发交易流程业务开通物流支付确认3、执行交易流程环节订单处理进程日志中心订单中心应用层rpcid=0rpcid=0.1rpcid=0.1.1rpcid=0.1.1.1rpcid=0.1.1.2rpcid=0.1.1.3rpcid=0.1.1.44、发送消息5、消息消费发开通资源占用创建
19、资料转实例rpcid=0.1.1.2.16、执行业务处理流程rpc_id=0.1.1.2.1.1rpc_id=0.1.1.2.1.2rpc_id=0.1.1.2.1.3rpc_id=0.1.1.2.1.4rpc_id=0.1.1.2.1.1.116业务并发控制请求接收加分布式用户锁业务规则校验订单项生成请求接收加分布式用户锁业务规则校验订单项生成解分布式用户锁解分布式用户锁线程等待或直接返回订单中心异步化后将扩大并发控制时长并加深并发校验及业务规则校验的复杂度。B B客户客户已订购（实例）订购中（订单项）预存话费送手机-158档神州行新家园卡（大众卡）飞信移动数据流量标准资费短消息 来电助手来
20、电显示预存话费送手机-88档移动数据流量10元套餐X 订购（下单）校验成功校验失败 并发校验：通过添加分布式用户锁解决单用户在不同渠道下单后的并发校验。业务规则校验：当用户存在在途单（订单项）并在次下单时，业务规则校验需同时校验在途单和订购实例。互斥A A客户客户网上营业厅下单手机营业厅下单17异常处理（1/3）订单中心集成异常框架对系统内异常进行统一捕获及处理，实现异常处理逻辑与主程序业务处理逻辑分离。异常框架提供标准化的异常处理流程，包括异常定义、异常识别、异常记录、异常自动补偿处理。异常定义业务异常：不符合业务规则或业务处理逻辑的异常，由业务开发人员抛出。系统异常：系统运行过程中由于网络
21、问题或其他系统相关问题产生的异常，由开发框架抛出。流程异常：流程运行过程中抛出、影响流程正常运行的异常，由流程环节及组件开发人员抛出。异常识别异常记录异常补偿处理 业务异常系统异常流程异常异常类型(B)(S)(W)异常异常错误码(OCB10000001)异常原因(订单不存在)中心编码(OC)异常类型(B)异常编码(10000001)对异常信息进行识别，获取异常错误码（中心编码+异常类型+异常编码）及异常原因。针对无法识别的异常信息，使用通用异常定义。异常日志异常类型中心编码异常编码异常原因异常堆栈进程编码 制定标准异常记录输出格式，对异常日志进行输出。通过异常记录分析，找出系统隐含问题所在。对
22、标准日志进行告警，提升故障解决效率。异常流程处理策略异常提醒处理策略自动重试处理策略自动补偿策略xxx处理策略支持对识别后的异常配置异常自动补偿处理策略。异常框架默认提供异常流程处理、自动重试处理、异常提醒（短信、邮件）处理等补偿处理策略，同时支持自定义异常处理策略。对自动补偿处理失败后的异常，提供通知人工干预功能。18工作流引擎订单中心消息总线服务路由器流程业务服务开通中心计费帐务中心客户中心账户中心消费反馈同步调用消息发布同步调用消息消费根据规则配置获取组件并执行处理组件执行成功？监听消费结果12344同步处理结果判断异步处理结果判断记录失败工单5失败重处理策略失败重处理12输入订单执行过
23、程中，流程引擎回调通过统一的流程业务服务实现与订单中心的交互处理；流程业务服务中，根据当前环节环节及规则配置获取并执行相应组件，通过组件与其他中心交互实现具体的业务处理，如创建客户资料、发开通等，支持基于消息总线或服务路由器实现异步或同步交互；如果执行失败则先记录失败工单，包括错误原因、错误描述等信息，然后继续下一环节处理。对失败工单进行调度，根据错误原因及配置的失败重处理策略，对失败工单进行重处理否继续下一个环节6是异常处理（2/3）-重试补偿处理19异常处理（3/3）-异常流程补偿处理资源配置网络施工上门施工资源报竣用户要求撤单端口被占/不足账号有问题资源配置撤销网络施工撤销资源重配置网络
24、施工重发上门施工资源报竣网络施工重发上门施工资源报竣 当前流程当前环节异常原因异常补偿流程+分离现有流程中的异常处理分支（撤单、改单），通过异常处理机制实现，扩展业务异常处理能力，提升流程可阅读性，更加方便进行全流程跟踪；业务流程运行过程中，某环节发生某个异常时，根据异常配置匹配到异常处理流程进行业务补偿处理；当发生未定义异常时，可转入人工异常处理，实现异常人工干预20 应用无状态去0中心架构核心调整1、应用去中心化：应用侧去除设置中心，数据访问策略由应用侧设置中心的方式改成表字段设置路由策略2、状态数据集中管理：比如用户并发控制信息集中在分布式缓存中管理服务总线HTTP接入层APP0APP1
25、APP3APP2APP4ABCD现网数据访问策略1、APP为发布成EJB服务，0中心部署层面连接4中心的数据库，其他APP只能连接归属自己中心的数据库2、由接入层业务属性设置中心号的方式，路由到APP应用流程集成消息总线服务路由器服务总线订单交易集群订单处理集群订单进程集群数据库路由层数据库集群新系统数据访问策略1、去除接入层2、业务数据设置表字段路由规则，进行数据路由访问状态信息21中国移动通信集团浙江有限公司*日期22订单中心应用集成流程集成消息总线服务路由器其他业务中心业务规则处理业务到期处理订单交易服务服务总线1、调用订单创建2、触发一级流程业务开通物流支付3、执行一级流程环节5、消息
26、消费订单处理进程4、发送消息发开通资源占用创建资料转实例6、触发二级流程日志中心后台进程调度后台进程调用订单中心统一短信直接调用n订单中心与能力集成平台（服务总线、服务注册中心、流程集成平台、消息总线）交互关系；订单中心与（进程调度平台、bomc）的交互关系22能力集成平台集成-服务路由器(与其他业务中心关系)使用原则和场景1、跨层、跨域的服务调用通过ESB进行交互2、同层（中心间）服务调用通过服务路由器进行交互3、订单中心服务注册到服务总线，提供业务能力域外的服务能力4、同步调用方式说明：1、服务提供方发布服务到服务注册中心，提供给客户端调用（启动阶段）2、服务调用方订阅服务提供方提供的服务
27、（启动阶段）3、服务提供方接口变化后通过服务注册中心异步通知服务调用方（异步）4、服务调用方调用已经注册的可用服务订单中心订单服务其他业务中心服务注册模块1、注册服务4、被调用2、订阅服务3、通知4、主调用1、注册服务2、订阅服务3、通知业务规则处理业务到期处理框架（客户端）框架（服务端）其他业务中心业务规则处理框架（服务端）订单中心框架（客户端）订单服务流程集成服务总线直接调用23订单中心能力集成平台集成-消息总线订单交易服务消息总线1、发送top1消息订单处理进程2、消息top1消费(push)订单分解业务流程调度订单竣工环节1环节23、发送top2消息外围系统4、消息top2消息(pus
28、h)4、消息top2消费(pull)使用场景1、内部模块解耦：订单交易服务推送消息到消息总线2、业务流程执行：业务流程执行过程中，某些环节通过消息总线完成与其他中心的交互，如：送开通、送计费等3、状态变更通知：订单执行过程中，订单状态变更通过消息总线发布消息，供外围订阅，如报表、稽核、到期处理等订单状态变化12324*日期能力集成平台集成-流程集成流程集成流程模板流程环节系统环节人工节点自动节点判断节点会签节点并行节点开始节点结束节点子流程循环结束条件判断判断结束循环节点自定义环节施工发开通发计费物流资源占用创建资料转实例流程执行引擎Workflow流程调度Process流程调度1订单中心Pr
29、ocess流程调度2消息总线服务路由器开通中心计费帐务中心客户中心账户中心同步调用消息消费处理组件流程业务服务远程调用本地调用发布1.集中部署统一工作流平台，实现流程定义、流程集中发布管理及流程调度等能力工作流平台支持自定义环节能力，通过将通用的业务环节抽象并固化到工作流平台，基于对自定义业务环节的编排，降低流程开发门槛、屏蔽开发细节流程执行引擎支持workflow/process两类调度能力2.Process流程调度支持远程/本地部署两种方式，分别通过远程/本地调用两种方式与订单中心交互本地部署以jar包形式提供能力，与业务系统部署在一起，运行时远程获取流程模板定义，可考虑启动时将流程模板加
30、载到本地，提升性能同时也可避免单点故障远程调用应支持http、ws、ejb、remote等多种协议，建议直接集成服务路由器能力进行交互25目录一、现状分析二、建设目标及范围三、系统架构1、技术架构2、功能架构 3、数据架构4、物理架构四、核心业务设计五、割接策略与步骤六、实施计划与资源七、遗留问题26业务能力层核心能力层订单管理订单创建订单调度订单归档订单查询订单拆分订单改单订单撤单订单挂起订单恢复工单处理订单退单工单生成工单回复工单执行工单查询配置管理组件配置环节配置流程配置异常管理异常规则管理异常原因管理n订单中心主要功能包括核心能力层和业务能力层，核心能力层分为订单管理、工单管理、配置管
31、理、异常管理；业务能力层包括业务资产、环节库、业务处理组件。订单中心功能架构业务资产GSM业务开户套餐变更固网业务实物购买类群组业务增值策划订购宽带/固话拆机/移机增值业务订购终端合约裸机销售融合套餐家庭亲情网政企业务企业信息机专线集团彩铃多终端共享配件销售虚拟资源类话费业务流量业务积分业务业务资产为分类，未列举全部业务订单审核订单跟踪物流单单管理物流商业务范围管理物流单查询代收款管理物流单状态管理物流单变更物流单调度物流单状态查询物流单监控支付单单管理支付基础管理支付单查询支付单生成支付单支付支付单撤单支付单撤单处理支付单错单处理购物车管理商机管理加入删除购买数量变更下单查询商机生成商机分派
32、商机跟踪商机评估27n优化订单模型，新增物流单、支付单和订单项，通过客户、账户、产品订单项实现复杂业务组合处理，同时支持网外客户订单处理，实现业务处理能力的灵活扩展。业务订单订单项客户类订单项账户类订单项产商品类订单项订单项关系客户订单支付单物流单资源明细费用明细业务属性订单模型关键实体说明：客户订单：记录客户办理或购买商品的场景，包括渠道、时间、操作人员、客户等信息；业务订单：客户订购的业务或购买的商品；如营销案、补换卡等；物流单：业务订单关联的实物资源进行物流的信息，包括资源出库、物流对接等；支付单：针对客户订单进行支付的信息，包括支付方式、支付金额、支付有效期等信息；订单项：对业务根据客
33、户、账户、产品等维度进行分解后形成可标准化处理的数据对象。28订单项模型n业务层面通过业务分析，将原组合业务进行拆分，形成功能单一、可复用的原子业务能力，并用不同类型的业务数据实体进行承载。n数据层面对所有类型的业务数据实体进行抽象，形成稳定、可供二级流程进行处理的数据主体对象订单项；具体业务数据作为订单项的补充，以扩展表的形式进行记录。29数据分布-容量评估（1/2）30n数据评估，计算公式：按3倍部署容量计算：数据库存储为：12377(G)*3=36.2T;数据连接数为：773*3=2319 并发数，按10倍建设容量计算：数据库存储为：12377(G)*10=120T;数据连接数为：773
34、*10=7730 并发数 订单存储空间=单笔存储空间*月平均量（笔/天）*30(天）*存储时长（月）;充值存储空间=单笔存储空间*月平均量（笔/天）*30(天）*存储时长（月）;存储索引空间=(订单存储空间+充值存储空间)*0.6；存储总量=(订单存储空间+充值存储空间+存储索引空间)/(1-系统预留)*（1+用户半年增值率)安全半年数；数据库连接数=订单接收并发数+订单查询并发数+订单处理并发数据+后台进程并发数计算因子：单笔订单存储空间=订单单月容量/订单表单月业务量+新表；统计3个月现有订单数据小于3k，加上新设计的交易订单和定单模型1K,总计为4k单笔充值存储空间=1K订单月平均请求量
35、（天）=客户订单量；充值月平均请求量（天）=用户充值量订单交易（双11）忙分笔数（非充值）指标响应时要求长(ms)并发数(笔/s)忙分笔数（充值）指标响应时间(ms)并发数(笔/s)905450075643720021订单查询（双11）忙分笔数指标响应时要求长(ms)要求并发数(笔/s)10892004订单处理（双11）忙分吐量（非充值）（笔）二级流程数整体业务指标响应要求时长(ms)二级流程并行要求完成时长（ms）二级流程执行串行要求完成时长（ms）并发数(笔/s)905441000500500377后台进程（双11）连接数后台连接数系数并发数(笔/s)4770.62296数据库连接数773
36、订单存储空间单笔（kb）月平均量（笔/天）每月天数存储时长（月）空间大小（GB)4260709030133878.65充值存储空间单笔（kb）月平均量（笔/天）每月天数存储时长（月）空间大小（GB)1329108230131224.06索引空间订单存储空间充值量存储空间系数空间大小（GB)3878.651224.060.63061.63总计空间存储总量系统预留用户半年增值率安全半年数总存储要求（GB)8164.340.30.02312377.23数据分布-数据库部署（2/2）-总体描述及建议方案示意图n通过分析现网双11凌晨 充值情况，分析 账务数据库cpu使用率、active连接数情况、业务
37、吞吐量 情况，推导出现网oracle数据库最大能够承载的最大压力，同时需要引入数据库中间件31一、现状分析二、建设目标及范围三、系统架构1、技术架构2、功能架构 3、数据架构4、物理架构四、核心业务设计五、割接策略与步骤六、实施计划与资源七、遗留问题目录32订单中心订单中心融合CRM库逻辑部署图订单服务集群订单处理集群服务总线消息总线发布HTTP消费n订单中心整体划分三部分：订单服务集群：对外提供订单服务接口，包括下单、订单查询等。对接ESB，并把服务向服务路由器注册。订单处理集群：订单处理集群，负责完成整个订单执行工作。订单后台进程集群：主要处理原CRM套卡激活，到期等原进程。n数据存储层
38、新建订单中心数据库，存储订单数据，实例存储在融合CRM库。n部署方式 订单服务集群：废弃EJB层：订单服务集直接向ESB暴露HTTP服务。放弃分中心部署方式：各机器平行，部署不区分A,B,C,D和0中心。订单后台进程集群ABCD新订单库订单库服务路由器服务总线HTTP服务层APP0APP1APP3APP2APP4后台进程ABCD调整现状目标33中国移动通信集团浙江有限公司*日期中国移动通信集团浙江有限公司中国移动通信集团浙江有限公司硬件估算-容量评估n计算公式：1、订单部署服务主机订单交易主机数=并发数*能力扩展系统(3)/单进程线程数(3)/单机进程数(12)订单查询主机数=并发数*能力扩展
39、系统(3)/单进程线程数(3)/单机进程数(12)订单处理主机数=并发数*能力扩展系统(3)/单进程线程数(3)/单机进程数(12)订单交易并发数=(现网订单交易忙分吞吐量(不含批量)*指标响应时要求时长)/60/1000订单查询并发数=(现网订单中心查询忙分吞吐量*指标响应时要求时长)/60/1000订单处理主机并发数=(现网受理忙分吞吐量(不含批量)*二级流程数*二级流程并行要求完成时长+现网受理忙分吞吐量*二级流程串行要求完成时长)/60/10002、其他部署进程主机其他进程主机数=现网营业进程主机数一致*能力扩展系统(3)主机类型主机数单机处理能力（tpcc）总实例数单机进程数单进程线
40、程数现网忙分吐量（笔）指标响应要求时长(ms)并发数(笔/s)能力扩展系数建设目标并发数(笔/s)订单受理服务(非充值)7600000841239054500753225订单受理服务(充值)156000001801236437200169363订单查询服务16000001212318982006318订单处理进程326000003841239054100037731131其他进程主机24600000与现网一致主机数6660000034*日期硬件估算-布署原则机房部署机房部署1.应用服务器和数据库服务器同机房部署，尽可能减少跨机房访问，提高系统效率2.数据库存储实现异地容灾设备高可用设备高可用1
41、.服务器采用刀片设备，基于中间件的集群方式实现跨机器的cluster，部分服务器故障不影响系统应用2.DB服务器采用ORACLE-RAC双节点方式部署高可用部署高可用1.对于浏览器-WEB-服务总线-业务中心-DB 的调用，考虑到越到后端网络流量越大(如业务中心-DB流量最大，服务总线业务中心其次)，优先对后端的应用部署结构进行优化，不可优化的情况下再对上一层的应用部署结构进行优化的总体策略进行应用部署2.部署根据访问渠道的安全等级和业务量大小，划分不同的应用集群组，渠道之间互不影响，故障可以隔离3.业务中心服务器根据业务办理数据和数据库路由策略访问指定的数据库实例，避免RAC-WAIT的问题
42、4.业务中心服务器出现故障或者压力过大时，可将动态把备用服务加入集群，灵活地扩展应用处理能力35*日期36硬件估算-总体架构订单中心(42台)Array负载均衡订单中心生产数据库订单中心容灾数据库DNSDNS访问访问HAHA服务总线集群消息中间件集群流程集成集群服务总线集群消息中间件集群流程集成集群石桥机房订单交易4台主+1备CBOSS 1台+2备订单处理10台主后台进程 4台三墩机房订单交易4台主+1备CBOSS 1台+2备订单处理10台主后台进程 4台服务路由器集群三墩机房石桥机房36三墩机房高可用场景验证：订单交易集群实例故障订单交易集群石桥机房订单交易集群三墩机房石桥机房订单交易服务路
43、由器集群三墩机房石桥机房服务总线集群服务总线集群 1、服务路由器集群监听订单交易集群的健康度情况，如果订单交易集群某台实例发生故障，通知服务总线集群某实例已失效2、服务路由器跨机房集群，考虑是同城交互，允许跨机房交易3、CBOSS独立交易集群4、服务路由器在客户端对容灾的考虑4.1、客户端缓存 每次收到服务路由器的更新后客户端对数据的内存缓存，当服务路由器集群无法正常使用，即使客户端不能及时响应数据获取数据，客户端也能正常访问到订单交易集群 4.2、本地配置 数据快照能够保存的是最近几次更新的数据，数据比缓存的数据旧一些，但是会保存最近的多个版本。数据快照用于服务端出现问题并且各种原因不能使用
44、使用数据缓存时，可以从早几个版本的数据快照来进行恢复5、客户端支持多种集群调用策略 快速失败：FailfastCluster快速失败，只发起一次调用，失败立即报错，通常用于非幂等性的写操作 失败转移：FailoverCluster，失败转移，当出现失败，重试其它服务器故障124注册订阅2订阅故障通知33 故障通知37三墩机房高可用场景验证：订单处理集群实例故障订单处理集群三墩机房石桥机房三墩机房石桥机房流程集成集群流程集成集群订单交易服务服务路由集群三墩机房石桥机房流程集成服务路由集群三墩机房订单交易集群石桥机房订单处理集群石桥机房订单交易集群1.2订阅1.2 订阅1.1注册故障1.3故障通知
45、1.3 故障通知1.4调用故障2.1 注册2.1注册2.2订阅2.3 故障通知2.3故障通知2.4 调用订单处理高可用原理同订单交易集群实例故障，流程集成集群接入服务路由集群38三墩机房高可用场景验证：单进程故障与消息中间件交互后台进程订单交易集群订单处理服务三墩机房后台进程订单交易集群订单处理服务石桥机房producer集群consumer集群消息中间件集群slave-masterslavemasterslaveslavemaster三墩机房石桥机房Name Server集群故障1 注册2故障通知34消息发送2故障通知55消息消费消息消费1、每个Borker与Name Server集群中的所
46、有节点建立长连接，定期注册Topic信息到所有的Name Server2、Producer 与 Name Server 集群中的其中一个节点（随机选择）建立长连接，定期从Name Server取Topic路由信息，并向提供Topic服务的master建立长连接，且定时向Master发送心跳。Producer 完全状态，可集群部署3、Consumer与Name Server 集群中的其中一个节点（随机选择）建立长连接，且定义向Master、Slave发送心跳石桥机房39高可用场景验证：数据库实例故障和数据库容灾切换40*日期生产库数据库订单中心数据库包括生产库和容灾库，每个库包括两个RAC节点；
47、在数据库及RAC节点全部正常的情况下，由生产库的RAC1节点接收订单服务集群的请求进行数据库操作，当故障发生后：1、RAC1节点故障：RAC2通过Oracle-RAC库的Failover机制自动接管RAC1节点的请求。2、生产库故障：通过手工切换域名的方式连接到容灾库订单接收分布式集群订单处理分布式集群订单服务集群容灾库RAC1RAC2RAC1RAC2RAC1故障2、生产库故障1RAC1故障2ORACLE-RAC切换3手工切换域名方式连接容灾库三墩机房容灾机房40数据库订单中心引入数据库中间件，由数据库中间件替换Oracle的RAC节点，同时支持底层数据库的平行扩展。中间件故障：通过Failo
48、ver机制自动切换到集群内其他实例。机房故障：全部数据库访问集中到另一机房进行访问。主库故障：由数据库中间件自动发现后将路由地址切换到相应备库，同时对主库的恢复进行心跳检测。订单服务集群数据库中间件集群三墩机房订单交易分布式集群三墩机房订单处理分布式集群石桥机房订单交易分布式集群石桥机房订单处理分布式集群三墩机房数据库中间件分布式集群石桥机房数据库中间件分布式集群调用调用调用调用中间件故障三墩机房主库故障生产1主库生产2主库生产3主库生产4主库石桥机房生产1备库生产2备库生产3备库生产4备库调用调用、数据复制 机房故障高可用场景验证：数据库中间件集群和数据库容灾切换41一、现状分析二、建设目标
49、及范围三、系统架构四、核心业务设计 1、核心框架设计 2、四元模型设计 3、业务设计五、割接策略与步骤六、实施计划与资源七、遗留问题目录42设计思路（1/2）n订单中心采用微核(Microkernel)+插件(Plugin)的方式构建，抽象订单处理的核心过程，包括适配、接收、拆分、流程调度等，形成稳定的内核，在业务环节中通过开放业务接口方式，完成业务处理逻辑，满足业务扩展性处理；n业务框架（微核）：抽象业务处理过程，形成标准、稳定的系统处理框架，各业务根据框架规范实现业务开发及运行；n业务流程（插件）：将订单处理过程进行分层分级处理，按照数据范围、客户交互等维度分为交易业务、业务处理流程，各级
50、流程通过工作流平台驱动，实现业务的灵活定制交易处理流程：针对整个客户订单进行处理的过程，包括支付、物流等，实现业务可视、可追溯，自动对接自有渠道、电子渠道、互联网渠道等业务处理流程：针对订单项的业务处理过程，包括开通、转实例等，形成原子业务能力，并以业务资产形式沉淀和管理，通过对原子业务能力的复用及灵活组合，实现复杂业务的快速支撑n环节（插件）：固化业务环节，包括交易、业务处理流程各环节，封装各环节通用处理逻辑，简化业务流程开发。n组件（插件）：对环节的扩展实现，与某个具体业务相关的代码逻辑，实现各业务的灵活扩展及各业务逻辑的松耦合处理。43组件化的设计功能组件订单订单项商机购物车客户订单支付
