如果在諸多熱門云計算技術中，諸如容器、微服務、DevOps、OpenStack 等，找出一個最火的方向，那么非微服務莫屬。盡管話題炙手可熱，但對傳統(tǒng)行業(yè)來說，微服務落地和方法論目前處于起步階段。
日前，拓撲社（微信：tobshe）聯(lián)合數(shù)人云發(fā)布了《微服務2017年報告》。本報告于2017年11月份展開，從驅動因素、落地現(xiàn)狀、和容器關系、架構體系、未來趨勢和落地方法論等方面對微服務進行了分析。
希望能夠為傳統(tǒng)企業(yè)微服務決策、規(guī)劃和實施提供依據(jù)和解決辦法。
在服務公開中，許多服務都可以被內部獨立進程所限制。如果其中任何一個服務需要增加某種功能，那么就必須縮小進程范圍。在微服務架構中，只需要在特定的某種服務中增加所需功能，而不影響整體進程。
我們發(fā)現(xiàn)傳統(tǒng)行業(yè)對IT效率的變革需求是微服務成長土壤,業(yè)務模式創(chuàng)新重塑導致系統(tǒng)更新頻繁、應用復雜度急劇升高，傳統(tǒng)架構不堪重負。微服務架構具有明顯的好處，尤其是在應對復雜業(yè)務系統(tǒng)的多變需求方面。
在本次調研企業(yè)中，每個月都要進行業(yè)務系統(tǒng)更新的比例占63%，只有不到20%的企業(yè)半年以上更新一次系統(tǒng)。
加快互聯(lián)網+步伐成為許多傳統(tǒng)企業(yè)的必然選擇。業(yè)務場景、用戶習慣和行為在迅速變化，許多傳統(tǒng)行業(yè)線上業(yè)務出現(xiàn)急速增長。
比如金融行業(yè)的移動支付、互聯(lián)網理財?shù)龋囍圃煨袠I(yè)的營銷、電商、售后服務等線上業(yè)務比例迅速提高。IT團隊業(yè)務開發(fā)、迭代都以每月、甚至每周來計，需要7*24小時響應，這些給系統(tǒng)開發(fā)和運維帶來極大挑戰(zhàn)。
在IT對業(yè)務的響應和支撐方面，不同行業(yè)所面臨的困擾略有不同，但總體差異不明顯。
根據(jù)調研顯示，系統(tǒng)支撐方面排在前四的難題分別為：系統(tǒng)復雜性越來越高（28%），運維管理復雜度高，打造一支全棧運維團隊困難（26%），線上訪問壓力大（19%），設備采購維護成本高（19%）。
在傳統(tǒng)單體或SOA架構下，應用如果頻繁升級更新，開發(fā)團隊非常痛苦。企業(yè)的業(yè)務應用經過多年IT建設，系統(tǒng)非常龐大，要改動其中任何一小部分，都需要重新部署整個應用，敏捷開發(fā)和快速交付無從談起。
傳統(tǒng)企業(yè)在長期的IT建設過程中，通常大量使用外包團隊，這導致采用的技術棧之間差異較大，統(tǒng)一管控和運維要求更高。需要運維7*24小時全天候值守、在線升級，并快速響應。
在此時脫穎而出的微服務技術，面對上述困惑幾乎渾身優(yōu)點：獨立開發(fā)、獨立部署、獨立發(fā)布，去中心化管理，支持高并發(fā)高可用，支持豐富技術棧，企業(yè)可以根據(jù)需要靈活技術選型。
1.微服務客戶畫像
微服務架構在企業(yè)的使用情況可以分為四個層次：初級使用者、輕度使用者、中度使用者、以及重度使用者。
初級使用者基本是傳統(tǒng)架構，獨立部署需求不突出，技術堆棧不成熟，需要較長的培育和成長期。
輕度使用的企業(yè)邊緣業(yè)務系統(tǒng)開始使用Spring Boot 或Spring Cloud等框架，但組件的使用尚不熟練。
中度使用者為使用Dubbo或Spring cloud時間較長，但還沒有做周邊配套的工具鏈。
重度使用者是那些走在微服務架構改造前沿，具備微服務規(guī)劃和體系，有自己研發(fā)實力的企業(yè)，通常是以技術見長的大型互聯(lián)網公司。
2.15% 左右的調研企業(yè)引入了SpringCloud、Dubbo等微服務主流開發(fā)框架。
此次調研中，6%的企業(yè)已經部分引入了Spring Cloud 開發(fā)框架，Spring Cloud 也被開發(fā)者認為是最好的開發(fā)框架。
另外，9%的受訪企業(yè)采用了 Dubbo 等其他微服務框架，也就是說引入了或考慮引入微服務架構的企業(yè)達15%。
此外，還有51%以上的企業(yè)在考慮往云原生方向轉型。這是由于企業(yè)數(shù)字化轉型背景下，IT要更好適應線上業(yè)務趨勢的必然要求。加上國家政策層面對云服務的支持，傳統(tǒng)企業(yè)云化是大勢所趨。
3.微服務四大技術優(yōu)勢受青睞
從IT技術發(fā)展趨勢看，無論硬件、軟件、還是基礎架構都在朝著輕量化的方向發(fā)展。微服務通過化整為零的概念，將復雜的IT部署分解成更小、更獨立的微服務。
相對傳統(tǒng)的建設方法，傳統(tǒng)企業(yè)更看重微服務如下四方面的優(yōu)勢：技術選型靈活，更輕松采用新架構和語言（28%）降低系統(tǒng)內部服務冗余，提升開發(fā)效率（27%）獨立部署（22%）更好的容錯機制（20%）
在涉及復雜項目時，和單體架構的對比中，微服務從多個角度顯示出了壓倒性的優(yōu)勢。
4.制造業(yè)開始發(fā)力、金融小試牛刀
這里所說制造業(yè)，是大制造的概念，包括制造、汽車、大型制造以及航空業(yè)等。從調研數(shù)據(jù)來看，這些行業(yè)引入Spring Cloud、Dubbo等微服務開發(fā)框架的占比略高于其他行業(yè)，超過15%。制造業(yè)開始初步嘗試微服務架構。
能看出制造業(yè)向“智造”轉型的影響，今天的制造業(yè)結合了物聯(lián)網、傳感器、云計算、大數(shù)據(jù)等技術，人工智能技術正在工業(yè)、汽車駕駛等領域應用。大量新興業(yè)務場景出現(xiàn)，服務變得復雜，產業(yè)的彎道超車帶來了明顯的微服務需求。
其次，需求明顯的為金融行業(yè)，包括銀行、保險、證券等。尤其是一些國有銀行、股份制銀行以及城商行等大行都走在架構改造的前列。
在自己的創(chuàng)新業(yè)務，如手機銀行、微信銀行、互聯(lián)網理財?shù)葮I(yè)務上試水微服務架構。在核心業(yè)務系統(tǒng)方面，則相當謹慎。一方面是由于監(jiān)管和政策的原因，另一方面，銀行開發(fā)體系龐大，IT架構變革將是一件非常復雜的事情。
5.微服務推進障礙
微服務不是完美架構，會帶來系統(tǒng)的各種復雜度，以及運維要求更高等諸多難點
微服務并不是一項橫空出世的技術，事實上MicroService的概念已經誕生多年。除了組件和技術不成熟，企業(yè)業(yè)務模式不急迫的因素外，微服務本身也有自己的劣勢。
本次調研，有近一半的企業(yè)會談到對微服務的顧慮。比如部署以后的復雜度，后期運維管理的不友好等等。對于團隊來說，搭建微服務架構上手難，運維效率低，運維成本高。
另外，還可能帶來團隊之間溝通上的沖突，微服務需要與DevOps同步推進。微服務被分割成一個個獨立的業(yè)務模塊后，服務間通信接口設計非常重要。如何科學地將系統(tǒng)部署到服務器上，保證各個服務高效運行，更是難點。
微服務推進過程中有許多障礙。對微服務自身復雜度的擔憂、缺少具備相關經驗的專家、難以招募專業(yè)人才和使用相關工具是三個最普遍的障礙。其中對微服務復雜度的顧慮，排名前三的是運維要求和成本高，分布式架構的網絡延遲、容錯等挑戰(zhàn)，以及較強的部署依賴性。
在接受調研的企業(yè)中，2017年在生產環(huán)境中采用Docker的比例為9%，測試環(huán)境使用達22%。而且規(guī)模越大的企業(yè)，尤其是服務器規(guī)模在500臺以上的，是Docker容器的主要采用者。
另外，正在考慮評估中的占到被調研企業(yè)的一半以上。企業(yè)的關注度急劇升高，Docker使用正在快速普及。
容器和微服務相輔相成，兩大技術成熟的時間點非常契合。容器技術的成熟為微服務提供了得天獨厚的客觀條件。輕量化的容器是微服務的最佳運行環(huán)境，微服務應用只有在容器環(huán)境下才能保障運維效率的提升。
同時，微服務應用架構對外在組件的管理會變得困難，需要用容器平臺去管理中間件，才能發(fā)揮出更大價值。
1.企業(yè)微服務架構改造需要包括周邊配套工具鏈在內的一整套微服務體系
采用微服務架構改造應用系統(tǒng)，不僅僅是選擇開發(fā)框架本身，還要建設一套完整的體系架構。既要實現(xiàn)應用模塊之間的解耦，還要實現(xiàn)統(tǒng)一管理。
微服務化體系，包括開發(fā)框架、以及周邊配套工具鏈和組件，比如服務注冊、服務發(fā)現(xiàn)、API網關、負載均衡、服務治理、配置中心、安全管理、與容器的結合、監(jiān)控管理等等。一整套的體系建設是微服務真正的難點所在。
落地過程中，受訪企業(yè)關注的功能包括，API網關（33%）、服務治理（27%）、配置中心（21%）、分布式任務調度（17%）、應用監(jiān)控與報警（11%）、高并發(fā)（7%）等。這些組件可以根據(jù)自身的業(yè)務特性選擇使用。
2.微服務落地方法論：咨詢+產品工具+實施
在IT建設中，企業(yè)都希望將開發(fā)人員的精力放在自身業(yè)務系統(tǒng)的開發(fā)上，而工具的整合和使用則主要借助外部供應商的力量來做。軟件外包商都有自己的發(fā)展歷程，迅速改變技術架構不太現(xiàn)實。
另外，傳統(tǒng)企業(yè)都有大量原有IT系統(tǒng)，掉頭和轉向不可能丟掉歷史包袱，全部推翻重新建設。因此，企業(yè)一方面有架構之痛，另一方面不得不總是在業(yè)務系統(tǒng)快速上線和新架構選擇之間平衡。
對于企業(yè)來說，最實際的微服務落地路徑是，首先納入微服務咨詢，引入外部行業(yè)技術專家角色，站在企業(yè)架構的總體高度，幫助企業(yè)進行微服務體系規(guī)劃，落地roadmap，然后借助一些產品和工具進行落地實施。
在本次調研中，有的企業(yè)鑒于微服務的優(yōu)勢和業(yè)務快速變化的需要，會在新項目建設時直接選擇微服務架構進行開發(fā)，落地方法也不例外。
3、企業(yè)踐行微服務的三種類型
目前微服務落地的企業(yè)可以分為：溫柔型的變革者、業(yè)務倒逼型的強硬者、觀望型的探索者。
具體來說，溫柔的變革者從邊緣非核心業(yè)務探索嘗試新興技術。漸進式實施、創(chuàng)新靈活多變業(yè)務是這類型客戶微服務切入的關鍵詞。也是大部分傳統(tǒng)企業(yè)在切入微服務時，選擇的路徑。
本次參與調研的企業(yè)多是如此，在切入微服務時，選擇了諸如測試流程、API網關、開發(fā)平臺升級、測試環(huán)境快速部署等非核心業(yè)務進行技術驗證。
業(yè)務倒逼型是那些企業(yè)核心業(yè)務系統(tǒng)在日常支撐中承受著巨大壓力，必須進行架構改造，否則業(yè)務運轉舉步維艱。觀望型的探索者，是那些出于業(yè)務考量，要看到行業(yè)標桿案例，明確收益和價值，以及技術風險和可靠性充分把握的情況下，才會投入資源開始改造。
4.微服務落地需要從上到下推動和密切團隊協(xié)同
微服務應用的構建依賴組織結構的變化，它按照業(yè)務，而不是技術來劃分組織，在推進過程中會受到從上到下的壓力，因此必須有決策層的支持和推動。同時，需要團隊更好的協(xié)同，小團隊作戰(zhàn)，打破團隊間的高墻，減少溝通成本。上了微服務的受訪企業(yè)對搭建一支敏捷團隊都感受很迫切。
預計兩年內服務網格技術將呈現(xiàn)爆發(fā)之勢
本次的受訪者中，有42%表示聽說過 ServiceMesh 這一新興技術理念，但只有6%的受訪者對該技術有過一些研究。
微服務帶來的復雜度讓企業(yè)頭疼，尤其是服務間通信，如何保證服務間通信的端到端性能和可靠性，催生了下一代微服務Service mesh。2017年，ServiceMesh 經過技術擁躉、技術社區(qū)和媒體的反復布道，迅速被業(yè)界了解。
Service Mesh 是服務間通信層，可以提供安全、快速、可靠的服務間通訊。在過去的一年中，Service Mesh 已經成為微服務技術棧里的一個關鍵組件，被譽為“下一代微服務”。
Conduit、Istio 等Service Mesh技術在市場上已形成激烈的競爭，國內外企業(yè)開始紛紛站隊。國外，一些有高負載業(yè)務流量的公司都在他們的生產應用里加入了Service Mesh。
國內前沿技術公司開始圍繞SpringCloud等開發(fā)體系，為客戶提供成熟的解決方案和工具產品。同時，探索基于 ServiceMesh 的新方案，積極擁抱Istio/Conduit。
當然對于傳統(tǒng)企業(yè)來說，技術的先進性是為了保障業(yè)務需求的快速變化和發(fā)展，而不是一味追求新興。受訪企業(yè)表示，一方面會主動關注新技術的最新動向，另一方面在考慮落地時，也要關注新技術的可靠性和有例可循，有無業(yè)界最佳實踐背書。
微服務的核心使命是簡化開發(fā)，提高IT系統(tǒng)對業(yè)務的支撐能力。通過本次調研，我們可以得出如下一些結論：
1.傳統(tǒng)行業(yè)新興業(yè)務對IT效率的變革需求，業(yè)務模式創(chuàng)新重塑要求IT快速響應，是今天微服務炙手可熱的主要驅動因素。從目前微服務落地的狀態(tài)預估有兩年左右的培育和成長期。
評估一家企業(yè)是否需要上微服務，主要考察這五大關鍵要素：數(shù)據(jù)量和業(yè)務復雜度，團隊規(guī)模，應對業(yè)務流量變化，是否需要足夠的容錯容災，以及功能重復度和差錯成本。
2. 實施微服務的理想技術條件包括：進程隔離、數(shù)據(jù)庫表隔離，以及通過公開接口訪問。
3. 微服務架構在企業(yè)的使用可以分為四個層次：初級使用者、輕度使用者、中度使用者，以及重度使用者。
以技術見長的大型互聯(lián)網公司首先引領了微服務的風潮，國內制造、金融等大型龍頭企業(yè)中也有佼佼者開始規(guī)劃微服務體系，且具備較強的研發(fā)實力。大部分企業(yè)還處在初步嘗試，不成體系，尋找技術和專家力量探討解決方案的階段。
4. 微服務和容器共生：容器和微服務相輔相成，天生一對。Docker的成熟，讓微服務推廣和落地更加可靠、方便。隨著Docker和微服務架構組件等相關技術的逐步成熟，微服務架構將逐步落地傳統(tǒng)企業(yè)。
5. 微服務落地方法論：微服務主要用來解決系統(tǒng)的復雜性問題，企業(yè)客戶對于如何實施微服務并不清晰，同時有諸多顧慮。受企業(yè)客戶青睞的落地方法是：微服務咨詢+產品工具+實施。
6. 微服務落地策略：微服務正成為許多企業(yè)構建應用時的首選。微服務并不缺乏受眾，有的企業(yè)將微服務用于新應用開發(fā)，有的關注將單體應用遷移到微服務架構。
微服務改造循序漸進，快速演化只會適得其反。另外，落地過程中注意開發(fā)和運維部門的協(xié)同，進行組織內管理創(chuàng)新。
