1.2 电信业务支撑系统的发展历程

电信业务支撑系统随着电信技术的快速迭代而不断发展和壮大。近二十年，电信行业进入了爆发期，业务支撑系统也随之迎来了黄金发展期。回顾业务支撑系统发展历程，该历程大致可分为4个阶段：初始阶段、成型阶段、稳定阶段和变革阶段（如图1-3所示）。

1.初始阶段

20世纪80年代，拥有9亿人口的中国，电话用户数仅为280多万，电话普及率为0.43%。当时还是政企合一，邮电部既是电信行业的主管部门，又是电信运营商，主要的工作重点是建设和完善电信基础设施，由于信息技术还不发达，因此国内并没有真正意义上的运营支撑系统。在80年代中后期，随着程控数字交换机的上线，出现了简单的计费和网管系统。但是这些软件仅限于本厂家的设备，功能单一且规模小。从80年代后期到1997年，随着网络规模的快速扩大，产生了具备跨厂商设备管理能力的网管系统。随着用户规模的扩大以及移动通信网的建设，计费系统也开始发展起来。这些都是由邮电部组织和委托高校和科研机构开发的，并没有独立的软件企业和专业人员进行相关的软件开发工作。随着用户数和业务量的爆发式增长，电信的服务和管理水平遇到了发展瓶颈，为了解决日益增长的用户需求与落后的服务手段之间的矛盾，1995年5月，邮电部电信总局提出开发和建设“市内电话业务计算机综合管理系统”，即“九七工程”。“九七工程”是一个里程碑，它拉开了业务支撑系统建设的序幕。

2.成型阶段

从1997年到2008年，业务支撑系统进入了快速发展阶段，这个阶段也是我国电信改革最为剧烈的一段时间。电信企业经过几次大的拆分与重组，到2008年电信市场完成了从业务专营到三足鼎立全牌照运营（三足指中国移动、中国电信、中国联通）的转变，市场竞争格局逐步形成。这种转变直接促进了电信运营支撑系统的蓬勃发展，电信运营商经过系统选型、试错、定型，已基本确定了适合自己的业务支撑系统，合作厂家也从原来的十几家逐渐稳定到了四五家。这个阶段中国电信重新对“九七工程”进行改造，使它从传统的业务计费功能转变到全业务的运行支撑，CTG-MBOSS开始稳步发展。中国联通也完成了系统集中化建设，开始向全国集中化迈进。此时，中国移动凭借成功的系统建设策略和强大资金优势，将众多合作伙伴吸引到自己身边，并将资源的优势化为胜势，规划、建设齐头并进，BOSS建设跨入NGBOSS时代。

3.稳定阶段

2008年以后，经过多年的系统建设，运营商已经积累了丰富的系统建设经验，对自己的需求和业务支撑系统的发展方向都有了更清晰的认识。随着各运营商业务支撑系统大版本的确定，“统一规划、分步实施”已成为运营商系统建设的主导思想，系统建设从规划到投资立项都进入了相对稳定的状态。运营商几乎每年都会组织技术规范修订，用于指导系统的演进发展。这个阶段，中国移动几乎一年一个版本，完成NGBOSS从1.0到4.5的发展演进过程。中国联通在系统集中化的道路上不断进取，在完成了电子营业厅（ECS）系统建设，并推出了全网统一的业务和产品后，又借着3G的东风与苹果合作，通过控制号码资源和明星终端资源，成功完成了业务集中，建立了集中化的运营体系。中国电信系统建设则一直稳扎稳打，CTG-MBOSS版本从1.0到2.0不断升级，通过规范指导，有效落实IT能力的提升和统一。

4.变革阶段

随着大数据、云计算和互联网的迅猛发展，到了2015年，新技术、新模式、新业务对电信业务支撑系统的影响开始显现，各运营商又开始酝酿新的技术变革。系统云化、微服务化、自动化、智能化成了转型升级的主旋律。中国移动在完成了NGBOSS 4.5的规范建设后，于2015年制订了第三代业务支撑的建设规范。新规范借鉴了互联网企业的系统运维模式和云化的技术发展路线，对技术架构进行了更细层级的划分（CRM系统从原来的三层架构演进为五层架构），对业务架构也进行了重新定义（由单体架构向业务中心建设转型）。中国联通在继续深化CBSS和全国集中化建设的同时，开始专注系统专项能力提升以及智能化、云化和分布式系统建设。2016年，中国电信发布了转型升级新战略，将持续推进企业转型升级3.0，着重推进网络智能化、业务生态化、运营智慧化，致力于打造业界领先的综合智能信息服务运营商。

电信行业是一个比较依赖IT系统的行业。一直以来，电信企业对IT系统的建设和IT技术的发展都非常重视，相较于其他传统企业更加追求技术进步。每次有重大技术变革或理论创新，电信企业都会最先做出反应，敢于尝试。然而，随着近几年互联网企业的崛起，在新兴互联网技术不断涌现的情况下，电信企业受传统业务连续性保障的制约，在新技术、新思想方面的探索和发展相对滞后。

电信业IT系统的发展历程绝对可称得上是一部中国IT技术的发展史。开发语言经历了Fox Base、Power Builder、Delphi、Pro*C到J2EE、JEE的变迁，系统架构经历了单体、C/S架构、B/S架构、SOA，目前已全面实施分布式系统架构。从跟随到引领，电信人从来没有放弃对技术进步的追求。“让技术驱动创新，让软件定义一切”一直是我们前进的方向。

1.2.1 “大算盘”时代

前面讲到业务支撑系统的发展经历了四个阶段，支撑系统实现了从无到有，从高速发展到稳定运营的发展过程。这里谈的大算盘时代并没有明确的时间节点，如果非要划个界线，就以邮电部电信总局的“九七工程”为界。“九七工程”的实施，标志着电信业务支撑系统建设的正式起步。

实施“九七工程”前，业务单元都是以市为单位进行运营管理的。当时的业务比较简单，主要围绕着装机、配号、配线展开，计费也比较原始（通过C程序解码交换机上的磁带，计算话费）。各县市资源调配、资源管理依赖于笔记本电脑、Excel。后来相继用Fox Base开发了一些管理系统，这些系统从功能上看基本上是手工操作的模仿和延续，也就是通常所说的“大算盘”。这些系统几乎没有管理功能，可管理性差，更谈不上数据共享、信息传输等现在看来最基础的能力。在当时，软件架构绝对是高大上的东西。

进入20世纪90年代以来，我国电信行业的业务量每年以45%～50%的速度递增。原来的服务手段和管理水平已不能满足业务的发展，装机难、修机难、查询难等成为电信营业部门的心病。为了解决先进的电信网与落后的服务手段不相称而带来的各种问题，1995年5月，邮电部电信总局提出开发和建设“市内电话业务计算机综合管理系统”，即“九七工程”。从此，电信业务支撑系统进入了C/S时代。

1.2.2 C/S时代

“九七工程”共分为九个子系统。其中，营业受理、配线配号、订单管理、机线资源、综合管理与查询属于基本子系统，112、114、计费、号簿子系统与基本子系统完全实现数据共享。根据电信总局对“九七工程”的实施要求和对各子系统相互之间关系的阐述，以大唐电信为代表的一些厂家基于当时的技术条件，选择Power Builder+Oracle的架构模式，也就是所谓的C/S架构。

然而，Power Builder+Oracle模式并没有持续多长时间，基于安全考虑，要求前端不能直接访问数据库。于是Delphi+Pro*C+Oracle的模式应运而生，这也是最初的三层架构的雏形了（如图1-4所示）。Delphi程序作为客户端负责与用户交互；Pro*C程序运行在CICS中件间提供业务服务，阻断客户端直接访问数据库；Oracle数据库服务器提供数据服务。通过这种三层架构设计，从技术上消除了客户端直接访问数据库带来的风险。

在这个阶段，电信业务的发展也走上快车道。伴随着用户量的不断攀升，移动网络的快速发展，再加上电信企业的拆分、重组以及市场化改革，市场竞争加剧，业务类型不断丰富，管理要求越来越高。这时，C/S程序的数据分散、客户端升级维护麻烦，业务响应慢等弊端开始突显，已经很难满足业务的快速发展。与此同时，B/S程序作为一种新的软件架构模式展现了其强大的生命力。而随着J2EE的不断发展以及大量成功案例的出现，B/S软件架构的企业级应用登上了历史舞台。

1.2.3 MVC垂直应用

B/S软件架构的兴起让人们开始憧憬Web程序给客户带来的便利。不用再在每个客户终端安装应用程序，对客户终端的要求变得更简单，只需要能够正常上网即可。同时，软件升级和维护也变得容易，只需要更新服务器上的软件即可，这对客户的人力、物力、时间、费用的节省是显而易见的。Web程序的巨大成功，推动了Java的快速发展，而Java的发展又推动了企业级Web应用的普及。根据J2EE的标准，软件架构分为三个层级（如图1-5所示）。

通常意义上的三层架构就是将整个业务应用划分为：表现层（UI）、业务逻辑层（BLL）、数据访问层（DAL）。每个层次的职责如下。

①表现层（UI）：通俗讲就是展现给用户的界面，负责与用户交互，用于接收用户输入的数据和显示处理后用户需要的数据。

②业务逻辑层（BLL）：表示层和数据访问层之间的桥梁，针对具体问题的操作，负责实现业务逻辑。

③数据访问层（DAL）：负责与数据库打交道。主要实现对数据的增、删、改、查。将存储在数据库中的数据提交给业务层，同时将业务层处理的数据保存到数据库。

严格来说，MVC不是一种应用架构，它是表现层的一种设计模式。基于表现与数据分离的原则，表现层分为三个模块：Model-View-Controller。由于早期的J2EE应用都是基于MVC的三层架构垂直构建的，所以后来人们也就称这种垂直构建的三层系统为MVC应用，也称为单体架构。MVC系统生态如图1-6所示。

MVC时代的业务支撑系统建设的特点就是造“烟囱”。在信息化大潮下，业务处在高速发展阶段，在先建设再优化的指导思想下，各个运营商都建设了各种各样的数目可观的信息系统，如营业系统、计费系统、渠道系统、决策支持系统等。每个系统由一个或多个厂商承建，自成体系。久而久之，这些系统不仅个体庞大，且相互之间没有通信，就好像一个个的大烟囱。

“烟囱”多了，造成了信息孤岛，于是支撑系统又开始踏上打破孤岛、系统整合的道路。主流的EAI整合方式主要有三种：界面集成、服务集成、数据集成。

①界面集成是通过前台框架把不同的系统的页面集成到一个系统中（或称系统门户）。这种方式相对比较简单，也是当初最常用的集成方式。界面集成涉及的关键技术有Portal和单点登录（SSO）。简单地说就是，通过Portal技术把其他系统的相关界面集中到一个门户中，然后通过SSO解决跨系统登录访问的问题。

②服务集成是不同应用系统之间通过共享的服务进行功能的整合和数据同步。它本质上是数据集成的一种服务化的表现形式，是EAI集成的高级阶段。服务集成有力地推动了Web Service、SOA、RPC等技术的发展。

③数据集成是为解决信息孤岛把不同系统的生产数据在逻辑上或物理上进行有效的集中，为企业提供全面的数据共享。数据集成的方式比较多，如联邦数据模式、中间件模式、数据仓库等。电信行业是国内最先尝试数据仓库（中国移动在2001年就开始学习研究数据仓库）的企业，为中国培养了大批的数据工程师。现在很多从事大数据、人工智能方面的中高级人才有电信经营分析的从业背景。

系统建设、系统整合几乎是MVC时代的主旋律。建设初期系统相对比较简单，但是随着时间的推移，业务的不断发展，系统会变得越来越臃肿，关系也变得越来越复杂，给运维带来了很大风险和难度。此外，成本居高不下，重复建设造成了严重的资源浪费。“大象病”就是这么一点点形成的。

如何才能更好地实现服务复用，避免重复建设，简化系统间关系呢？于是，SOA出现了。

1.2.4 SOA服务化

SOA是指面向服务的架构，强调以服务为基础搭建的企业IT架构。它通过建立标准解决了服务“复用”和系统间“互操作”等问题。SOA虽然出现很早，但是当时的技术水平和市场环境尚不成熟，并未引起人们的广泛关注，直到Web服务和SOA参考模型的出现，SOA才直正进入高速发展阶段。2005年左右国内外开始有厂商推动ESB产品在运营商系统的落地。

因为电信行业的IT系统间关系并不是简单的平行并列关系，而是“核心+外围”星形模式，所以运营商并没有大规模引入ESB，只是在一些技术先进省份进行试点。调用关系是单向的，一般是外围系统调用核心系统提供的服务，并不太适合ESB的业务场景。再加上ESB的定制能力差，核心系统在服务开放形式上只能以当时最标准的Web Service的形式进行注册和发现，性能上存在严重的问题。因此，在核心业务系统领域，并没有使用ESB产品，而是自建接口平台。

接口平台实现了服务汇集，同时实现了外围系统对核心系统的隔离。以CRM为例， CRM除了提供垂直应用的营业功能外，还对外提供了大量的接口供外围系统调用，如电子渠道、社会渠道、ESOP、网状网以及外部银行、商城等渠道。这些渠道通过接口平台实现了与CRM的通信（如图1-7所示）。

随着服务化的深入、新业务的不断涌现以及市场竞争的加剧，对业务支撑系统的要求越来越高，而上述架构在ESB或接口平台上的瓶颈也日益凸显。原系统架构主要问题表现在：

①缺乏有效的服务治理，服务资产混杂不清，没有有效的服务管控手段；

②业务支撑响应慢，系统尾大不掉，无法做到实时更新和模块化发布；

③系统可用性差，无法做到7×24小时无间断提供服务；

④创新业务难以支撑，特别是带有互联网特点的创新业务，如团购、秒杀等。

传统的SOA模式已很难满足业务的快速发展，急需一种新的架构模式，既要解决单体架构沉重的负担，又要高效率实现服务化的功能，这时微服务架构出现了。

1.2.5 微服务架构（MSA）

SOA虽然解决了部分服务复用和系统间整合的问题，但它并没有解决“大象病”带来的系统臃肿、反应迟缓、运维困难的问题。新技术、新业务以及市场竞争的加剧，对系统的业务支撑能力提出了更高的要求，如7×24小时不间隔服务、模块化快速迭代、应用的水平扩展、资源的弹性伸缩等。

认知的提高会催生技术的发展，新的难题一定会有新的解决方案。在这方面，IT领域总不会让人失望。正是由于大家对系统敏捷的追求，对高可用、水平扩展、弹性伸缩的渴望，Docker、DevOps从一出生就高歌猛进，大大加速了微服务架构的推广实践。微服务架构是一种分布式服务架构模型（如图1-8所示），与SOA的主要区别在于一个是分布式调用，另一个是集中式调用。

面对如此势头，运营商不会无动于衷，于2014年开始规划新一代业务支撑系统的架构演进路线。作为国内最大的电信行业IT解决方案的提供商和服务商，亚信科技一直在跟随世界IT发展趋势，关注着新技术发展动态，不断地尝试新技术的实践方案。

在IT技术领域，没有最好的，只有最合适的。结合对电信行业的理解和系统特点，亚信科技已形成了一套完善的企业级微服务架构。

新架构的主要特点如下。

①分布式：实现了三个层次的分布式，分别为物理部署分布式、服务部署分布式、数据存储分布式。

②高可用：由于分布式架构，再加上服务发现和集群化部署，避免了单点故障可能引起的业务故障。服务自动注册功能又使得系统可以实时发布，实现了系统7×24小时不间断服务。

③可伸缩：正是基于分布式架构高可用设计和动态路由支撑，使得应用对主机的启、停无感知，真正做到按需、随时分配资源。

④运维智能化：服务治理、DevOps实现了应用部署自动化，服务关系可视化，服务状态可控化，资源分配自动化，告警、预警智能化。