互聯(lián)網(wǎng)化背景下運(yùn)營(yíng)商構(gòu)建微服務(wù)IT架構(gòu)的探討

喬宏明+梁奐+姚文勝

編者按

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

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

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

1 引言

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

3 運(yùn)營(yíng)商實(shí)現(xiàn)IT架構(gòu)微服務(wù)化的風(fēng)險(xiǎn)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

5 結(jié)束語(yǔ)

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

參考文獻(xiàn)：

[1] 孫盛婷，朱奕健. 基于運(yùn)營(yíng)商能力開(kāi)放的能力編排及微服務(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] 王華超. 新形勢(shì)下運(yùn)營(yíng)商移動(dòng)業(yè)務(wù)經(jīng)營(yíng)策略研究[J]. 移動(dòng)通信， 2015，39（1）： 22-23.

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

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

[6] 黃罡. App經(jīng)濟(jì)已停滯 API才能讓大數(shù)據(jù)釋放更多價(jià)值[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ì)[J]. 軟件， 2016（37）： 94-95.

[8] 王健，李冬睿. 從單一模式系統(tǒng)架構(gòu)往微服務(wù)架構(gòu)遷移轉(zhuǎn)換技術(shù)研究[J]. 學(xué)科探索， 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.