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實現了應用部署自動化，服務關系可視化，服務狀態可控化，資源分配自動化，告警、預警智能化。