第三代业务支撑系统-BOSS系统总体技术规范（云化技术要求）.doc

第三代业务支撑系统-BOSS系统总体技术规范. 总体说明驱动力随着运营商传统业务增长的逐步放缓以及互联网行业的高速发展，同时新形势下的竞争环境、业务、客户、产品和网络的变化都对业务支撑系统支持提出了更高的要求。而BOSS系统作为中国移动业务、客户、计费和账务的聚合点，是整个业务支撑系统转型的关键点之一。传统的体系架构已经很难满足数据不断增长和快速支撑业务的需求，主要体现在以下几个方面：1、从2G到3G时代，BOSS系统从批量计费发展到准实时计费，到了4G时代，随着DCC消息量的增长，实时计费、实时控制和实时提醒促使BOSS从后台支撑系统逐步参与前端的实时营销，成为实时的支撑系统，对系统处理能力提出了更高的要求。2、4G时代音视频等大流量业务快速发展、新业务模式刺激流量消费、4G终端数量增加等原因导致流量话单大幅增长，给现有系统容量带来巨大压力，系统性能产生瓶颈，传统架构已难以完全满足业务快速增长的要求。3、互联网时代，需要满足个人随时随地等多方面数字化的需求，同时支持流量，终端及实物产品、内容和数字化业务的管理及自由组合销售。以流量经营为核心，以数据业务强劲增长为契机，进一步提升4G市场的运营能力、运营效率。4、4G时代要求BOSS能力服务化，需要提供帐务管理开放能力，以拓宽中国移动的业务领域，提高在整个产业链的影响力，保持在行业的优势地位。 5、在互联网增量不增收的背景下，引入低成本的硬件和软件，支持大规模电信级的业务，在严格控制成本的同时大幅增加系统处理能力，同时保障客户感知，服务质量和运营管理水平不降低是我们面临的挑战。综上所述：在4G时代，更高的用户体验和快速增长的业务量对BOSS系统的支撑能力提出了更高的要求，旧系统已难以提供很好的支撑；所以BOSS系统需要向低成本、可弹性伸缩的BOSS云化架构进行演进。5. 系统架构5.1 业务支撑网体系架构中国移动的业务支撑网体系架构采用两级架构，即一级业务运营支撑系统、省级业务运营支撑系统两级，一级业务运营支撑系统归属于有限公司，省级业务运营支撑系统归属于省公司。中国移动的业务支撑网现阶段体系架构如下图所示：图5-1 业务运营支撑系统体系架构在业务支撑网的两级架构中，一级业务运营支撑系统具有管理、实体和枢纽功能，为有限公司进行全网业务管理和业务运营提供支撑和保障，实现全网信息的交换和管理。省级业务运营支撑系统具有管理和实体功能，为省公司进行省内业务管理和业务运营提供支撑和保障。省级业务运营支撑系统与一级业务运营支撑系统通过接口相联，实现数据交换，二者相互协作与配合，共同支撑移动业务的运营与管理。省级业务支撑网包括CRM、BOSS、宽带P-BOSS、经营分析系统、业务支撑网网管五个系统。1、 CRM系统包括市场管理、营销管理、客户服务、渠道管理、客户管理、资源管理、产品资费管理、基础管理等功能域。2、 BOSS系统包括产品资费管理、采集预处理、融合控制、融合计费、综合帐务、服务开通、综合结算、合作伙伴管理、信息管理、基础管理、局数据管理与发布等功能域。3、 宽带P-BOSS系统包括服务开通管理、服务保障、施工管理、资源管理、基础管理等功能域。4、 经营分析系统提取业务支撑网和其它系统的相关数据，建立统一的数据信息平台，并采用数据仓库技术和分析挖掘工具，为客户服务、市场营销、经营决策等工作提供有效支撑。5、 业务支撑网网管系统实现在业务支撑网生产运行过程中对主机设备、网络设备、存储设备、备份设备、数据库、中间件、应用软件等进行“集中监控、集中维护、集中管理”，提供故障处理、配置数据处理、性能监控、稽核核心应用环节的业务流程和数据以及异常告警等功能。5.2 编写目标中国移动编制NG3-BOSS(V1.0)技术规范的目标体现在以下几个层面：1、 明确BOSS系统云化目标、云化特征、云化范围和云化架构；2、 明确BOSS系统云化要求和应用示例；3、 明确BOSS系统云化关键技术能力；4、 明确BOSS系统技术要求。5.3 系统结构结合BOSS多年来的最佳实践，以及NG3-BOSS规划思想，BOSS系统结构设计遵循以下原则：1、 可复用原则：系统核心由一系列服务组成，服务又由一个或多个组件构成，组件的粒度满足高可复用性要求；2、 可扩展原则：系统结构可以按层次进行分布式部署，提高系统可扩展性，降低系统成本；3、 流程与服务分离原则：将流程与服务实现进行分离，提高系统的灵活性和快速部署能力；4、 数据平台化原则：构建统一数据访问引擎，将业务处理中的业务数据和状态数据与应用分离，实现应用的轻量化、无状态和数据的共享访问。根据以上原则，BOSS系统结构分为云应用、云平台、云设施，如下图所示：图5-2 BOSS系统结构下面分别对各层进行阐述：云应用包括接入层和业务层：接入层是BOSS系统与外部进行数据交换的平台，由接入逻辑构成。对于系统使用者，提供多样化的集成逻辑，实现对业务逻辑的共享。业务层是BOSS系统业务处理的逻辑平台，它通过统一数据访问引擎访问业务数据，实现不同的功能模块，满足不同的业务需求。业务层由若干业务流程组成，通过调用业务组件，为接入层提供业务服务，实现业务逻辑的共享，完成相应的业务功能。云平台包括分布式服务框架和分布式数据访问框架，分布式服务框架实现任务的调度和任务的监控；分布式数据访问框架是BOSS系统对业务数据进行统一组织、集中管理的平台，它通过统一数据访问引擎为业务层提供规范、高效的数据服务，实现业务数据的充分共享，是整个BOSS系统的基础。云设施包括计算资源、存储资源、网络资源，计算资源向低成本X86服务器迁移，网络资源需要具备高带宽、低时延特性，存储资源需要具备高性能、低成本、可扩展特性。5.4 功能结构BOSS功能结构如下图所示： 图5-3 BOSS系统功能结构图BOSS各功能域简要描述如下：1、 产品资费管理产品资费管理是对构成产品的服务、资费进行配置管理，以及根据服务、资费要素对产品进行定义、打包形成客户可以订购的产品或打包产品。产品资费管理包括产品的基本属性管理、资费管理和产品的服务管理。对于产品变更需要通过版本管理来进行跟踪和追溯。2、 服务开通服务开通是指按照BOSS信用控制和CRM提交的服务开通类定单的要求，实现开通工单的控制管理，并执行相应的服务开通的过程。BOSS的服务开通模块负责即开即通类业务的开通，如语音、短信、彩铃、VPMN、ADC等业务的开通。3、 采集预处理采集预处理包括综合采集和预处理。综合采集完成原始服务使用记录的采集和在线计费消息的接入。预处理屏蔽网元侧的物理差异，为BOSS其他功能域和其他系统提供标准格式的网络服务使用记录。4、 融合控制融合控制的范围涉及BOSS系统中的计费预处理、计费引擎、帐务处理、帐务管理等功能组件，通过对上述功能组件进行流程的配置、监控，实现在线计费、离线计费和月结出帐的流程调度，并实现各功能组件的负载均衡控制。5、 融合计费融合计费是依据计费资源、产品资费、用户资料信息实现个人客户、家庭客户和集团客户跨地域、跨业务等的计费过程。融合计费功能域需要具备全业务融合计费能力、在线计费与离线计费融合计费能力、计费事件提醒触发能力。6、 综合帐务综合帐务是指对综合帐单的生成、管理及核算的过程，包括：帐务管理、帐务处理、信用管理、积分管理、BOSS服务管理（BSM）、消费提醒管理。7、 信息管理信息管理是对BOSS系统在计费、帐务、结算等处理中所依赖的三户信息、订购信息、局数据、产品资费信息和帐单的共享存储管理。信息管理将上述数据集中统一管理，供BOSS内部融合计费、综合帐务、综合结算等相关功能域使用。8、 综合结算综合结算是中国移动与其他通信运营商、合作伙伴之间以及中国移动内部根据结算规则完成收入分摊、核对、调整和监管的过程。结算规则、核对方式以及公司内部管理要求等内容来自结算双方合作协议或合同。9、 合作伙伴管理合作伙伴管理包括合作伙伴资质管理、合作伙伴信息管理、合作伙伴业务管理、合作伙伴考核管理、合作伙伴服务、合作伙伴信息审核发布。通过合作伙伴管理，规范与合作伙伴的合作模式，可以整合与合作伙伴的业务流程，提高与合作伙伴的合作效率。10、 基础管理基础功能是系统提供的一组公用功能，包括系统管理、CAPES指标体系管理、数据一致性管理、业务局数据、计费帐务稽核和统计报表等功能。11、 局数据管理与发布局数据管理与发布包括全网业务局数据发布、省级业务局数据发布、局数据监控告警管理、局数据查询、局数据一致性管理、统一开通指令等功能，规范局数据的发布与管理流程，提升局数据的一致性和准确性，实现局数据发布的同步监控和统一开通功能。6. 云化要求6.1 概述建设第三代支撑网BOSS系统，以实现云计算架构为目标，通过应用云化、平台云化、基础设施云化和云运维等能力的提升，实现业务支撑系统向云化架构演进。其中应用云化主要实现应用与数据分离、高可用、负载均衡和弹性伸缩；平台云化包含分布式服务框架和分布式数据访问框架；基础设施云化遵循计算资源集群化和X86化、存储资源分布式部署、网络资源高带宽低时延；云运维平台是保障系统高效、稳定和健康运行的管理平台，提供监控管理、发布管理、故障管理、探针管理和配置管理等能力。6.1.1 云化目标为了支撑4G业务与流量经营新计费模式，提升客户实时计费体验并解决由此带来的DCC消息爆发式增长问题，满足产业链对计费能力开放的要求，第三代支撑网省级BOSS云化的主要目标是：1、增强系统扩展能力。2、降低系统扩容成本。3、缩短新业务开发周期。4、开放BOSS服务能力。5、提升系统运维效率。本期BOSS云化要求实现系统X86化及弹性伸缩，实现数据平台化及数据分布式部署，实现BOSS能力开放，以持续提升移动互联网时代BOSS业务支撑能力。6.1.2 云化特征6.1.2.1 数据平台化 数据平台化是指通过应用架构和数据架构的重新梳理、规划与调整，构建统一数据访问引擎，封装应用访问数据接口，将业务处理中的业务数据和状态数据与应用分离，实现应用的轻量化、无状态和数据的共享访问。应用与数据分离是BOSS云化的前提和基础。6.1.2.2 系统弹性伸缩系统弹性伸缩是通过强化集群部署和管理能力，实现系统快速扩容、处理能力线性扩展、故障自动隔离。当系统负载增长到达承载阀值时，可以快速加入服务器进行负载均衡。当集群中某个机器不可用时，系统自动将该机器上承载的业务分发到其他正常机器承载。6.1.2.3 数据分布式部署数据分布式部署实现数据的高效低成本扩展。通过分片化数据存储方式减少单节点数据访问的压力，提升数据高可用性，同时通过灵活的路由分配机制降低数据访问的复杂性。6.1.2.4 系统X86化 通过系统X86集群化部署，实现低成本支撑，并且缩短项目建设周期。BOSS系统以云化架构为指导思路，将系统逐步向X86化演进，最终目标是应用和数据均支持X86化部署。6.1.2.5 帐务管理能力开放通过帐务管理能力开放，对外提供统一的接入和管理能力，实现数据访问的一致性和完整性，增强对外开放能力，提升系统互联网化能力，提升客户体验。对外提供统一的数据和能力服务。6.1.3 云化功能架构BOSS云化功能架构如下图所示：图6-1 BOSS云化功能架构BOSS云化功能架构包括云应用、云平台、云设施和云运维平台，简要描述如下：1、云应用：是指BOSS系统中的经过云计算架构改造后的应用，具备云化特征，实现与数据分离和无状态化，应用通过统一的数据访问引擎访问数据。主要包含采集预处理、融合计费、综合账务、信息管理、基础管理、融合控制、综合结算、服务开通、合作伙伴管理、产品资费管理和局数据管理和发布。2、云平台：是BOSS云化的基础服务平台，提供统一任务调度和监控能力以及统一数据访问能力。主要包括分布式服务框架（DSF）和分布式数据访问框架（DAF），其中分布式数据访问框架包含统一数据访问引擎（DAE）和数据存储。3、云设施：是指为适应系统云化的基础设施，包括：计算资源、网络资源和存储资源。4、云运维平台：是保障系统高效、稳定和健康运行的管理平台，提供监控管理、发布管理、故障管理、探针管理和配置管理等能力。6.1.4 云化部署架构BOSS云化部署架构如下图所示： 图6-2 BOSS云化部署架构BOSS云化部署架构包括云应用、云平台和云设施等各层的云化部署，简要描述如下：1、云应用建设采集预处理、融合计费和综合帐务等云应用集群，实现应用的弹性伸缩和X86部署，实现应用与数据分离，通过统一的数据访问引擎进行数据共享访问。2、云平台建设物理数据库集群、内存数据库集群、分布式文件系统集群、NOSQL数据库集群、分布式缓存集群，实现各系统的弹性伸缩和X86部署。3、云运维平台建设云运维平台，提供监控管理、发布管理、故障管理、探针管理和配置管理等能力。6.1.5 云化范围各省在部署时需要根据云化范围要求完成必选建设内容，并根据各省情况完成可选建设内容。业务范围模块云化云应用采集预处理在线接入预处理分拣 融合计费在线计费离线计费综合帐务帐务处理帐务管理积分管理信用管理消费提醒管理BOSS服务管理(BSM)云平台分布式文件系统内存数据库物理数据库NOSQL数据库分布式缓存要求实现 选择实现6.2 云应用要求6.2.1 概述云应用是指BOSS系统中的经过云计算架构改造后的应用，具备云化特征，实现与数据分离和无状态化，应用通过统一的数据访问引擎访问数据。根据应用处理数据源和处理方式的差异，分别提出总体云化技术要求，并给出应用云化示例。整个BOSS领域的应用分为如下四类：1、 文件处理类，强调高吞吐量；例如：语音，数据业务的离线话单处理。2、 消息处理类，强调低时延、高可靠；例如：语音，数据业务的在线计费。3、 表数据处理类，强调并行处理能力；例如：周期触发的固定费计算处理等。4、 服务处理类，强调低时延、数据一致性；例如：从CRM触发的开户请求处理和外围渠道的充值、余额查询等请求处理。需要针对不同类型的应用采用适合的云化方案，综合考虑云化效率、成本以及运营支持方面的因素在如下几个方面提出相关要求：1、 应用与数据分离：应用无状态，数据集中存储；2、 高可用：应用节点故障时任务可自动迁移到其他可用节点，应用支持任务的断点续做或者回滚后重新处理，保证数据的一致性和正确性，节点之间的任务切换时间符合业务要求；3、 负载均衡：应用处理的任务粒度和任务量可根据主机的处理能力进行适应性配置，分配机制可保证输入的任务在节点之间均衡处理；4、 弹性伸缩：能够根据业务量的变化动态调整应用节点数量。6.2.2 总体技术要求针对云应用提出了如下具体技术要求，其中“应用与数据分离、应用集群部署同质化、应用节点间负载均衡、故障自动接管、弹性伸缩和系统升级业务无中断”针对文件处理类、消息处理类、表数据处理类以及服务处理类所有应用，“任务拆分规则可定义和任务之间无依赖”仅针对表数据处理类应用。1、应用与数据分离 要求相关应用不保存客户资料、帐务信息等数据，支持通过统一数据访问引擎获取数据。2、应用集群部署同质化要求相关应用支持集群化部署，并且集群内各个节点部署的应用无差异、同质化，能够互相替代。3、应用节点间负载均衡要求应用各节点能力对等，实现节点间任务均衡处理。4、故障自动接管当应用服务故障后，其未完成的任务支持由其他应用服务接管继续处理或重新处理，接管过程中，要求任务处理完整。5、弹性伸缩支持系统应用集群的动态调整，系统处理能力能够随应用节点变化线性调整。6、系统升级业务无中断对不涉及数据模型变更、大的流程重构等一般性需求开发提供在线升级能力，确保升级过程业务无中断，保持业务的连续性。7、任务拆分规则可定义对于待处理任务，根据业务特征，可选择按尾数、键值区间、取模、哈希、时间段等方式或方式组合，对待处理任务进行拆分。8、任务之间无依赖同一作业的待处理任务拆分后，各个子任务之间没有依赖关系，可以无序执行。6.2.3 应用示例6.2.3.1 采集预处理6.2.3.1.1 在线接入在线接入子系统负责接入外部网元和网状网D模块（漫出）的DCC在线计费消息，并分发给在线计费集群或网状网D模块（漫入）。图6-1 在线接入功能结构 负载均衡器（可选）：在线接入子系统通过负载均衡器实现与外部网元设备的对接，并由负载均衡器实现内部DCC Proxy间的负载均衡、水平扩展和升级不间断。负载均衡器需要支持过载保护功能，在达到系统预设的负荷阈值后限制接收DCC请求，确保在大量用户接入时系统仍然正常运行。同时，系统确保处理能力在大用户量接入的冲击后尽快恢复。负载均衡器可以布置多套，网元可以连接不同的负载均衡器，每个网元可以连接两个负载均衡器作为主备连接。每台负载均衡器可以采用主备双机方案确保其高可用性，通过浮动IP对外开放一个IP地址。DCC Proxy：DCC Proxy包含协议适配和路由管理功能。协议适配接收来自业务控制网元、网状网D模块的在线计费请求消息，将其转换为内部消息，提供给融合计费，并接收融合计费返回的业务使用额度等结果消息，将其转换为DCC协议响应消息，转发给相应的在线计费请求方。路由管理支持与多个业务控制网元并行进行在线计费消息交互的能力，支持根据用户和业务信息配置，将在线计费消息转发到相应的在线计费实例或网状网D模块（漫入）的功能。如果应用层服务节点失效，则新的CCR自动路由到其他节点上。在线接入处理流程如下：图6-2 在线接入处理流程 本省用户计费流程：1、GGSN/P-GW等网元触发在线计费DCC消息给所连接的省BOSS的DCC Proxy。2、省BOSS的DCC Proxy根据用户路由情况将在线计费DCC消息分发给计费引擎。漫游用户计费流程：1、GGSN等网元触发在线计费DCC消息给所连接的省BOSS的DCC Proxy。2、省BOSS的DCC Proxy判断为外省漫入用户，将在线计费DCC消息分发给本省的网状网D模块（漫入）。3、本省的网状网D模块（漫入）将在线计费DCC消息发给用户归属省的网状网D模块（漫出）。4、用户归属省的网状网D模块（漫出）将在线计费DCC消息给省BOSS的DCC Proxy。5、省BOSS的DCC Proxy根据用户路由情况将在线计费DCC消息分发给计费引擎。在线接入有两种典型组网结构，各省可根据实际情况灵活选择。组网结构1：图6-3 在线采集组网结构1组网结构1由多套DCC Proxy组成集群，GGSN/P-GW等网元与DCC Proxy采用固定搭配，网元扩容时DCC Proxy集群配套扩容。GGSN或P-GW等网元需要能够与主、备DCC Proxy建立连接，并在侦测到主连接断开后将报文发送到备用连接。组网结构2：图6-4 在线采集组网结构2组网结构2由负载均衡器和多套DCC Proxy组成集群，GGSN或P-GW等网元与主、备负载均衡器双机建立连接，由负载均衡器将DCC消息均衡地发送给各DCC Proxy。6.2.3.1.2 预处理分拣预处理分拣涵盖话单格式标准化、业务场景分析、产品有效性分析，以及查重、分拣处理， 从而完成离线计费前的标准化处理，场景分析处理，为后续计费算费做好预处理准备。 根据话单文件的不同并行处理方式，分为抢占式和分发式两种方式。6.2.3.1.2.1 抢占式图6-5 预处理方案-抢占式集群模式下，文件存储在分布式文件系统上，要求提供任务抢占处理模式，保证文件不被重复处理。 1、提供记录锁对任务进行加锁控制；2、通过增加处理节点，水平扩展系统处理能力；3、要求实现应用与数据分离，应用无状态，节点出现故障时，其他节点可以接管。6.2.3.1.2.2 分发式图6-6 预处理方案-分发式预处理分拣提供话单分发能力： 1、话单记录分发：对一类话单文件，解码输出到同一个队列，话单文件分发环节将话单文件依次读出并分配给不同的目标队列；2、文件负载调配：对于分发到目标队列的文件，由对应后端处理节点的传输进程来获取，提供对长时间未处理的文件调配到其他主机进行处理。6.2.3.2 融合计费6.2.3.2.1 在线计费在线计费支持依据在线计费消息进行正算和反算，结合在线业务控制网元的实时话务控制能力，进行欠费风险控制；以在线计费消息作为计费依据。图6-7 在线计费实现方案在线计费处理主要具备如下特点：1、 在线计费应用与数据分离 在线计费集群不保存客户资料、帐务信息等数据，在线计费节点通过统一数据访问引擎获取客户资料、帐务信息和会话信息等数据，实现应用与数据分离。2、 高可用设计a) 在线计费应用集群部署同质化：集群内各个节点无差异，同质化部署，能够互相替代。b) 在线计费应用集群节点间负载均衡：DCC Proxy可根据路由规则将任务分发到多个在线计费应用集群，集群内各节点间任务负载均衡。c) 在线计费应用集群内某个节点发生故障，任务可由其他节点接管，接管过程无数据丢失（已经完成消息交互的会话数据保存在会话管理节点，接管任务的节点在收到update消息时，从会话管理节点获取会话数据；正在处理的消息则无法完成处理，无法给网元返回响应，网元侧将超时）。3、 在线计费应用集群可水平扩展a) 支持集群内新增在线计费应用节点，新节点就绪后DCC Proxy再分发任务给其处理，应用节点扩展过程中不中断业务处理。b) 新增节点集群业务处理性能可线性增强。4、 异常、超时会话的存储周期可进行配置。目前在线计费会话数据有两种存储方式：方式一：在本地进行会话缓存，同时通过会话同步方式同步到远端集中存储，会话管理节点采用单机或双机方式部署。图6-8 本地会话缓存方式方式二：会话只在远端集中存储，本地不缓存。图6-9 本地会话远端存储方式6.2.3.2.2 离线计费离线计费是以经过采集预处理后的话单作为计费依据，服务费用的计算和累积量更新是在用户服务使用后进行的。根据话单文件的不同并行处理方式，分为抢占式和分发式两种方式。6.2.3.2.2.1 抢占式图6-10 离线计费帐务集成方案-抢占式方案描述1、 离线计费集群处理的数据文件存储在话单文件队列，各个处理节点通过抢占控制列表，对文件进行加锁控制，实现“抢占式”任务处理。任务处理完成后对话单文件进行解锁。2、 离线计费集群内节点故障后，其锁定的任务自动释放，其他节点可抢占并处理。3、 离线计费集群可水平扩展，支持水平横向新增节点，新节点就绪后共同分担文件处理任务。新增节点集群业务处理性能可线性增强。6.2.3.2.2.2 分发式图6-11 离线计费帐务集成方案-分发式方案描述：1. 采集、预处理生成的离线话单分发到各话单文件队列，通过负载均衡器发送到对应的应用节点。2. 离线计费应用可水平扩展，支持水平横向新增节点，负载均衡器注册新节点、定制分发策略后开始分发处理。3. 当某节点出现故障时，任务由其他节点继续处理。6.2.3.3 综合帐务6.2.3.3.1 帐务管理帐务管理与离线计费应用的主要区别在于处理的数据源有差异，离线计费处理的数据源主要是离线批量文件，而帐务管理处理的数据源主要是表数据记录。固定费用计算、月结帐务优惠、积分计算、信用控制及提醒服务管理等应用的云化要求参考此章节。帐务管理应用云化方案分为抢占式和分发式两种方式：6.2.3.3.1.1 抢占式图6-12 帐务管理处理视图-抢占式将任务定义为集群任务号，并定义子任务，通过各个节点的进程对子任务进行“抢占式”轮询，对任务进行处理。对于进程处理异常情况，其他进程可以自动接管，应用保证子任务异常接管及任务排重能力。6.2.3.3.1.2 分发式图6-13 帐务管理处理视图-分发式从用户资料数据表中获取用户编号，数据为先按地市再取模的方式进行任务拆分，通过分发调度应用对任务进行分发处理。对于进程处理异常情况，其他进程可以自动接管，应用保证子任务异常接管及任务排重能力。6.2.3.3.2 BOSS服务管理(BSM)计费帐务对外提供的能力开放当前主要由BOSS服务管理承载提供，为自助终端、网厅、营业厅、银行、代理商等接入渠道，提供充值、欠费查询、缴费、余额查询、帐单查询、免费资源查询等服务。图6-14 BOSS服务管理逻辑架构1、提供对外接口协议适配功能，负责与外围系统的对接；2、增加负载均衡器进行任务的分发；3、提供统一的服务代理，提供服务的封装。6.3 云平台要求6.3.1 概述图6-15 云平台逻辑架构云平台是BOSS云化的基础服务平台，它提供任务统一调度管理的核心能力以及统一封装的数据访问能力。云平台主要包括分布式服务框架（DSF）和分布式数据访问框架（DAF），其中分布式数据访问框架包含统一数据访问引擎（DAE）和数据存储。分布式服务框架实现服务的调度和监控；分布式数据访问框架通过统一数据访问引擎对应用提供数据访问服务。云平台支持数据平台化，构建统一数据访问引擎，实现数据与应用分离；强化云应用处理的集群部署和管理能力，实现系统的弹性伸缩。支持数据分布式部署，通过数据存储分片降低单节点数据访问压力。通过路由机制降低数据访问的复杂性，实现高效低成本扩展。支持计费资源全X86化部署，实现对应用的云化架构支持。支持帐务管理能力开放，实现多渠道的接入标准化，数据访问的一致性和完整性，增强对外开放能力，提升系统互联网化支撑能力。6.3.2 总体技术要求6.3.2.1 分布式服务框架分布式服务框架为云应用提供服务调度和服务监控基础服务，统一管理各类业务服务，从而实现应用的分布式计算能力、在线快速扩容、处理能力线性扩展、故障自动接管。6.3.2.1.1 服务调度具体的能力要求如下：1、根据系统的繁忙程度动态调节应用服务进程的数量。 2、根据应用集群内各应用计算节点的负载情况，自动将任务分发到空闲节点，实现节点间的负载均衡。3、支持动态调整节点资源，使节点资源具备弹性伸缩能力。4、支持按指定规则分配任务。5、支持抢占式或分发式任务调配能力。6.3.2.1.2 服务监控具体能力要求如下：1、管理并监控应用服务，支持异常进程的发现与处理。 2、支持任务队列的监控，支持过载等异常处理机制。6.3.2.2 分布式数据访问框架分布式数据访问框架通过统一数据访问引擎对应用提供数据访问服务，支持数据平台化，实现数据与应用分离；支持数据分布式部署，通过数据存储分片降低单节点数据访问压力。通过路由机制降低数据访问的复杂性，实现高效低成本扩展。6.3.2.2.1 统一数据访问引擎统一数据访问引擎提供对数据的统一访问能力。具体的实现要求如下：1、实现统一的分布式数据访问接口，支持通过LIB库的API或者服务调用的方式实现分布式数据的访问。2、支持分布式数据的路由策略，实现数据访问的透明化。3、支持分布式数据访问的一致性和完整性。4、支持服务部署的弹性伸缩。5、支持路由数据并发高速访问和持久化保存。6、支持路由数据的动态更新。7、支持路由数据访问的高可用性。8、支持路由数据的一致性。6.3.2.2.2 数据存储根据BOSS数据的访问频度、访问方式（只读、读写）等特征决定数据采用的存储方式。目前BOSS常用数据存储方式包括分布式文件系统、内存数据库、分布式缓存、NOSQL数据库和物理数据库(传统的关系型物理数据库)。BOSS系统中的数据实体分类如下：1、原始话单：从网元采集的离线话单文件。2、DCC消息：从网元接收到的实时DCC消息数据。3、计费中间文件：计费处理中间环节输出的文件。4、运行日志：应用运行过程中输出的状态和日志记录。5、详单：也称清单，是标准服务使用记录批价后的记录。6、帐单: 出帐等阶段形成基于用户的帐目详细记录。7、三户资料：涉及客户、用户、帐户的基础资料信息。8、产品订购：用户订购的套餐、服务、营销活动等相关信息。9、余额：帐户下所有帐本的余额明细信息。10、累积量：用户使用服务过程中，服务使用量的累积等信息。11、免费资源：套餐、活动等赠送的通信量数据。12、局数据：是指涉及跨部门（业务部门和执行部门之间）需要进行统一分配管理的公共资源数据或相关属性的数据，可分为全网业务局数据和省级业务局数据。13、配置数据：应用运行所需的参数信息。6.3.3 应用示例6.3.3.1 分布式数据访问框架 图6-16 分布式数据访问框架帐管、计费、账务等云应用客户端发起的一次带事务的请求，通过统一数据访问引擎获取数据，保证数据访问的透明化及一致性。MDB云化需要支持按地市、用户号码分布式部署，业务模块可根据业务需要对MDB标识拆分合并上、下行包并返回业务端。6.3.3.2 数据存储数据分类特征和存储方案如下：表 6-1 数据分类特征和建议存储方式数据分类数据特点短期/高速访问存储长期/持久化存储原始话单数据写入频繁、基本不改变半结构化集中式存储分布式文件系统磁带分布式文件系统DCC消息数据写入频繁、基本不改变半结构化集中式存储本地存储分布式文件系统分布式文件系统集中式存储计费中间文件数据读写频繁、短时间内频繁修改半结构化集中式存储分布式文件系统分布式文件系统运行日志数据写入频繁、基本不改变半结构化集中式存储本地存储分布式文件系统分布式数据库详单数据写入频繁、当月数据会出现修改、历史月数据基本不改变、半结构化分布式数据库集中式存储分布式文件系统分布式数据库分布式文件系统帐单数据写入频繁、当月数据会出现修改历史月数据基本不改变内存数据库分布式缓存物理数据库分布式数据库三户资料数据读写频繁、要求访问低延时结构化内存数据库分布式缓存物理数据库分布式数据库产品订购余额数据读写频繁、要求访问低延时、有事务操作、结构化内存数据库分布式缓存本地缓存物理数据库分布式数据库累积量免费资源局数据读取远大于修改、要求低访问延时、结构化内存数据库分布式缓存本地缓存物理数据库配置数据读取远大于修改、要求访问低延时、结构化内存数据库分布式缓存物理数据库6.4 云设施要求6.4.1 概述云设施是指为适应系统云化的基础设施，包括：计算资源、网络资源和存储资源。在BOSS系统云化的要求下，云设施需遵循计算资源向低成本X86服务器迁移，网络资源需要具备高带宽、低时延特性，存储资源需要具备高性能、低成本、可扩展特性。6.4.2 总体技术要求6.4.2.1 计算资源1、主机性能计算要求由于X86和小机的差异性，X86设备日常CPU利用率不超过40%进行资源评估。2、集群部署要求单个集群尽可能采取同一类型的主机进行部署，减少异构部署模式。3、弹性可伸缩的平滑扩展要求架构应具备灵活的扩展性，以支持系统集群规模可以根据需要进行快速的扩展。4、大规模集群化管理要求需要有便利的软硬件部署方式及管理模式。5、设备选型要求设备CPU架构需一致，且属于主流演进路线，以降低对硬件厂商的依赖和获取长期技术升级的支持；6、不同设备需支持安装统一的操作系统，以降低应用的复杂度，并支持应用快速上线、应用动态部署和主机设备的快速更换；在进行单设备选型时，需根据具体应用部署判断是否配备大容量内存，对于内存需求高的集群配备大容量内存，如：内存库集群，计费集群，账务集群等； 7、操作系统要求操作系统要求采用Linux，可以使用主流的Suse、RedHat等版本。6.4.2.2 网络资源传统架构下应用以单机部署为主，节点间信息交互少，对复杂的网络连接需求低。在BOSS系统云化后，应用跨主机节点的交互大大增多，对网络连接需求增高，因此要求选用高带宽低时延的网络资源。组网方面要求对于大数据量交互的集群采用万兆以上带宽的组网方式，对于一般数据量的交互可以采用千兆组网方式。采用集中共享式存储时建议存储网络单独构建，根据采用存储类型的区别可以采用FC光纤或万兆以上以太网。为提升性能，可采取多网卡设计或引入InfiniBand技术。BOSS系统云化在工程实施时需要注意：1、网络隔离设计：按应用、数据、平台、接口划分网络管理域，不同域之间尽量隔离。2、网络带宽需求周密评估：云化后，由于数据分片管理、不同节点之间交互增多等原因，导致网络带宽需求急剧增长，在工程实施前需要进行周密的网络带宽需求评估，制定周密的实施方案。3、InfiniBand组网需考虑应用和系统软件的兼容性： InfiniBand需要软件进行适配性改造。4、节能环保：应从机房供电、散热、机房布局、设备选型等多个方面考虑降低能耗。6.4.2.3 存储资源BOSS系统云化对存储设备的性能、可靠性、稳定性、适配性等因素具有更灵活的要求，需要按照相关指标根据应用的需求进行存储设备的选择。存储设备选择原则如下:1、在性能方面，存储系统的指标由容量、访问速率和并发处理能力等来衡量，包括代表I/O处理能力的IOPS、前后端带宽、磁盘读写速度、CACHE 读写速度等。1)IO吞吐率（IOPS），每秒可以完成的读写操作数，对交易型业务性能影响明显。2)IO带宽（MBPS），对流媒体和大块数据操作具有现实意义。3)请求延时，从接受主机请求到返回结果的延迟时间，对随机型访问、高性能计算等应用影响较大。2、可靠性和稳定性，则由系统的冗余能力、可靠运行能力、故障隔离及恢复能力等衡量。3、可扩展性要求存储资源在磁盘容量和端口上具备良好的扩展能力。4、在使用SAN 存储的情况下，建议采用主流的中高端FC交换设备，FC交换机具有足够的交换能力，且具备链路聚合能力。存储应具备电源冗余能力，具备存储性能监控能力。 5、存储设备支持各种磁盘类型和接口，包括SCSI、SATA、SAS、SSD、FC 等。6.4.3 应用示例6.4.3.1 计算资源图6-17 计算资源应用示例1. 计算资源在应用模块按照集群化、X86化进行应用部署；2. 数据域可以采取X86、小型机混搭的方式进行部署；6.4.3.2 网络资源在BOSS系统云化中，组网分为两种类别：主机层组网和存储层组网，以下表格根据此两种类别进行组网模式分析：类别序号方案特点主机层组网模式一千兆以太网网络延时：几十微秒带宽：1Gbps，可通过多条千兆网络进行带宽捆绑提高带宽至nGbps级别模式二万兆以太网网络延时：几十微秒带宽：10Gbps，可通过多条万兆网络进行带宽捆绑提高带宽至n*10Gbps级别模式三InfiniBand技术组网网络延时：百纳秒带宽：40Gbps需对应用进行改造以支持RDMA协议，才能发挥低延时特性，RDMA协议由于需要内存映射会有额外内存消耗。存储层组网模式一以太网（与主机间通信共用网络）适用NAS、分布式文件系统扩展灵活与主机间通信共用网络适合对总吞吐量要求不高的应用场景模式二以太网（存储独立组网）适用NAS、分布式文件系统扩展灵活与主机间通信隔离，避免了互相影响提供了更高的数据吞吐带宽模式三SAN 存储专用网络适用SAN集中式存储高数据吞吐与主机间通信隔离 BOSS系统云化的网络总体架构示例图如下：图6-18 网络总体架构图示例6.4.3.3 存储资源存储资源类型包括混合块存储、纯固态块存储、分布式文件系统、NAS存储和键值文件系统等，根据各个类型的特点，分别有不同的业务应用场景。其中在BOSS系统中有较多的业务应用场景的存储类型如下：1、混合块存储：基于传统的磁盘阵列实现，具有高稳定、高性能、低延迟、高带宽特点，适合IO访问密集型的数据库应用，如：oracle物理库持久化管理。2、纯固态块存储：基于SSD的磁盘阵列，具有高稳定、高性能、极低延迟，低功耗特点，适合IO访问密集型的数据库应用，如：内存数据库持久化管理。3、分布式文件系统：以标准文件系统接口（如NFS、CIFS、POSIX等）形式向应用系统提供海量非结构化数据存储空间，具有协议开销较高、存储能力和性能水平扩展较好的特点，适合各类文件存储场景，如：日志，原始话单，中间结果，文件备份，应用程序等存储。6.5 云运维要求6.5.1 概述云运维平台是保障系统高效、稳定和健康运行的管理平台，提供监控管理、发布管理、故障管理、探针管理和配置管理等能力。图6-19 云运维平台架构云运维为云应用、云平台和云设施提供运维管理所要求的各项业务和性能数据，以及操作控制协作能力，利用BOSS系统其他功能域提供的数据和控制方式，对BOSS系统进行统一监控管理，并能够对外提供监控、分析和运维管理的能力，包括：1、实现对物理资源、虚拟资源等基础设施的统一调度和监控；2、应用软件统一监控管理，提供统计、监控、调度、服务管控等端到端的综合管理能力；3、系统应用的快速部署发布、系统容量的平滑扩容、灵活的资源分配；4、有效的故障发现、处理和管理能力；5、关键业务各环节的重点监控能力；6、运维管理的可视化配置能力。6.5.2 总体技术要求6.5.2.1 监控管理6.5.2.1.1 云应用管理应用监控：能够对系统应用软件进行性能和业务运行情况监控，包括应用状态、资源消耗情况、性能情况、业务处理效率等运行信息。应用管理：能够对应用进行启停等基础管理操作，能够根据监控结果，将异常应用的任务迁移到可用应用节点进行继续处理。任务管理：对应用的管理还包括任务编排、调度，实现一组运维任务的有序运行，支持任务执行过程的监控和异常处理，如重做等。6.5.2.1.2 云平台管理平台监控：对分布式服务框架、分布式数据访问框架和分布式数据存储的运行状态、处理性能、资源消耗等情况进行监控。平台管理：能够根据监控结果，对异常情况根据异常处理策略进行人工干预或服务接管，确保平台高可用和服务不间断。6.5.2.1.3 云设施管理性能监控能够对云设施进行拓扑结构、运行状态、性能等进行全方面一体化监控，并能对产生的变化和异常进行处理和辅助分析。 完善资源管理相关流程，涉及资源预算管理，资源申请，资源变更，资源回收等流程。用于管理资源的分配和回收，同时资源分配要与策略开通相结合，使得业务在获取资源后即可使用，无需进行诸如路由、IP等策略申请。包括动态适配、动态调整等等相关策略，实现资源配置、配置项管理、资源分配、调整及规划的能力； 故障自动隔离：集群可以自动发现故障节点并调整任务调度策略，在不影响处理的同时隔离故障节点，保持系统高可用； 对系统各设施的运行情况进行监控管理，包括节点计算性能、CPU和内存使用率、存储空间和IO性能等情况，对异常进行业务切换或进行人工干预，确保系统不间断运行。6.5.2.2 发布管理面对拥有巨大数量主机的系统架构，以及业务与应用的动态伸缩、弹性扩展等特点，需要确保系统应用和业务应用在少量人工参与的条件下，能够快速、高质量的部署应用软件和配置，能够适应不断变化的基础架构设施变化，使系统具备高效的升级能力，包括：1. 能够适应平台结构变化；2. 能够将应用高效的部署到目标平台，减少人工干预；3. 能够控制系统启停任务和顺序；4. 能够对业务发布过程进行监控。6.5.2.3 故障管理故障管理通过日志分析、应用监控、数据采集等手段，实现系统内的故障快速发现，并能够辅助定位分析。在系统发生故障时，能够自动采取隔离故障的措施，减少故障引起的损失，并通过告警等方式通知人员处理干预，同时对系统发生的故障历史进行统计分析，作为系统优化和运维管理流程改进的基础。6.5.2.4 配置管理配置管理通过可视化的方式，为运维管理人员提供多元化的配置方式，包括配置信息管理、采集、更新、下发。1. 云设施、云平台和云应用基本信息配置和采集2. 监控信息的采集配置和异常处理策略配置3. 应用发布规则和策略配置4. 故障发现规则和处理规则的配置5. 业务探针流程和规则配置6. 其他运维管理配置。6.5.2.5 探针管理探针管理是针对关键业务的各个环节进行性能统计分析的工具，是面向环节健康度分析、瓶颈分析和优化的方式。探针管理要求关键业务流程中的各环节应用能够提供处理效率数据，并能够关联统计分析输出关键业务处理性能以及各环节各自处理性能和处理结果。1. 可以指定需要进行业务探针测试的业务流程和处理环节2. 可以指定探测时间要求、间隔要求3. 可以指定用户进行业务探针测试4. 能够按照探针策略进行关键业务的全流程探测7. 关键技术能力7.1 分布式服务框架分布式服务框架为BOSS应用提供服务调度、服务监控等基础服务。目前有抢占式和分发式两种模式，这两种模式能保证任务在不同节点之间均衡分片。在单一对象的数据（如同一用户大量短信话单在多个话单文件中出现）在大量并发任务中出现且任务处理过程中需要进行锁定时，由于锁定冲突有可能导致整个系统处理出现阻塞，分布式服务框架需要有冲突的识别和自动处理机制（建议出现锁冲突后，系