中国移动XX公司BOSS系统发展演进规划.ppt

中移动XX公司BOSS系统发展演进规划,2,目 录,3,XX移动BOSS系统发展现状,XX移动BOSS系统由11个子系统组成，涵盖15个业务功能域,BOSS系统业务功能域建设部署现状,BOSS系统业务发展现状,到达用户数：1321万通话用户数：820万话单量：29亿/月工单数：4040万/月主机：105台存储容量：45TB,截止到2007年10月,根据预测XX移动用户数在2008年底将达到2500万,4,BOSS系统当前发展过程中存在的主要问题,BOSS系统数据域过于集中，造成核心数据库性能压力较大，降低了系统运行的稳定性，BOSS业务连续运营的能力无法得到有力保障BOSS营帐系统的应用功能域部署缺乏合理性，单笔的OLTP类业务与后台批量处理类业务都基于同一个数据库节点来实现，造成各类业务间相互竞争系统资源，大大降低了业务处理效率，影响了系统的稳定性BOSS核心实体表数据规模过于庞大，导致基于该类实体表上的相关业务其处理效率越趋低下BOSS各子系统间的现有接口方式耦合性较强，造成“牵一发，动全身”，系统整体架构易碎,系统体系架构方面,业务功能支撑实现方面,系统运维管控能力方面,系统业务功能实现缺乏必要的灵活性，可配置化程度整体较低；业务流程、业务规则均是以程序代码的形式捆绑在业务服务中，一旦流程、规则发生变化就会导致程序代码的修改，从而造成上线的频繁，严重影响系统支撑的稳定性，同时也降低了需要响应的及时性目前BOSS产品管理的可配置化能力较低，新增产品资费的配置流程较为复杂，缺乏可管理性及可维护性；另外现有产品资费模型较偏重与计费、出帐，而对产品市场营销层面的业务支撑能力较弱现有短信营业厅、信控催缴、及工单调度等功能模块的业务处理效率不高，有待进一步优化和能力提升,当前BOSS系统缺乏运行期间的状态监控能力，当系统出现问题时很难定位故障发生的原因，同时也缺乏必要的运行日志参数来为故障的处理提供依据当前BOSS较为核心的MDB应用缺乏在线热备能力，容易导致单点故障，系统的连续运行能力不足目前BOSS应用在上线期间缺乏有效的功能回归测试手段，基本依赖QA人员的经验，容易导致功能的漏测，应用的可用性无法得到有力保障,5,目 录,6,XX移动BOSS系统07年建设项目回顾,7,XX移动BOSS系统07年建设项目回顾,8,目 录,9,XX移动BOSS系统发展演进的总体思路,系统的可持续发展,平稳的向前发展，风险最小化；保护现有投资,系统可用性,符合集团公司建设规范；满足省公司业务拓展需要；快速的需求响应能力,系统可维护性,实现基于业务层面以及细颗粒度的系统运行监控能力逐步构建BOSS系统运行管理平台，加强系统整体的可维护性、可管理性,10,XX移动BOSS发展演进的系统功能架构目标,实现营业、帐务处理的拆分；BOSS营业专注于支撑个人客户、大客户、集团客户的关系的管理、市场营销、业务受理、及渠道的管理通过拆分逐步迁移出批量处理型的业务子系统，将BOSS营业系统演进成单一的在线事务处理型的CRM系统,将拆分出的帐务处理，信控管理、帐单批扣与计费子系统共同形成融合的计费帐务功能域，主要专注于用户产品资费的计算、帐单费用的管理及信用度控制该功能域逐步演进成面向产品资费的BOSS产品运营域,构建BOSS业务统一门户，整合各渠道客户服务界面，形成风格统一的系统接入框架，规则一致的业务受理流程,构建独立部署的产品管理子系统，统一管理BOSS各类资费、产品及目录增强面向CRM的产品定购模型提升产品的可管理性及可配置性,11,XX移动BOSS系统体系架构的演进逐步引入规则引擎，实现业务逻辑规则的灵活配置,通过构建基于规则引擎的业务流程处理模式，逐步实现代码和业务流程的分离，适应快速业务开发的需要，降低代码上线的频率，增强BOSS系统运行的稳定性,12,XX移动BOSS系统体系架构的演进引入面向消息的数据通讯机制，逐步解藕BOSS各子系统间的数据交互接口,点对点(定向)方式,应用A,应用B,改造当前BOSS各子系统间的数据交互方式，引入面向消息的数据通讯机制，解藕原有系统间的紧耦合集成模式，从而全面提升BOSS系统的灵活性、松散耦合性，分散业务实时、集中处理的性能压力，增强系统运行的稳定性,考虑演进的系统,采用的消息通讯模式,13,XX移动BOSS系统体系架构的演进基于业务规则驱动、松散耦合的系统交互，逐步构件化BOSS业务服务，最终推动BOSS体系架构向SOA方向演进,实现BOSS营帐拆分，优化业务处理流程，逐步解藕系统功能模块改进提升BOSS核心业务模型，基于SID规范设计各系统间可共享的信息数据模型构件化系统功能服务，在共享信息数据模型上，以SOA架构来部署BOSS各系统应用,融合计费帐务,14,目 录,15,BOSS 体系架构演进建设措施1实施BOSS营帐系统的拆分，降低营业子系统的性能压力,三户实体域,用户订购域,帐务管理域,帐务处理域,渠道管理域,资源管理域,资金管理,帐单管理,信控管理,现有单中心营帐系统,BOSS营帐拆分的边界原则,拆分到帐务处理而不是帐务管理；而帐管中的信控、批扣应用域也将从帐务管理中拆分出去；营帐接口采用消息通讯机制，减小了系统耦合，也避免了两阶段事务,帐务处理域,信控管理,帐单销帐管理,计费帐务接口处理,帐户MDB,计费子系统,拆分后的融合计费帐务子系统,消息队列通讯,融合营业受理、帐管、大客户、集团客户和渠道管理，逐步演进为CRM系统,专注于实现复杂资费的计算、帐单的批扣及用户消费费用的控制后续逐步演进为面向产品的产品运营系统,16,实施BOSS营帐系统拆分的优势,营帐拆分的边界定位在帐务处理，而不是帐务管理，这样在拆分后的营业子系统中将保持完整的三户信息，用户各类缴费及充值业务与其他受理业务能够在同一个系统中实现，从而使面向客户服务的各类业务能够保持事务的完整性，及数据的一致性；增强了对后续新业务的支撑能力，同时也利于营业系统向CRM演进,将帐务处理、信控、及帐单销帐等后台批量处理型的应用域拆分出去，能够大大降低营业系统的性能压力，提升营业系统的业务处理效率；同时拆分后的营业系统将逐步演进为单一的在线事务处理系统，其系统运行的稳定性将得到大幅提高,拆分后形成的融合计费帐务子系统，将专注于复杂资费的计费实现，用户信用度的控制及帐单的管理，与计费系统的交互更加紧密，有利于后续产品资费模型的演进，及计费、欠费控制能力的持续提升,拆分后营业子系统与帐务计费系统间采用了面向消息的数据交互模式，从而使两个系统间的依赖趋向松散耦合，数据交互的处理效率也得到有效提升，同时也避免了两阶段事务提交问题采用消息队列交互数据，也能够将原先数据交互过程中对数据库节点的性能压力，分散到系统的应用服务器上，在这种模式下可以通过应用服务器的条带化部署来线性扩展系统间的数据交互能力，规避了数据库集成节点的瓶颈问题,营帐这种拆分方式，当用户量增加时，系统扩容的重点更多的分散到具备可伸缩性的计费、帐务中；而营业系统由于主要支撑单一的OLTP类业务，其性能压力能够得到有力的控制,17,BOSS 体系架构演进建设措施2实施BOSS业务数据的生命周期管理,BOSS业务数据生命周期管理的建设实施思路,完成BOSS营帐生产数据库的环境清理（废弃数据库对象、超出生命周期历史数据的清理）依据后续业务历史数据易于在线迁移原则，来完成关键业务实体表结构的优化调整，并改造相关服务应用梳理各类业务数据的生命周期，定义出各类业务数据在线保留周期整理完成数据库开发设计规范以及数据库日常维护流程规范,定义出各类业务历史数据的迁移方式及规则，实现历史数据自动迁移的应用控制框架基于已有的BOSS营帐数据历史库，完成生产库中业务历史数据的自动化迁移借助综合查询系统、以及营帐历史库信息，全面构建客户统一信息视图，提升系统以客户为中心的服务、营销能力,1,2,营帐数据的瘦身及大表结构的优化,建设实施历史数据的自动化迁移,18,实施BOSS业务数据的生命周期管理构建历史数据自动化迁移控制平台,梳理系统中各类业务历史数据的迁移规则，对其实现统一定义。通过定义转移数据的实体范围，转移周期、转移方式、限制条件等规则，来驱动历史数据自动迁移模块，从而实现业务历史数据的自动化转移，提高系统维护的工作效率。同时对于后续系统建设过程中新增的数据实体，也需要进行规则配置，实现其业务历史数据的转移，保证当前支撑运营的业务数据能维持在一定数据量水平及增长幅度，从而可提高系统应用的总体运行效率,业务历史数据自动化迁移管理控制平台,19,BOSS系统业务功能演进建设措施1构建统一的产品管理平台，提升BOSS产品的可管理性，增强产品对市场营销及计费出帐的业务支撑能力,构建统一产品管理平台的实施思路,将产品管理从计费中独立出来，形成单独的系统,在统一产品平台上构建以下系统功能：统一产品模型，分离计费域和定购域的产品模型统一产品目录建设完整的产品生命周期管理实现统一产品配置管理,基于产品管理平台提升以下业务支撑能力：产品的相关配置在一个界面上可以完成，提高产品的配置效率,提供模板化配置功能产品的所有属性可以在一个界面上展现，提高产品信息查询便捷性降低产品之间的耦合度产品平台对外接口多种接口，满足外部系统生产的正常调用,20,BOSS系统业务功能演进建设措施1统一产品管理平台的系统架构,21,BOSS系统业务功能演进建设措施2构建BOSS综合查询系统，集中和规范BOSS对外信息查询入口，增强系统业务数据对外提供能力,BOSS综合查询系统的建设驱动力,同一内容数据，由于其提供途径不同，存在着不符、不全等差错现象,已提供相关信息的查询，但其格式、内容不符合或不能满足需求的灵活变化,针对BOSS系统客户相关信息查询所存在的问题,同一类相关内容散落于各系统或同一系统的不同界面中,用户详单的查询效率较低，且缺乏实时性，无法满足客户个性化展现要求,22,BOSS综合查询系统功能架构及系统体系结构,综合查询系统的功能模块,综合查询系统的体系结构,23,BOSS系统业务功能演进建设措施3基于系统运行现状，针对关键应用功能域实施优化建设，补系统业务支撑能力的“短板”,24,BOSS系统运维管控能力提升的建设措施1构建BOSS业务运行监控平台，增强对BOSS核心业务运行状态的实时管控能力，提升对故障分析、定位的准确性、及时性,BOSS业务运行监控平台建设思路,通过对BOSS各核心系统所使用的OBD模块升级改造，使系统在整体架构上能够支持业务在运行期间生成各个层面的运行日志,25,BOSS业务运行监控平台建设方案应用服务监控信息生成机制,应用服务的管控能力,可以准确定位导致中间件CPU消耗很大的应用函数,可以准确定位出某个业务效率较慢的处理环节,可以准确定位出应用消耗内存较大的具体原因,26,BOSS业务运行监控平台的系统总体架构,系统管控界面展示层,管控参数配置模块,管控日志分析模块,管控日志拆分模块,系统管控日志采集模块,管控平台基础管理模块,管控日志的采集（定时、异步）,实现对BOSS核心应用主机运行状况的管控实现对BOSS核心应用服务运行状况的管控,27,BOSS系统运维管控能力提升的建设措施2建设实现MDB系统的HA，增强MDB的容灾能力,生产MDB,事务处理线程,事务处理线程,事务处理线程,热备份MDB,数据同步处理模块,数据发送队列,数据接收队列,TCP网络,REDO内存区,REDO内存区,REDO内存区,改造MDB内部的事务控制机制，为内部事务处理线程对应增加数据重处理内存区域，该区域内主要记录当前事务所操作的数据、表、位置、及操作类型,在MDB外部新增数据接收、发送队列；并在主备MDB间建立数据发送/接收通道,MDB数据同步机制,MDB的热备方式将提供半同步、异步两种类型；半同步模式，即主MDB内部的事务处理线程完成当前事务处理后，负责将其对应的REDO内存数据直接通过主备节点间的数据传送通道，发送给备MDB的外部数据接收模块；主节点发送成功后，即返回MDB客户端完成当前事务处理请求；备节点的数据接收模块在接收到REDO数据后，进行时序排序并异步的将此数据发送给备MDB，从而备MDB根据REDO数据完成与主节点的数据同步；异步模式，即主节点MDB内部的事务处理线程负责将REDO数据写到本地主机的发送队列上，后续由专门的发送进程负责将此数据传送给备节点，完成主备间的内存数据同步,28,BOSS系统运维管控能力提升的建设措施3构建BOSS应用服务启停控制平台，增强运维人员对系统服务的管理能力，加强系统操作的安全性，降低人为操作失误,启停控制指令发起层,服务启停控制指令通讯模块,服务信息查询指令通讯模块,启停状态检测指令通讯模块,启停控制平台WEB服务器,启停总控服务伺服进程,启停总控服务伺服进程,启停总控服务伺服进程,应用主机1,应用主机2,。,TCP/IP连接,建设目标通过应用启停控制平台的建设以及后台应用服务启停脚本的结构化、规范化，实现BOSS维护人员利用WEB前台界面来查询各应用主机上服务的部署情况，通过前台界面操作完成对后台应用服务的启停控制、状态检测、以及启停日志的查询关键实现方案启停控制平台建设前提是后台应用服务启停脚本进行了结构化、规范化梳理前台控制发起层与后台应用服务启停脚本之间采用进程间远程通讯方式，由部署在应用主机上的启停总控服务响应前台服务请求，进而通过服务进程内调用操作系统shell，来完成对指定应用服务启停脚本的调用，启停BOSS服务BOSS后台应用主机上，在特殊用户下部署应用启停总控服务，其类型为系统伺服进程，监听TCP某端口；每台主机只需部署一组启停总控服务在前台WEB层中实现指令发起的底层通讯模块，负责根据上层传入的目标主机名称，建立与该主机的TCP连接，并通过TCP端口向后台总控进程发送启停控制指令，以及接受后台返回的服务信息数据,应用启停控制平台建设目标及方案,29,BOSS应用服务启停控制平台建设方案前台展现控制模式,启停控制平台的前台信息展现模式,启停控制平台的前台界面结构化展现其所管理的应用主机、主机上的系统用户、以及每个用户下应用服务的部署信息针对展现信息中的系统用户、用户下应用服务组、原子应用服务，提供对应的服务启动、停止操作，以及服务启停状态检测针对某台主机某个系统用户下的服务进行启停操作时，前台界面将要求操作人员输入该系统用户的登录密码通过前台界面启停后台应用服务过程中，前台将异步的发起对启停过程日志信息的查询请求，并将日志信息显示在相应的界面中,前台展现、控制模式,30,BOSS系统运维管控能力提升的建设措施4引入YYAIGA自动化软件测试平台，提升系统测试工作效率，加强BOSS业务模块上线前的回归测试能力，减少系统运行期的软件故障,31,YYAIGA自动化软件测试平台的技术特点,灵活的自动测试框架AIGA框架提供了组件化的case开发方法，建立了灵活的case表达方式，很大程度了提高了运行脚本的复用率，节省了开发时间。易维护通过AIGA开发的自动测试系统，对组件进行了有效封装，大大降低了维护工作量。不会产生传统录制回放方法中出现的随程序变更，需要重复录制脚本的问题。业务驱动AIGA以业务为驱动，可以通过测试case数据流的配置，快速、灵活地实现不同的业务流分支的回归测试。统一的测试数据管理AIGA的测试用例、测试结果数据统一在数据库中管理，实现了测试工具无关性。可以很好的进行移植，并为用户提供了一套测试用例资产。统一的测试数据管理AIGA的测试用例、测试结果数据统一在数据库中管理，实现了测试工具无关性。可以很好的进行移植，并为用户提供了一套测试用例资产。,32,目 录,33,XX移动BOSS系统发展演进的建设步骤,08年度项目规划,09年度远期规划,BOSS营帐系统拆分,业务能力提升,管控能力提升,BOSS数据生命周期管理建设,BOSS3.0项目建设,BOSS统一产品管理平台建设,BOSS综合查询系统建设,BOSS关键应用服务优化改造,BOSS业务运行监控平台建设,BOSS应用服务启停控制平台建设,MDB HA热备能力建设,BOSS统一业务门户建设（WEB化）,BOSS后台服务构件化改造，构建SOA体系架构,NGBOSS建设,BOSS自动化测试系统建设,BOSS运维知识管理系统建设,34,谢 谢！,