年終盤點篇：2017年度微服務調查報告出爐

【IT168 調查報告】若是在諸多熱門雲計算技術中，諸如容器、微服務、DevOps、OpenStack 等，找出一個最火的方向，那麼非微服務莫屬。儘管話題煊赫一時，但對傳統行業來講，微服務落地和方法論目前處於起步階段。

　　本報告於2017年11月份展開，從驅動因素、落地現狀、和容器關係、架構體系、將來趨勢和落地方法論等方面對微服務進行了分析。但願可以爲傳統企業微服務決策、規劃和實施提供依據和解決辦法。

　　1、驅動因素

　　傳統行業對IT效率的變革需求是微服務成長土壤,業務模式創新重塑致使系統更新頻繁、應用複雜度急劇升高，傳統架構不堪重負。

　　微服務架構具備明顯的好處，尤爲是在應對複雜業務系統的多變需求方面。在本次調研企業中，每月都要進行業務系統更新的比例佔63%，只有不到20%的企業半年以上更新一次系統。

　　加快互聯網+步伐成爲許多傳統企業的必然選擇。業務場景、用戶習慣和行爲在迅速變化，許多傳統行業線上業務出現急速增加。

　　好比金融行業的移動支付、互聯網理財等，汽車製造行業的營銷、電商、售後服務等線上業務比例迅速提升。IT團隊業務開發、迭代都以每個月、甚至每週來計，須要7*24小時響應，這些給系統開發和運維帶來極大挑戰。

　　在IT對業務的響應和支撐方面，不一樣行業所面臨的困擾略有不一樣，但整體差別不明顯。調研顯示，系統支撐方面排在前四的難題分別爲：系統複雜性愈來愈高（28%），運維管理複雜度高，打造一支全棧運維團隊困難（26%），線上訪問壓力大（19%），設備採購維護成本高（19%）。

　　在傳統單體或SOA架構下，應用若是頻繁升級更新，開發團隊很是痛苦。企業的業務應用通過多年IT建設，系統很是龐大，要改動其中任何一小部分，都須要從新部署整個應用，敏捷開發和快速交付無從談起。

　　傳統企業在長期的IT建設過程當中，一般大量使用外包團隊，這致使採用的技術棧之間差別較大，統一管控和運維要求更高。須要運維7*24小時全天候值守、在線升級，並快速響應。

　　在此時脫穎而出的微服務技術，面對上述困惑幾乎渾身優勢：獨立開發、獨立部署、獨立發佈，去中心化管理，支持高併發高可用，支持豐富技術棧，企業能夠根據須要靈活技術選型。

　　2、微服務落地現狀

　　一、微服務客戶畫像

　　微服務架構在企業的使用狀況能夠分爲四個層次：初級使用者、輕度使用者、中度使用者、以及重度使用者。初級使用者基本是傳統架構，獨立部署需求不突出，技術堆棧不成熟，須要較長的培育和成長期。輕度使用的企業邊緣業務系統開始使用Spring Boot 或Spring Cloud等框架，但組件的使用尚不熟練。

　　中度使用者爲使用Dubbo或Spring cloud時間較長，但尚未作周邊配套的工具鏈。重度使用者是那些走在微服務架構改造前沿，具有微服務規劃和體系，有本身研發實力的企業，一般是以技術見長的大型互聯網公司。

　　二、15% 左右的調研企業引入了SpringCloud、Dubbo等微服務主流開發框架

　　這次調研中，6%的企業已經部分引入了Spring Cloud 開發框架，Spring Cloud 也被開發者認爲是最好的開發框架。另外，9%的受訪企業採用了 Dubbo 等其餘微服務框架，也就是說引入了或考慮引入微服務架構的企業達15%。

　　此外，還有51%以上的企業在考慮往雲原生方向轉型。這是因爲企業數字化轉型背景下，IT要更好適應線上業務趨勢的必然要求。加上國家政策層面對雲服務的支持，傳統企業雲化是大勢所趨。

　　三、微服務四大技術優點受青睞

　　從IT技術發展趨勢看，不管硬件、軟件、仍是基礎架構都在朝着輕量化的方向發展。微服務經過化整爲零的概念，將複雜的IT部署分解成更小、更獨立的微服務。

　　相對傳統的建設方法，傳統企業更看重微服務以下四方面的優點：技術選型靈活，更輕鬆採用新架構和語言（28%）下降系統內部服務冗餘，提高開發效率（27%）獨立部署（22%）更好的容錯機制（20%）

　　在涉及複雜項目時，和單體架構的對比中，微服務從多個角度顯示出了壓倒性的優點。

　　四、製造業開始發力、金融小試牛刀

　　這裏所說製造業，是大製造的概念，包括製造、汽車、大型製造以及航空業等。這些行業往引入Spring Cloud、Dubbo等微服務開發框架的企業佔比約爲10%。製造業開始初步嘗試微服務架構。

　　能看出製造業向「智造」轉型的影響，今天的製造業結合了物聯網、傳感器、雲計算、大數據等技術，人工智能技術正在工業、汽車駕駛等領域應用。大量新興業務場景出現，服務變得複雜，產業的彎道超車帶來了明顯的微服務需求。

　　其次，需求明顯的爲金融行業，包括銀行、保險、證券等。尤爲是一些國有銀行、股份制銀行以及城商行等大行都走在架構改造的前列。在本身的創新業務，如手機銀行、微信銀行、互聯網理財等業務上試水微服務架構。在覈心業務系統方面，則至關謹慎。一方面是因爲監管和政策的緣由，另外一方面，銀行開發體系龐大，IT架構變革將是一件很是複雜的事情。

　　五、微服務推動障礙

　　微服務不是完美架構，會帶來系統的各類複雜度，以及運維要求更高等諸多難點

　　微服務並非一項橫空出世的技術，事實上MicroService的概念已經誕生多年。除了組件和技術不成熟，企業業務模式不急迫的因素外，微服務自己也有本身的劣勢。

　　本次調研，有近一半的企業會談到對微服務的顧慮。好比部署之後的複雜度，後期運維管理的不友好等等。對於團隊來講，搭建微服務架構上手難，運維效率低，運維成本高。另外，還可能帶來團隊之間溝通上的衝突，微服務須要與DevOps同步推動。微服務被分割成一個個獨立的業務模塊後，服務間通訊接口設計很是重要。如何科學地將系統部署到服務器上，保證各個服務高效運行，更是難點。

　　微服務推動過程當中有許多障礙。對微服務自身複雜度的擔心、缺乏具有相關經驗的專家、難以招募專業人才和使用相關工具是三個最廣泛的障礙。其中對微服務複雜度的顧慮，排名前三的是運維要求和成本高，分佈式架構的網絡延遲、容錯等挑戰，以及較強的部署依賴性。

　　3、Docker與微服務

　　在接受調研的企業中，2017年在生產環境中採用Docker的比例爲9%，測試環境使用達22%。並且規模越大的企業，尤爲是服務器規模在500臺以上的，是Docker容器的主要採用者。另外，正在考慮評估中的佔到被調研企業的一半以上。企業的關注度急劇升高，Docker使用正在快速普及。

　　容器和微服務相輔相成，兩大技術成熟的時間點很是契合。容器技術的成熟爲微服務提供了得天獨厚的客觀條件。輕量化的容器是微服務的最佳運行環境，微服務應用只有在容器環境下才能保障運維效率的提高。同時，微服務應用架構對外在組件的管理會變得困難，須要用容器平臺去管理中間件，才能發揮出更大價值。

　　4、微服務化是一個體系，從架構、工具到團隊協同

　　一、 企業微服務架構改造須要包括周邊配套工具鏈在內的一整套微服務體系

　　採用微服務架構改造應用系統，不只僅是選擇開發框架自己，還要建設一套完整的體系架構。既要實現應用模塊之間的解耦，還要實現統一管理。

　　微服務化體系，包括開發框架、以及周邊配套工具鏈和組件，好比服務註冊、服務發現、API網關、負載均衡、服務治理、配置中心、安全管理、與容器的結合、監控管理等等。一整套的體系建設是微服務真正的難點所在。

　　落地過程當中，受訪企業關注的功能包括，API網關（33%）、服務治理（27%）、配置中心（21%）、分佈式任務調度（17%）、應用監控與報警（11%）、高併發（7%）等。這些組件能夠根據自身的業務特性選擇使用。

　　二、微服務落地方法論：諮詢+產品工具+實施

　　在IT建設中，企業都但願將開發人員的精力放在自身業務系統的開發上，而工具的整合和使用則主要藉助外部供應商的力量來作。軟件外包商都有本身的發展歷程，迅速改變技術架構不太現實。

　　另外，傳統企業都有大量原有IT系統，掉頭和轉向不可能丟掉歷史包袱，所有推翻從新建設。所以，企業一方面有架構之痛，另外一方面不得不老是在業務系統快速上線和新架構選擇之間平衡。

　　對於企業來講，最實際的微服務落地路徑是，首先歸入微服務諮詢，引入外部行業技術專家角色，站在企業架構的整體高度，幫助企業進行微服務體系規劃，落地roadmap，而後藉助一些產品和工具進行落地實施。

　　在本次調研中，有的企業鑑於微服務的優點和業務快速變化的須要，會在新項目建設時直接選擇微服務架構進行開發，落地方法也不例外。

　　三、企業踐行微服務的三種類型

　　目前微服務落地的企業能夠分爲：溫柔型的變革者、業務倒逼型的強硬者、觀望型的探索者。

　　具體來講，溫柔的變革者從邊緣非核心業務探索嘗試新興技術。漸進式實施、創新靈活多變業務是這類型客戶微服務切入的關鍵詞。也是大部分傳統企業在切入微服務時，選擇的路徑。

　　本次參與調研的企業可能是如此，在切入微服務時，選擇了諸如測試流程、API網關、開發平臺升級、測試環境快速部署等非核心業務進行技術驗證。

　　業務倒逼型是那些企業核心業務系統在平常支撐中承受着巨大壓力，必須進行架構改造，不然業務運轉舉步維艱。觀望型的探索者，是那些出於業務考量，要看到行業標杆案例，明確收益和價值，以及技術風險和可靠性充分把握的狀況下，纔會投入資源開始改造。

　　4.微服務落地須要從上到下推進和密切團隊協同

　　微服務應用的構建依賴組織結構的變化，它按照業務，而不是技術來劃分組織，在推動過程當中會受到從上到下的壓力，所以必須有決策層的支持和推進。同時，須要團隊更好的協同，小團隊做戰，打破團隊間的高牆，減小溝通成本。上了微服務的受訪企業對搭建一支敏捷團隊都感覺很迫切。

　　5、Service Mesh下一代微服務搶灘登錄

　　預計兩年內服務網格技術將呈現爆發之勢

　　本次的受訪者中，有42%表示據說過 ServiceMesh 這一新興技術理念，但只有6%的受訪者對該技術有過一些研究。

　　微服務帶來的複雜度讓企業頭疼，尤爲是服務間通訊，如何保證服務間通訊的端到端性能和可靠性，催生了下一代微服務Service mesh。2017年，ServiceMesh 通過技術擁躉、技術社區和媒體的反覆佈道，迅速被業界瞭解。

　　Service Mesh 是服務間通訊層，能夠提供安全、快速、可靠的服務間通信。在過去的一年中，Service Mesh 已經成爲微服務技術棧裏的一個關鍵組件，被譽爲「下一代微服務」。

　　Conduit、Istio 等Service Mesh技術在市場上已造成激烈的競爭，國內外企業開始紛紛站隊。國外，一些有高負載業務流量的公司都在他們的生產應用里加入了Service Mesh。國內前沿技術公司開始圍繞SpringCloud等開發體系，爲客戶提供成熟的解決方案和工具產品。同時，探索基於 ServiceMesh 的新方案，積極擁抱Istio/Conduit。

　　固然對於傳統企業來講，技術的先進性是爲了保障業務需求的快速變化和發展，而不是一味追求新興。受訪企業表示，一方面會主動關注新技術的最新動向，另外一方面在考慮落地時，也要關注新技術的可靠性和有例可循，有無業界最佳實踐背書。

　　6、結論

　　微服務的核心使命是簡化開發，提升IT系統對業務的支撐能力。經過本次調研，咱們能夠得出以下一些結論：

　　1.傳統行業新興業務對IT效率的變革需求，業務模式創新重塑要求IT快速響應，是今天微服務煊赫一時的主要驅動因素。從目前微服務落地的狀態預估有兩年左右的培育和成長期。

　　評估一家企業是否須要上微服務，主要考察這五大關鍵要素：數據量和業務複雜度，團隊規模，應對業務流量變化，是否須要足夠的容錯容災，以及功能重複度和差錯成本。

　　2. 實施微服務的理想技術條件包括：進程隔離、數據庫表隔離，以及經過公開接口訪問。

　　3. 微服務架構在企業的使用能夠分爲四個層次：初級使用者、輕度使用者、中度使用者，以及重度使用者。

　　以技術見長的大型互聯網公司首先引領了微服務的風潮，國內製造、金融等大型龍頭企業中也有佼佼者開始規劃微服務體系，且具有較強的研發實力。大部分企業還處在初步嘗試，不成體系，尋找技術和專家力量探討解決方案的階段。

　　4. 微服務和容器共生：容器和微服務相輔相成，天生一對。Docker的成熟，讓微服務推廣和落地更加可靠、方便。隨着Docker和微服務架構組件等相關技術的逐步成熟，微服務架構將逐步落地傳統企業。

　　5. 微服務落地方法論：微服務主要用來解決系統的複雜性問題，企業客戶對於如何實施微服務並不清晰，同時有諸多顧慮。受企業客戶青睞的落地方法是：微服務諮詢+產品工具+實施。

　　6. 微服務落地策略：微服務正成爲許多企業構建應用時的首選。微服務並不缺少受衆，有的企業將微服務用於新應用開發，有的關注將單體應用遷移到微服務架構。微服務改造按部就班，快速演化只會拔苗助長。另外，落地過程當中注意開發和運維部門的協同，進行組織內管理創新。

　　關於調研對象

　　本次調研咱們總計收到了來自182家企業受訪者的調研問卷，並現場調研部分受訪企業。覆蓋製造/航空、金融、互聯網、地產、交通物流和零售等行業，受訪者包括CIO、CTO等IT高管，及開發、基礎架構部門IT人員。