喬宏明+梁奐+姚文勝

編者按

自2015年李克強總理在政府工作報告中明確提出“互聯(lián)網(wǎng)+”行動計劃以來，“互聯(lián)網(wǎng)+”已逐漸深入應(yīng)用于各行各業(yè)中，如本期專題探討的“互聯(lián)網(wǎng)+現(xiàn)代農(nóng)業(yè)”、“互聯(lián)網(wǎng)+移動辦公”等，可以說，“互聯(lián)網(wǎng)+”正推動傳統(tǒng)產(chǎn)業(yè)的變革。當然，在此進程中仍有不少關(guān)鍵點值得進一步探討，包括物聯(lián)網(wǎng)、云計算等技術(shù)該如何融合創(chuàng)新，電信運營商怎樣借助“互聯(lián)網(wǎng)+”構(gòu)建微服務(wù)等。本期專題希望通過分析過去幾年“互聯(lián)網(wǎng)+”的相關(guān)技術(shù)研究和應(yīng)用成果，對其未來的發(fā)展方向進行展望。

【摘 要】為了探討互聯(lián)網(wǎng)化背景下運營商如何構(gòu)建微服務(wù)IT架構(gòu)，結(jié)合電信運營商IT的特點，分析了電信運營商在互聯(lián)網(wǎng)化背景下構(gòu)建微服務(wù)IT架構(gòu)的驅(qū)動力，并就其構(gòu)建微服務(wù)IT架構(gòu)可能面臨的挑戰(zhàn)進行探討，最后就其實施IT架構(gòu)微服務(wù)化給出了建議。

【關(guān)鍵詞】微服務(wù) 信息系統(tǒng) 運營商

1 引言

近三年來，“微服務(wù)”取代了“SOA”，成為國內(nèi)IT行業(yè)在IT架構(gòu)方面的研討熱點，諸多互聯(lián)網(wǎng)企業(yè)前期已經(jīng)做了大量的實踐。在互聯(lián)網(wǎng)化背景下，電信運營商也在探討能否將這一架構(gòu)引入運營商的IT領(lǐng)域[1]，用微服務(wù)架構(gòu)重構(gòu)IT應(yīng)用系統(tǒng)，從而更好地滿足企業(yè)對IT服務(wù)能力在靈活性和高效響應(yīng)方面的要求。

關(guān)于微服務(wù)架構(gòu)的研究和實踐在國外已經(jīng)開展了10多年的時間，根據(jù)該概念的提出者James Lewis和Martin Fowler的意見[2]，微服務(wù)架構(gòu)是一種架構(gòu)風格（microservice architectural style），某種意義上引用了Unix的設(shè)計原則，是一種將單一應(yīng)用開發(fā)為一組小服務(wù)（a suite of small services）的方法，每個小的服務(wù)都運行在自己的進程中，通過輕量級的機制（通常是一種HTTP資源API）互相通信。微服務(wù)架構(gòu)風格有如下9個特征，即：基于服務(wù)的組件化、圍繞業(yè)務(wù)能力組織團隊、“做產(chǎn)品”而不是“做項目”、“智能端點”與“啞管道”、“去中心化”治理、“去中心化”管理數(shù)據(jù)、“基礎(chǔ)設(shè)施”自動化、“容錯”設(shè)計、“演進式”設(shè)計等，本文后續(xù)的討論和分析將依照上述微服務(wù)架構(gòu)的特點進行陳述展開。

2 運營商構(gòu)建微服務(wù)架構(gòu)的驅(qū)動力

電信運營商對微服務(wù)架構(gòu)的研究和興趣主要有以下4個方面的原因：

（1）現(xiàn)有IT系統(tǒng)的痼疾希望通過微服務(wù)架構(gòu)得到緩解或解決

當前運營商業(yè)務(wù)形態(tài)和經(jīng)營管理模式日益復雜：業(yè)務(wù)形態(tài)方面，從傳統(tǒng)的通信服務(wù)向信息服務(wù)、內(nèi)容服務(wù)、互聯(lián)網(wǎng)金融、物聯(lián)網(wǎng)業(yè)務(wù)等轉(zhuǎn)型；經(jīng)營渠道方面，從傳統(tǒng)實體營業(yè)廳向多樣化電子渠道的轉(zhuǎn)移，從自有營業(yè)廳向外部電商、第三方伙伴渠道擴展；營銷活動方面，互聯(lián)網(wǎng)企業(yè)的各類玩法（流量包搶購、內(nèi)容限時免費、免月租卡搶購等）都在試水；經(jīng)營管理方面，依據(jù)國家政策進行了引入民營資本嘗試，在虛擬運營方面也進行了探索和實踐。

企業(yè)業(yè)務(wù)和管理的變革都需要IT系統(tǒng)予以支持，使支撐企業(yè)管理運營的IT系統(tǒng)日益復雜。當前中國電信運營商的轉(zhuǎn)型還沒有到盡頭，后續(xù)電信運營商將進一步擴展經(jīng)營手段，擴充生態(tài)圈，業(yè)務(wù)形態(tài)和商業(yè)模型都可能發(fā)生更大的變化。未來企業(yè)的發(fā)展需要更加靈活、快速響應(yīng)的IT支撐能力。

運營商傳統(tǒng)IT系統(tǒng)以單一系統(tǒng)（monolith）模式為主，其復雜度隨著各項功能的疊加也日益增加，擴展性、可靠性、可維護性越來越差。另一方面業(yè)務(wù)部門對需求的交付周期要求越來越短。單一系統(tǒng)架構(gòu)復雜度的提升和快速、靈活響應(yīng)需求的矛盾日益突出。根據(jù)電信行業(yè)IT系統(tǒng)某主要供應(yīng)商提供的一個案例[3]，某個僅僅需要短短十幾行代碼的需求，評估之后竟然需要9個星期才能上線，因為需要在9個不同的功能模塊中修改，并新增900多個測試用例用來做全量的回歸測試。近期部分運營商使用了一些互聯(lián)網(wǎng)技術(shù)和方案（與分庫分表、分布式緩存、公共服務(wù)平臺化等）優(yōu)化IT系統(tǒng)，但重點解決的是性能問題，系統(tǒng)本身的復雜度問題沒有得到解決。從實踐上看，前期采用SOA等架構(gòu)總體效果也不甚理想。

（2）運營商集約化管理的要求可以通過IT架構(gòu)微服務(wù)化更容易地落地

為更有效地應(yīng)對行業(yè)內(nèi)外的競爭，電信運營商近年來一直在加強集約化管理，與其相配套的，IT系統(tǒng)集約和集中一直在路上，三大運營商都在總部構(gòu)建了越來越多生產(chǎn)性質(zhì)的IT系統(tǒng)，且越來越多的服務(wù)能力（如物聯(lián)網(wǎng)業(yè)務(wù)支撐）采用了集中化部署的模式。

相對而言，省公司的IT系統(tǒng)集中相對進展緩慢，這一方面有管理方面的原因，也有技術(shù)方面的難度。如果省公司的IT系統(tǒng)能借助微服務(wù)架構(gòu)進行改造，實現(xiàn)相關(guān)服務(wù)能力的獨立部署、快速迭代，就可以為未來IT最終的集中集約奠定更堅實的技術(shù)基礎(chǔ)。

（3）微服務(wù)架構(gòu)可以為運營商開展IT自主研發(fā)奠定良好基礎(chǔ)

借鑒互聯(lián)網(wǎng)企業(yè)經(jīng)驗，運營商都在開展IT自主研發(fā)工作，有借助企業(yè)內(nèi)部的研發(fā)單位專職開展自主研發(fā)，也有鼓勵各個省公司自己組建小團隊的嘗試。很多自主研發(fā)工作都采用了新的系統(tǒng)或數(shù)據(jù)應(yīng)用做切入點，但都不可避免的要跟原有的IT系統(tǒng)有交互。目前運營商IT系統(tǒng)主要是外部第三方合作伙伴提供的，一般技術(shù)棧固化，自主研發(fā)團隊很難切入，從軟件工程的角度，把交互放到接口層更有利于雙方的獨立發(fā)展，如果現(xiàn)有第三方提供的核心系統(tǒng)能提供微服務(wù)化服務(wù)接口，實現(xiàn)契約驅(qū)動，就能為自主研發(fā)提供更大的助力。另一方面，IT團隊自主研發(fā)的系統(tǒng)，未來趨勢也是自主運營（DevOps），這也符合微服務(wù)“做產(chǎn)品”而不是“做項目”的典型特征，自主研發(fā)從技術(shù)架構(gòu)上采用微服務(wù)架構(gòu)，也有利于長期的發(fā)展。

（4）采用微服務(wù)IT架構(gòu)符合互聯(lián)網(wǎng)化技術(shù)演進的趨勢和企業(yè)長遠利益

當前微服務(wù)IT架構(gòu)的配套技術(shù)生態(tài)環(huán)境（如容器化技術(shù)、DevOps工具鏈、各種開發(fā)語言的框架、設(shè)計開發(fā)方法論等）已經(jīng)比較成熟，諸多互聯(lián)網(wǎng)企業(yè)和政府組織[1]（如亞馬遜、Netflix、英國衛(wèi)報、英國政府數(shù)字化服務(wù)中心）也驗證了微服務(wù)架構(gòu)在提高應(yīng)用交付速度的獨特優(yōu)勢?！癆PI經(jīng)濟”概念[4]的提出，標志著基于IT開放服務(wù)的業(yè)務(wù)生態(tài)已經(jīng)逐步成熟，其生態(tài)圈必定將從互聯(lián)網(wǎng)應(yīng)用領(lǐng)域逐步滲透到傳統(tǒng)企業(yè)的IT領(lǐng)域，而微服務(wù)架構(gòu)正是當前乃至未來支撐IT開放服務(wù)的核心技術(shù)架構(gòu)。具體到電信行業(yè)，電信管理論壇（TMF）是電信行業(yè)IT相關(guān)規(guī)范標準制定方面的權(quán)威組織，在其框架規(guī)范體系中，已經(jīng)在TMF6XX系列規(guī)范中將IT服務(wù)能力用REST風格的API進行了標準化，可見運營商IT系統(tǒng)的微服務(wù)化也已經(jīng)有了廣泛的共識和標準基礎(chǔ)，企業(yè)在這方面的投入未來會有顯著回報。

3 運營商實現(xiàn)IT架構(gòu)微服務(wù)化的風險

雖然運營商采用微服務(wù)IT架構(gòu)有顯著的驅(qū)動力，也是未來的發(fā)展趨勢，但短時間內(nèi)并不具備全面實現(xiàn)IT系統(tǒng)全面微服務(wù)化的條件，其面臨的主要風險包括兩個方面：

（1）采用微服務(wù)架構(gòu)面臨的一般風險

采用微服務(wù)架構(gòu)的應(yīng)用必須部署在分布式計算環(huán)境下，必須要面對分布式計算的復雜性，比如：分布式應(yīng)用開發(fā)的復雜性要考慮網(wǎng)絡(luò)因素對性能的影響、異步處理的難度、權(quán)衡服務(wù)粒度的大小等；為應(yīng)對可靠型風險增加，需要更強的容錯設(shè)計；要面對分布式環(huán)境下的負載均衡、故障難以定位、單點故障雪崩效應(yīng)的問題；要面對多個分布式應(yīng)用的協(xié)同問題；要面對分布式計算環(huán)境下數(shù)據(jù)一致性和處理性能方面的權(quán)衡等，這些分布式計算面臨的挑戰(zhàn)，微服務(wù)架構(gòu)都要處理。

此外，微服務(wù)架構(gòu)還有一些特定的技術(shù)難題，比如微服務(wù)架構(gòu)相比單體架構(gòu)意味著引入更多的系統(tǒng)實體，必然會帶來管理的復雜性。一般而言，微服務(wù)的數(shù)量會很大，在版本管理和服務(wù)間協(xié)作方面需要投入更多的關(guān)注。微服務(wù)的邊界控制和管理至關(guān)重要，這需要開發(fā)團隊對自己的產(chǎn)品和業(yè)務(wù)有足夠的了解，定義好服務(wù)契約，把握好耦合度。微服務(wù)架構(gòu)的良好運作需要更精細的監(jiān)控能力和手段，一般需要專有的平臺。

最后，微服務(wù)架構(gòu)的實施需要搭建一個技術(shù)生態(tài)環(huán)境，最主要是建立DevOps機制才能更好發(fā)揮微服務(wù)快速迭代、快速響應(yīng)需求的優(yōu)勢。為此，需要建立面向DevOps的開發(fā)方法和團隊文化；需要建立面向DevOps的技術(shù)平臺，比如服務(wù)接口管理、標準化的開發(fā)環(huán)境、自動化部署測試環(huán)境、企業(yè)內(nèi)共享的鏡像管理平臺、依賴包管理平臺等。上述技術(shù)平臺都有多種開源、閉源的解決方案，平臺本身的選型、安裝、管理維護（特別是采用微服務(wù)架構(gòu)的初期）也需要很大的管理、人員、設(shè)備資源投入。

（2）電信運營商在應(yīng)用微服務(wù)架構(gòu)時面臨的獨特挑戰(zhàn)

除了一般的風險，電信運營商由于自身行業(yè)及IT系統(tǒng)的特點，還要面臨一些特有的挑戰(zhàn)。

首先是微服務(wù)IT架構(gòu)與運營商現(xiàn)有IT應(yīng)用架構(gòu)差異很大，且主要由第三方合作伙伴提供，雙方都需要克服“路徑依賴”。對于眾多第三方合作伙伴，需要按照面向微服務(wù)架構(gòu)重構(gòu)IT的研發(fā)管理機制和相關(guān)配套工具，應(yīng)對從單一架構(gòu)應(yīng)用向微服務(wù)架構(gòu)遷移帶來的一系列問題[5]，乃至重新組織研發(fā)團隊。對于運營商，現(xiàn)有的單體應(yīng)用的維護管理組織、機制和流程更多是基于ITIL指導思想配置和指定的，相關(guān)職責劃分也一般參考了傳統(tǒng)應(yīng)用分層架構(gòu)，微服務(wù)IT架構(gòu)“去中心化治理、去中心化管理數(shù)據(jù)”的特點要求相應(yīng)的組織和職責也要調(diào)整，運維流程也需要在ITIL最佳實踐的基礎(chǔ)上優(yōu)化；運營商開展自主研發(fā)，需要多個第三方合作伙伴和自身研發(fā)隊伍在軟件開發(fā)流程和標準、研發(fā)測試環(huán)境、項目管理機制等方面進行協(xié)同，采用DevOps機制也意味著相關(guān)團隊人員能力、考核機制、管理流程必須做必要的調(diào)整。沒有足夠的內(nèi)外部驅(qū)動力，想改變這些路徑依賴非常困難。

另一方面，相比互聯(lián)網(wǎng)企業(yè)，電信業(yè)務(wù)的復雜度很高，特定場景對數(shù)據(jù)一致性的要求很高，不同運營單位的管理運營思路也可能有很大的差異，微服務(wù)的劃分雖然有標準組織的規(guī)范可供參考，但不可能直接拿來“開箱即用”，需要IT部門及業(yè)務(wù)部門協(xié)同，需要參與人員在業(yè)務(wù)領(lǐng)域、技術(shù)領(lǐng)域的個人能力和經(jīng)驗積累，無法一步到位得到最優(yōu)化的設(shè)計。

最后，傳統(tǒng)上對運營商的IT系統(tǒng)，穩(wěn)定運營和快速支撐是兩個主要的考核指標，穩(wěn)定運營的重要性往往更甚于快速支撐，對IT架構(gòu)進行全面的微服務(wù)化改造如果短期內(nèi)給客戶部門帶來的成效不顯著，往往難以在內(nèi)部獲得足夠的支持，從而難以開展改造工作。

4 運營商微服務(wù)架構(gòu)實施建議

綜上分析，運營商采用微服務(wù)IT架構(gòu)既有驅(qū)動力，也面臨一系列現(xiàn)實的風險，這一局面是有普遍性的：包括微服務(wù)架構(gòu)的提出者Ames Lewis和Martin Fowler在內(nèi)，很多微服務(wù)架構(gòu)布道者也提出，傳統(tǒng)的單體系統(tǒng)維護體系和人才能力已經(jīng)成型，要轉(zhuǎn)變成微服務(wù)架構(gòu)需要多方面的配合和深入的轉(zhuǎn)型，除非面對的是一個復雜到難以維系的單體應(yīng)用，否則不能輕易采用微服務(wù)架構(gòu)。對于單體應(yīng)用過于復雜、難以維護的問題，如果評估相關(guān)團隊能力具備，也可以優(yōu)先采用一些折中的方法（比如單體應(yīng)用自身的模塊化改造），而非強制用微服務(wù)架構(gòu)將系統(tǒng)進行“物理性”的分割。

總體而言，對于大型的復雜系統(tǒng)來說，微服務(wù)架構(gòu)是一種可適用的技術(shù)架構(gòu)。對運營商來說，其向微服務(wù)IT架構(gòu)的演進也有客觀的驅(qū)動力。運營商要構(gòu)建微服務(wù)IT架構(gòu)，有以下建議：

（1）對實施IT架構(gòu)微服務(wù)化轉(zhuǎn)型要有思想準備。微服務(wù)架構(gòu)的實施是一個長期摸索的過程，需要以為企業(yè)運營管理和業(yè)務(wù)運營提供價值為基礎(chǔ)，制定實施微服務(wù)架構(gòu)的效能評估指標，一方面期望得到領(lǐng)導層的長期支持，另一方面便于隨時自我評估，改進實施策略和方案?？紤]到當前的IT系統(tǒng)供應(yīng)商格局，在相當長時間內(nèi)將是傳統(tǒng)架構(gòu)和微服務(wù)架構(gòu)并存的形態(tài)，需要迭代演進，不能追求一蹴而就。

（2）技術(shù)基礎(chǔ)準備方面，要就微服務(wù)架構(gòu)下的一些技術(shù)決策點盡早給出明確的意見。比如微服務(wù)定義原則和管理標準、統(tǒng)一的服務(wù)版本管理策略和流程、統(tǒng)一的服務(wù)QoS/SLA實施方案（如流量控制、服務(wù)降級、防止雪崩的控制策略、熔斷標準、超市控制、優(yōu)先級方案、容錯方案等）、統(tǒng)一的通信方案（同步異步選擇、交互協(xié)議類型等）、統(tǒng)一的跨服務(wù)控制調(diào)用方案等。此外還要實現(xiàn)統(tǒng)一的基礎(chǔ)設(shè)施管理（如共用鏡像和依賴庫、網(wǎng)絡(luò)環(huán)境、服務(wù)日志標準化采集分析平臺、服務(wù)調(diào)用鏈標準化采集分析平臺等），明確依賴管理工具、配置管理工具、代碼審核工具、API定義管理工具，建立自動化測試、自動化部署、自動化監(jiān)測技術(shù)手段。

（3）生態(tài)環(huán)境準備方面，要從企業(yè)層面推進微服務(wù)化架構(gòu)不僅在IT，也在業(yè)務(wù)平臺、網(wǎng)絡(luò)平臺等各個層面的實踐，指定企業(yè)級的相關(guān)標準，以標準為引導。在企業(yè)內(nèi)部，需要結(jié)合自主研發(fā)逐步開展DevOps理念的宣貫，完善現(xiàn)有的基于ITIL的服務(wù)管理機制，使IT運維從“穩(wěn)態(tài)管理”向“穩(wěn)態(tài)管理”和“敏捷運營”并重轉(zhuǎn)變。需要結(jié)合微服務(wù)應(yīng)用的特點調(diào)整IT組織架構(gòu)和相應(yīng)的考核標準，并對人員技能結(jié)構(gòu)做相應(yīng)的調(diào)整。在自主研發(fā)能力有限的情況下，微服務(wù)架構(gòu)落地中，外部第三方合作伙伴的配合是成功的關(guān)鍵：這既有賴于各個省級層面的協(xié)調(diào)，也有賴于集團層面的推動和指導。面向外部第三方面合作伙伴，一方面需調(diào)整采購標準和考核要求來推動，另一方面也從雙方企業(yè)的長遠利益著手，明確IT架構(gòu)微服務(wù)化給第三方帶來的效益，拉動第三方合作伙伴主動求變。

在上述準備的基礎(chǔ)上，選擇好實施切入點也很重要。在具體的應(yīng)用切入點上，Infosys Limited的Nikhil Mohan和Ansoo Susan Thomas給出了很好的方法論和建議[6]，可供參考。

5 結(jié)束語

通過本文分析可知，電信運營商推進IT微服務(wù)化有客觀的驅(qū)動力，也面臨諸多風險因素，需要有打持久戰(zhàn)的準備，協(xié)同第三方合作伙伴共同探索。在實施微服務(wù)IT架構(gòu)前，需要從思想、技術(shù)、生態(tài)環(huán)境等多個方面進行考慮和準備，找準痛點、選好切入點，穩(wěn)步推進。

參考文獻：

[1] 孫盛婷，朱奕健. 基于運營商能力開放的能力編排及微服務(wù)架構(gòu)研究[J]. 工業(yè)和信息化教育， 2016（3）： 53-54

[2] James Lewis， Martin Flower. Microservices[EB/OL]. （2014-03-25）[2017-04-17]. https：//martinfowler.com/articles/microservices.html.

[3] 王華超. 新形勢下運營商移動業(yè)務(wù)經(jīng)營策略研究[J]. 移動通信， 2015，39（1）： 22-23.

[4] 藺海榮. ICT時代運營商電渠系統(tǒng)的研究與設(shè)計[J]. 移動通信， 2016，40（14）： 89-92

[5] 李林鋒. 華為實施微服務(wù)架構(gòu)的五大軍規(guī)[EB/OL]. （2016-08-29）[2017-04-17]. http：//chuansong.me/n/605616624542.

[6] 黃罡. App經(jīng)濟已停滯 API才能讓大數(shù)據(jù)釋放更多價值[EB/OL]. （2017-04-08）[2017-04-17]. http：//www.gog.cn/zonghe/system/2017/04/07/015570863.shtml.

[7] 蔣勇. 基于微服務(wù)架構(gòu)的基礎(chǔ)設(shè)施設(shè)計[J]. 軟件， 2016（37）： 94-95.

[8] 王健，李冬睿. 從單一模式系統(tǒng)架構(gòu)往微服務(wù)架構(gòu)遷移轉(zhuǎn)換技術(shù)研究[J]. 學科探索， 2016（27）： 44.

[9] 張清輝. 從SOA到微服務(wù)的技改之路[EB/OL]. （2016-11-09）[2017-04-17]. http：//www.infoq.com/cn/presentations/transformation-of-the-road-from-soa-to-micro-service-technical.

[10] Nikhil Mohan， Ansoo Susan Thomas. Transforming BSS/OSS Systems to Microservices Architecture[J]. TMForum， 2015（8）： 11-14.