郭濤

企業(yè)應(yīng)用規(guī)模日益龐大，

傳統(tǒng)架構(gòu)無(wú)法有效應(yīng)對(duì)敏捷性需求，

企業(yè)IT架構(gòu)亟待改變，

需要降低耦合度，提高運(yùn)維效率，

還要避免局部故障影響整體可用性。

伴隨云計(jì)算、容器（Docker）技術(shù)的發(fā)展，

微服務(wù)（Microservice）應(yīng)運(yùn)而生。

什么是微服務(wù)？

微服務(wù)架構(gòu)如何落地？

微服務(wù)的未來(lái)在哪里？

讓我們慢慢一步步梳理它的來(lái)龍去脈。

松耦合、自主化的微服務(wù)架構(gòu)

隨著云計(jì)算、Docker（容器）技術(shù)的發(fā)展，IT架構(gòu)在不斷演進(jìn)，傳統(tǒng)的單體應(yīng)用架構(gòu)已經(jīng)無(wú)法滿足業(yè)務(wù)敏捷性的需求。由于應(yīng)用規(guī)模日益龐大，架構(gòu)需要降低耦合度，同時(shí)提高運(yùn)維效率和降低成本，此外還要避免因局部故障可能對(duì)整體業(yè)務(wù)可用性造成的影響。

微服務(wù)的概念誕生于2012年。作為加快Web和移動(dòng)應(yīng)用程序開發(fā)進(jìn)程的一種方法，從2014年開始受到各方關(guān)注。本質(zhì)上講，微服務(wù)將單體應(yīng)用模塊功能進(jìn)行拆分，每個(gè)微服務(wù)單獨(dú)開發(fā)部署和運(yùn)維，可以有效提升開發(fā)運(yùn)維效率，保障整體可用性，實(shí)現(xiàn)持續(xù)集成與交付。

微服務(wù)是一種架構(gòu)風(fēng)格。一個(gè)大型復(fù)雜軟件應(yīng)用由一個(gè)或多個(gè)微服務(wù)組成，系統(tǒng)中的各個(gè)微服務(wù)可被獨(dú)立部署，各個(gè)微服務(wù)之間是松耦合的。每個(gè)微服務(wù)僅關(guān)注于完成一件任務(wù)并很好地完成該任務(wù)。在所有情況下，每個(gè)任務(wù)代表著一個(gè)小的業(yè)務(wù)能力。

微服務(wù)架構(gòu)是一種創(chuàng)建松散耦合且自主化服務(wù)的新型架構(gòu)風(fēng)格。從業(yè)界的實(shí)踐來(lái)看，微服務(wù)核心技術(shù)架構(gòu)主要包括以下幾個(gè)方面：進(jìn)程間通信、服務(wù)注冊(cè)/服務(wù)發(fā)現(xiàn)、負(fù)載均衡、配置管理、熔斷器、API網(wǎng)關(guān)。以微服務(wù)架構(gòu)的興起為標(biāo)志，DevOps、平臺(tái)即服務(wù) （PaaS）、容器和持續(xù)集成與交付 （CI/CD） 方法，正在幫助企業(yè)超越面向服務(wù)的架構(gòu) （SOA） 等傳統(tǒng)方式，實(shí)現(xiàn)更大規(guī)模的模塊化系統(tǒng)創(chuàng)建和管理。

SOA 的好處是可以創(chuàng)建具有彈性的分布式應(yīng)用，有效消除各類復(fù)雜的中央組件。然而，SOA與組織結(jié)構(gòu)高度耦合，該架構(gòu)能否獲得成功在很大程度上依賴于重新規(guī)劃后的組織結(jié)構(gòu)，以及設(shè)計(jì)該架構(gòu)的團(tuán)隊(duì)能力。有人認(rèn)為，SOA創(chuàng)建的并非是兼具松散耦合和自主化特點(diǎn)的系統(tǒng)，而是一個(gè)需要復(fù)雜基礎(chǔ)架構(gòu)的相對(duì)脆弱的系統(tǒng)。而且，早期的SOA實(shí)施會(huì)造成供應(yīng)商鎖定，因?yàn)閷Ｓ兄虚g件往往只專注于集中化邏輯與持久化治理。

相反，微服務(wù)架構(gòu)則在構(gòu)建應(yīng)用的每個(gè)步驟（從開發(fā)、部署到運(yùn)營(yíng)）中兌現(xiàn)了 SOA 的最初承諾，專注于簡(jiǎn)化技術(shù)，利用精簡(jiǎn)化的組件構(gòu)建復(fù)雜系統(tǒng)。該架構(gòu)通過(guò)基于異步HTTP或消息傳遞協(xié)議的簡(jiǎn)單、標(biāo)準(zhǔn)化的管道通信，取代集中化邏輯和集成基礎(chǔ)架構(gòu)（基于重量級(jí)、非標(biāo)準(zhǔn)化的平臺(tái)）。SOAP、XML 和其他重量級(jí)協(xié)議和數(shù)據(jù)格式將被輕量級(jí) JSON所取代。每項(xiàng)微服務(wù)都有自己的數(shù)據(jù)存儲(chǔ)，不需要集中化管理和持久化。

當(dāng)前主要的開源微服務(wù)框架包括Spring Cloud、Dubbo、gRPC等。我們以Spring Cloud為例來(lái)展開介紹。Spring Cloud是基于SpringBoot的一整套實(shí)現(xiàn)微服務(wù)的框架。它提供了微服務(wù)開發(fā)所需的配置管理、服務(wù)發(fā)現(xiàn)、斷路器、智能路由、微代理、控制總線、全局鎖、決策競(jìng)選、分布式會(huì)話和集群狀態(tài)管理等組件。更重要的是，Spring Cloud與Spring Boot框架一起使用，會(huì)讓用戶更方便地開發(fā)基于微服務(wù)架構(gòu)的云服務(wù)。SpringBoot旨在簡(jiǎn)化創(chuàng)建產(chǎn)品級(jí)的Spring應(yīng)用和服務(wù)，簡(jiǎn)化配置文件，使用嵌入式Web服務(wù)器，含有諸多開箱即用的微服務(wù)功能。

Spring Cloud目前在Java微服務(wù)領(lǐng)域具有統(tǒng)治地位，而且有強(qiáng)大的社區(qū)支持。近兩年，隨著組件生態(tài)的進(jìn)一步完善和生產(chǎn)案例的增加，Spring Cloud大有成為Java微服務(wù)框架的事實(shí)標(biāo)準(zhǔn)的趨勢(shì)。

但是作為一項(xiàng)開源技術(shù)，Spring Cloud得到大量開發(fā)者追捧的同時(shí)，也有自身的一些問(wèn)題需要使用者去解決。比如，部分周邊組件功能不完善。Spring Cloud的開發(fā)支持界面十分友好，開發(fā)人員接受度非常高，但是Spring Cloud的配置管理、服務(wù)治理、應(yīng)用發(fā)布等環(huán)節(jié)并不完善，需要通過(guò)周邊工具完善。

國(guó)內(nèi)PaaS廠商時(shí)速云在微服務(wù)治理方面早早做好了布局，研發(fā)出具有 Spring Cloud、 APM、 CSB、 Service Mesh 等主要能力的微服務(wù) 治理平臺(tái)，支持獨(dú)立部署在宿主機(jī) 系統(tǒng)， 或更加方便地通過(guò)時(shí)速云 PaaS 平臺(tái)進(jìn)行部署和管理。時(shí)速云對(duì) Spring Cloud 的核心組件進(jìn)行了深度定制和擴(kuò)展， 包括 Eureka、 Zuul、 ConfigServer、 Hys-trix、 Zipkin、 AuthServer 等。

國(guó)內(nèi)PaaS廠商MoPaaS認(rèn)為，微服務(wù)架構(gòu)就是將一個(gè)完整的應(yīng)用從數(shù)據(jù)存儲(chǔ)開始，垂直拆分成多個(gè)不同的服務(wù)，每個(gè)服務(wù)都能獨(dú)立部署、獨(dú)立維護(hù)、獨(dú)立擴(kuò)展，服務(wù)與服務(wù)間通過(guò)諸如RESTful API的方式互相調(diào)用。MoPaaS基于Spring Boot和Spring Cloud實(shí)現(xiàn)微服務(wù)架構(gòu)，并且各個(gè)模塊都是完全開源的。MoPaaS平臺(tái)提供注冊(cè)中心、配置中心、消息服務(wù)等組件可選，從而創(chuàng)建、編輯微服務(wù)；提供服務(wù)治理相關(guān)功能，包括服務(wù)查詢、對(duì)于服務(wù)狀態(tài)的展示、以拓?fù)鋱D直觀的展示微服務(wù)之間調(diào)用鏈、響應(yīng)時(shí)間關(guān)系等；支持啟用、禁用、分組等微服務(wù)管理功能；可以提供微服務(wù)的監(jiān)控、告警等功能，包括節(jié)點(diǎn)CPU、內(nèi)存等Metrics監(jiān)控與告警，以及各節(jié)點(diǎn)上的服務(wù)監(jiān)控與告警等。

企業(yè)如何過(guò)渡到微服務(wù)架構(gòu)

目前，一些制造企業(yè)，主要是汽車制造、大型裝備制造、航空業(yè)，以及金融行業(yè)的企業(yè)已經(jīng)在初步嘗試采用微服務(wù)架構(gòu)。

企業(yè)如果要向微服務(wù)架構(gòu)轉(zhuǎn)變過(guò)渡，應(yīng)該如何做呢？

在AWS中國(guó)區(qū)的網(wǎng)站上提供了關(guān)于微服務(wù)應(yīng)用的教程，其中一個(gè)例子是，使用微服務(wù)作為用戶應(yīng)用程序負(fù)載均衡器的目標(biāo)。用戶可以使用微服務(wù)架構(gòu)來(lái)構(gòu)造應(yīng)用程序，作為可以獨(dú)立開發(fā)和部署的服務(wù)。具體來(lái)說(shuō)，用戶可以在各EC2實(shí)例上安裝一個(gè)或多個(gè)這樣的服務(wù)，每個(gè)服務(wù)在不同端口上接受連接。用戶可以使用單個(gè)應(yīng)用程序負(fù)載均衡器將請(qǐng)求路由到應(yīng)用程序的所有服務(wù)。用戶將EC2實(shí)例注冊(cè)到目標(biāo)組時(shí)，可以多次注冊(cè)。對(duì)于每個(gè)服務(wù)，可使用該服務(wù)的端口注冊(cè)實(shí)例。

而紅帽公司認(rèn)為，若想成功采用微服務(wù)架構(gòu)，企業(yè)或組織就必須首先為其單體式架構(gòu)創(chuàng)建一個(gè)穩(wěn)固的基礎(chǔ)，然后必須考慮和建立模塊化、域邊界和基本分布式系統(tǒng)理論，以發(fā)揮微服務(wù)的全部?jī)?yōu)勢(shì)。此外，微服務(wù)還能為較復(fù)雜的系統(tǒng)創(chuàng)造更多優(yōu)勢(shì)，比如DevOps、PaaS、容器、服務(wù)復(fù)制和注冊(cè)、主動(dòng)監(jiān)控和警告等。

企業(yè)是否已經(jīng)為采用微服務(wù)做好了準(zhǔn)備？紅帽公司建議，企業(yè)可以從以下幾個(gè)方面進(jìn)行自查：是否構(gòu)建了結(jié)構(gòu)良好的單體式應(yīng)用，是否明確了將微服務(wù)用于滿足哪些特定需求，是否圍繞微服務(wù)架構(gòu)重新調(diào)整了團(tuán)隊(duì)結(jié)構(gòu)，是否采用了最佳DevOps和CI/CD實(shí)踐方法，是否明確界定了應(yīng)用的業(yè)務(wù)范圍，是否已經(jīng)實(shí)施了微服務(wù)編排和管理工具與流程等。

部署微服務(wù)，既需要協(xié)調(diào)一致、技能精湛的團(tuán)隊(duì)，還需要高效的管理工具。構(gòu)建一支采用扁平化組織結(jié)構(gòu)，具備靈活性、多功能和自主化的高效團(tuán)隊(duì)是成功應(yīng)用微服務(wù)的關(guān)鍵。

構(gòu)建高效率、高技能的團(tuán)隊(duì)需要圍繞業(yè)務(wù)功能，而非企業(yè)架構(gòu)來(lái)重新協(xié)調(diào)人員配置。例如，Amazon的“兩張披薩團(tuán)隊(duì)”原則，每組團(tuán)隊(duì)由8到10人組成，負(fù)責(zé)創(chuàng)建和維護(hù)其服務(wù)。此外，“康威定律”還指出，企業(yè)只能創(chuàng)造出與其組織結(jié)構(gòu)相仿的設(shè)計(jì)。例如，如果對(duì)一個(gè)團(tuán)隊(duì)按照開發(fā)、運(yùn)營(yíng)、質(zhì)保和安全幾個(gè)部分進(jìn)行劃分，則會(huì)對(duì)團(tuán)隊(duì)的業(yè)務(wù)靈活性造成一定的限制，并可能導(dǎo)致進(jìn)度延誤。因此，企業(yè)在過(guò)渡到微服務(wù)之前，應(yīng)先創(chuàng)立DevOps實(shí)踐，預(yù)先明確其通信策略，從而有效緩解或防范上述問(wèn)題的發(fā)生，避免創(chuàng)建失敗的SOA或非高效的微服務(wù)架構(gòu)。

2007年，紅帽公司曾針對(duì)客戶進(jìn)行過(guò)一項(xiàng)有關(guān)微服務(wù)應(yīng)用的調(diào)查，發(fā)現(xiàn)當(dāng)前微服務(wù)主要被用來(lái)重新架構(gòu)現(xiàn)有的應(yīng)用程序，而行業(yè)更喜歡多運(yùn)行、多技術(shù)、多框架的微服務(wù)。用戶普遍接受的微服務(wù)的六大益處可以概括為：持續(xù)集成（CI）/持續(xù)部署（CD）、敏捷性、更高的可伸縮性、更快的交付時(shí)間、更高的生產(chǎn)效率、更容易調(diào)試和維護(hù)。但同時(shí)也必須注意落地微服務(wù)可能面對(duì)的嚴(yán)峻挑戰(zhàn)，包括企業(yè)文化和組織結(jié)構(gòu)上的挑戰(zhàn)、微服務(wù)管理、診斷和監(jiān)控、時(shí)間和資源管理。

紅帽公司認(rèn)為，微服務(wù)架構(gòu)可以為企業(yè)帶來(lái)諸多優(yōu)勢(shì)，例如各種應(yīng)用組件的獨(dú)立可擴(kuò)展性，以及更快捷、更簡(jiǎn)便的軟件開發(fā)與維護(hù)。但是，微服務(wù)可能無(wú)法為所有團(tuán)隊(duì)或項(xiàng)目帶來(lái)同等的優(yōu)勢(shì)。過(guò)渡到微服務(wù)是一個(gè)循序漸進(jìn)的過(guò)程，僅重構(gòu)部分現(xiàn)有應(yīng)用（而非全面過(guò)渡）是切實(shí)可行的做法。為成功采用微服務(wù)架構(gòu)，企業(yè)必須首先根據(jù)現(xiàn)有平臺(tái)標(biāo)準(zhǔn)構(gòu)建和設(shè)計(jì)合理的應(yīng)用，然后根據(jù)需要將應(yīng)用重構(gòu)為微服務(wù)集合，以滿足業(yè)務(wù)需求，同時(shí)還要配以適當(dāng)?shù)娜藛T、流程和工具。

一句話，微服務(wù)將促進(jìn)更快的開發(fā)和部署，并讓企業(yè)擺脫長(zhǎng)期的技術(shù)鎖定，從而獲得業(yè)務(wù)發(fā)展和產(chǎn)品選擇的自由。

微服務(wù)的挑戰(zhàn)與未來(lái)

靈雀云認(rèn)為，傳統(tǒng)開發(fā)將面臨更加嚴(yán)峻的挑戰(zhàn)。

第一，研發(fā)成本高，主要體現(xiàn)在以下幾方面。代碼重復(fù)率高。在實(shí)際項(xiàng)目分工時(shí)，開發(fā)都是各自負(fù)責(zé)幾個(gè)功能，即便開發(fā)之間存在功能重疊，往往也會(huì)選擇自己實(shí)現(xiàn)，而不是類庫(kù)共享。主要原因是從技術(shù)架構(gòu)角度看，傳統(tǒng)垂直架構(gòu)的特點(diǎn)是本地API接口調(diào)用，不存在業(yè)務(wù)的拆分和互相調(diào)用，使用到什么功能就本地開發(fā)，非常方便，不需要過(guò)度依賴于其它功能模塊。從考核角度來(lái)看，共享很難推行，只需要對(duì)自己開發(fā)的模塊交付質(zhì)量負(fù)責(zé)，沒(méi)有義務(wù)為他人提供并維護(hù)公共類庫(kù)，這個(gè)非常耗費(fèi)成本?？绲赜?、跨開發(fā)小組協(xié)調(diào)很困難，業(yè)務(wù)團(tuán)隊(duì)可能跨地域研發(fā)，內(nèi)部通常也會(huì)分成多個(gè)開發(fā)小組，各開發(fā)小組之間的協(xié)調(diào)和溝通成本非常高。需求變更困難。代碼重復(fù)率變高之后，已有功能變更或者新需求加入都會(huì)非常困難。以充值繳費(fèi)功能為例，不同的充值渠道開發(fā)了相同的限額保護(hù)功能，當(dāng)限額保護(hù)功能發(fā)生變更之后，所有重復(fù)開發(fā)的限額保護(hù)功能都需要重新修改和測(cè)試，很容易出現(xiàn)修改不一致或者被遺漏，導(dǎo)致部分渠道充值功能正常，部分存在Bug的問(wèn)題。

第二，運(yùn)維效率低。在傳統(tǒng)的MVC架構(gòu)中，業(yè)務(wù)流程是由一長(zhǎng)串本地接口或者方法調(diào)用串聯(lián)起來(lái)的，臃腫而冗長(zhǎng)，而且往往由一個(gè)人負(fù)責(zé)開發(fā)和維護(hù)。隨著業(yè)務(wù)的發(fā)展和需求變化，本地代碼在不斷的迭代和變更，最后形成了一個(gè)個(gè)垂直的功能孤島，只有原來(lái)的開發(fā)者才理解接口調(diào)用關(guān)系和功能需求，一旦原有的開發(fā)者離職或者調(diào)到其他項(xiàng)目組，這些功能模塊的運(yùn)維就會(huì)變得非常困難。當(dāng)垂直應(yīng)用越來(lái)越多時(shí)，連架構(gòu)師都無(wú)法描述應(yīng)用間的架構(gòu)關(guān)系，隨著業(yè)務(wù)的發(fā)展和功能膨脹，這種架構(gòu)很容易發(fā)生“腐化”：測(cè)試、部署成本高，業(yè)務(wù)運(yùn)行在一個(gè)進(jìn)程中，因此系統(tǒng)中任何程序的改變，都需要對(duì)整個(gè)系統(tǒng)重新測(cè)試并部署；可伸縮性差，水平擴(kuò)展只能基于整個(gè)系統(tǒng)進(jìn)行擴(kuò)展，無(wú)法針對(duì)某一個(gè)功能模塊按需擴(kuò)展；可靠性差，某個(gè)應(yīng)用BUG，例如死循環(huán)、OOM等，會(huì)導(dǎo)致整個(gè)進(jìn)程宕機(jī)。

對(duì)于微服務(wù)的未來(lái)，UMCloud認(rèn)為，意識(shí)重于技術(shù)?？低▌t給我們的啟示：軟件系統(tǒng)的接口結(jié)構(gòu)會(huì)映射組織的溝通結(jié)構(gòu)，如果組織架構(gòu)不合理，就無(wú)法建立一個(gè)高效的系統(tǒng)架構(gòu)。一般在系統(tǒng)架構(gòu)調(diào)整時(shí)，要提前考慮相應(yīng)的組織架構(gòu)的調(diào)整，兩邊聯(lián)動(dòng)才能產(chǎn)生效果?？低▌t是近年流行的微服務(wù)架構(gòu)背后的組織原理。

Adrian Cockcorft是Netflix前云架構(gòu)師，在經(jīng)歷Netflix大規(guī)模微服務(wù)架構(gòu)的成功實(shí)踐后，他提議現(xiàn)代組織要打破谷倉(cāng)式職能壁壘，擁抱基于微服務(wù)的跨職能產(chǎn)品團(tuán)隊(duì)組織模式。

目前大部分研發(fā)組織仍嚴(yán)格劃分職能，職能間交集少，標(biāo)準(zhǔn)的研發(fā)流程以產(chǎn)品經(jīng)理和研發(fā)團(tuán)隊(duì) （包括用戶體驗(yàn)團(tuán)隊(duì)） 反復(fù)多次討論新功能需求開始，研發(fā)團(tuán)隊(duì)再將新功能用代碼實(shí)現(xiàn)，然后代碼被提交質(zhì)量保證團(tuán)隊(duì)進(jìn)行測(cè)試。這中間又涉及雙方的多次會(huì)議交互。測(cè)試通過(guò)后提交DBA和運(yùn)維上線，這中間又涉及和DBA、系統(tǒng)、網(wǎng)絡(luò)和存儲(chǔ)管理員的多次交互 （一般通過(guò)工單系統(tǒng)），整個(gè)流程緩慢。

康威法則告訴我們，軟件系統(tǒng)的接口結(jié)構(gòu)會(huì)反映組織的社交結(jié)構(gòu)。所以如果組織要真正轉(zhuǎn)型到微服務(wù)架構(gòu)，就必須圍繞微服務(wù)產(chǎn)品組織團(tuán)隊(duì)，基于DevOps 模式開展工作。組織內(nèi)不再以流水線方式設(shè)置產(chǎn)品經(jīng)理、用戶體驗(yàn)經(jīng)理、研發(fā)經(jīng)理等獨(dú)立職能角色。每個(gè)核心產(chǎn)品 （實(shí)現(xiàn)為微服務(wù)） 有一個(gè)經(jīng)理，即負(fù)責(zé)管理和監(jiān)督團(tuán)隊(duì)，也負(fù)責(zé)微服務(wù)軟件研發(fā)和交付的各個(gè)環(huán)節(jié)，從概念到發(fā)布。組織內(nèi)不再有獨(dú)立的運(yùn)維團(tuán)隊(duì)和職能細(xì)分，只有負(fù)責(zé)基礎(chǔ)設(shè)施產(chǎn)品 （IaaS/PaaS） 的平臺(tái)團(tuán)隊(duì)，提供自動(dòng)化和自助式平臺(tái) UI Portal或API，支持各個(gè)產(chǎn)品團(tuán)隊(duì)持續(xù)交付微服務(wù)。

UMCloud在容器云和微服務(wù)上的實(shí)踐表明，要在企業(yè)內(nèi)部實(shí)施微服務(wù)架構(gòu)，更多的是思維上的轉(zhuǎn)變。對(duì)于微服務(wù)架構(gòu)：技術(shù)上不是問(wèn)題，意識(shí)比工具重要。

一般提到微服務(wù)都離不開DevOps和Docker，理解微服務(wù)架構(gòu)是核心，DevOps和Docker則是工具和手段。UMCloud認(rèn)為，未來(lái)服務(wù)網(wǎng)格將會(huì)促進(jìn)微服務(wù)的大規(guī)模落地。如果我們能夠以透明化方式在服務(wù)與網(wǎng)絡(luò)之間插入一個(gè)基礎(chǔ)設(shè)施層，借此為運(yùn)營(yíng)人員提供必要的控制能力，同時(shí)幫助開發(fā)人員不必在其代碼當(dāng)中引入分布式系統(tǒng)帶來(lái)的專用解決方案，那么很多挑戰(zhàn)將迎刃而解。正如微服務(wù)架構(gòu)能夠幫助各功能團(tuán)隊(duì)實(shí)現(xiàn)彼此解耦一樣，服務(wù)網(wǎng)格能夠幫助運(yùn)營(yíng)人員從應(yīng)用程序功能開發(fā)與發(fā)布流程當(dāng)中“解耦”出來(lái)。Istio 項(xiàng)目即因此而生，它能夠以系統(tǒng)化方式將代理機(jī)制接入至網(wǎng)絡(luò)路徑當(dāng)中，從而將不同微服務(wù)轉(zhuǎn)化為綜合性服務(wù)網(wǎng)格。Istio項(xiàng)目提供了一種統(tǒng)一的方法配置多種必要的功能，使得運(yùn)營(yíng)人員能夠更加輕松地運(yùn)作高彈性水平服務(wù)網(wǎng)格。開發(fā)者在設(shè)計(jì)Istio項(xiàng)目時(shí)，應(yīng)充分考慮到網(wǎng)絡(luò)內(nèi)所運(yùn)行的各服務(wù)的透明性，允許團(tuán)隊(duì)隨著時(shí)間推移逐步采用Istio提供的各項(xiàng)功能。

微服務(wù)帶來(lái)的復(fù)雜度也讓很多企業(yè)頭疼，尤其是服務(wù)間通信。用戶對(duì)保證服務(wù)間通信的端到端性能和可靠性的需求，催生了下一代微服務(wù)Service Mesh。從2017年開始，Service Mesh漸漸為業(yè)內(nèi)人士所熟知。作為服務(wù)間的通信層，Service Mesh可以提供更加安全、快速、可靠的服務(wù)間通信。被譽(yù)為下一代微服務(wù)的Service Mesh可能迎來(lái)爆發(fā)。

企業(yè)相關(guān)技術(shù)

UMCloud

UMCloud作為國(guó)內(nèi)早期涉足容器和微服務(wù)領(lǐng)域的私有云計(jì)算服務(wù)商，有自己的一套微服務(wù)產(chǎn)品，為微服務(wù)建設(shè)提供從開發(fā)到運(yùn)行期的支持，主要包括以下七部分。

在微服務(wù)體系內(nèi)，API網(wǎng)關(guān)（Whale）提供給外部應(yīng)用訪問(wèn)內(nèi)部微服務(wù)體系的總?cè)肟诰W(wǎng)關(guān)。

統(tǒng)一配置管理中心（Hawk），為分布式系統(tǒng)中的基礎(chǔ)設(shè)施和微服務(wù)應(yīng)用提供集中化的外部配置支持。

治理中心（Coral）整合了微服務(wù)框架中的注冊(cè)中心和服務(wù)治理能力，提供一站式的治理服務(wù)。

批量任務(wù)（ Octopus）是UMCloud的彈性作業(yè)云產(chǎn)品，支持分布式定時(shí)作業(yè)、消息調(diào)度作業(yè)以及本地作業(yè)等，兼容已有Cron Table， 并提供靈活的開發(fā)框架，還可與UMCloud容器云平臺(tái)無(wú)縫融合。

微服務(wù)中間件平臺(tái)（Nemo）是當(dāng)前企業(yè)級(jí)中間件的一體化自服務(wù)平臺(tái)，幫助加速微服務(wù)應(yīng)用的構(gòu)建。

異步微服務(wù)平臺(tái)（Squid）用于高并發(fā)的業(yè)務(wù)場(chǎng)景，Squid將同步訪問(wèn)轉(zhuǎn)換成異步訪問(wèn)，將訪問(wèn)消息持久化保存防止丟失，實(shí)現(xiàn)微服務(wù)之間的異步調(diào)用。

企業(yè)級(jí)服務(wù)網(wǎng)格Service Mesh（Umesh）旨在降低微服務(wù)開發(fā)門檻，促進(jìn)微服務(wù)的規(guī)?；涞亍?/p>

紅帽

企業(yè)在向微服務(wù)架構(gòu)過(guò)渡的過(guò)程中，除了設(shè)計(jì)合理的軟件和組建高效團(tuán)隊(duì)之外，構(gòu)建高度可擴(kuò)展的架構(gòu)還需要適合的工具，主要包括服務(wù)注冊(cè)和發(fā)現(xiàn)工具，例如Kubernetes；容器化應(yīng)用的標(biāo)準(zhǔn)化打包格式，例如Docker，以及大規(guī)模復(fù)制容器的編排工具；CI持續(xù)集成環(huán)境創(chuàng)建工具，例如Jenkins或Shippable 推出的Docker and Kubernetes；依賴性解決方案，例如Nexus；故障切換和彈性工具，包括Hystrix和Ribbon等庫(kù)；服務(wù)監(jiān)控、提醒和事件工具，例如ELK（ElasticSearch、LogStash和Kibana）堆棧。紅帽O(jiān)penShift可提供滿足上述需求的可靠開源技術(shù)產(chǎn)品。

時(shí)速云

時(shí)速云是新一代容器云計(jì)算領(lǐng)域的企業(yè)，業(yè)務(wù)涵蓋容器PaaS平臺(tái)、DevOps、微服務(wù)治理、AIOps等領(lǐng)域。2018年1月，公司完成近億元B輪融資。時(shí)速云在微服務(wù)治理方面早早做好了布局，研發(fā)出具有Spring Cloud、APM、CSB、Service Mesh等主要能力的微服務(wù)治理平臺(tái)，支持獨(dú)立部署在宿主機(jī)系統(tǒng)，或更加方便地通過(guò)時(shí)速云PaaS平臺(tái)進(jìn)行部署和管理。

時(shí)速云對(duì)Spring Cloud的核心組件進(jìn)行了深度定制和擴(kuò)展，包括 Eureka、Zuul、ConfigServer、Hystrix、Zipkin、AuthServer等。

APM通過(guò)探針的方式，收集幾十種中間件的性能指標(biāo)，包括響應(yīng)時(shí)間、請(qǐng)求數(shù)量、負(fù)載情況、TPS等，自動(dòng)生成各個(gè)中間件之間的調(diào)用關(guān)系圖及相關(guān)數(shù)據(jù)。同時(shí)也可以查看每個(gè)服務(wù)的調(diào)用情況，包括每個(gè)請(qǐng)求的開始時(shí)間、路徑、響應(yīng)時(shí)間、服務(wù)地址、客戶端地址，并能追蹤到具體的代碼調(diào)用堆棧情況，方便對(duì)異常請(qǐng)求進(jìn)行迅速定位。

CSB相當(dāng)于微服務(wù)下的云服務(wù)總線，允許用戶發(fā)布自己的API，并定義版本和所屬的API組，或者訂閱其他用戶發(fā)布的API，支持API發(fā)布者生成API文檔。同時(shí)也可以通過(guò)CSB進(jìn)行協(xié)議轉(zhuǎn)換，比如WebService同Restful之間的轉(zhuǎn)換，可以讓客戶端使用Restful接口通過(guò)CSB 調(diào)用接入的SOAP服務(wù)。

靈雀云

靈雀云容器平臺(tái)使用微服務(wù)架構(gòu)輕松實(shí)現(xiàn)良好的可擴(kuò)展性，同時(shí)保證隨時(shí)可升級(jí)。靈雀云容器平臺(tái)可以作為一個(gè)容器應(yīng)用，易于部署和維護(hù)，輕松集成現(xiàn)有系統(tǒng)，或快速部署新系統(tǒng)。

靈雀云為用戶提供支持部署和管理微服務(wù)應(yīng)用，同時(shí)可便捷維護(hù)、部署和按需擴(kuò)容縮容微服務(wù)架構(gòu)。其特點(diǎn)在于：可伸縮性，輕松添加最常用服務(wù)的眾多實(shí)例，并刪除不經(jīng)常使用的服務(wù)實(shí)例，以保持運(yùn)行環(huán)境始終處于最佳狀態(tài)；可維護(hù)性，當(dāng)升級(jí)服務(wù)時(shí)，只需重新部署必要服務(wù)，而不影響整體的用戶體驗(yàn)；故障隔離，如果某個(gè)服務(wù)不可用，并不會(huì)影響系統(tǒng)的其他部分的使用功能，提供穩(wěn)定的應(yīng)用經(jīng)驗(yàn)；親和性，使用最適當(dāng)?shù)恼Z(yǔ)言或技術(shù)，開發(fā)目標(biāo)服務(wù)，實(shí)現(xiàn)目標(biāo)而不損害平臺(tái)的實(shí)用性。

靈雀云微服務(wù)基于容器，相對(duì)于基于虛擬機(jī)效率更高，資源的使用率更高。靈雀云基于幾年積累的技術(shù)優(yōu)勢(shì)打造的微服務(wù)產(chǎn)品，上層應(yīng)用和底層容器、基礎(chǔ)設(shè)施之間是打通的。

靈雀云微服務(wù)產(chǎn)品基于開源平臺(tái)，深度支持Spring Cloud微服務(wù)框架，可平滑遷移基于Spring Cloud的微服務(wù)應(yīng)用，構(gòu)建微服務(wù)架構(gòu)和管理平臺(tái)，同時(shí)不斷優(yōu)化和定制微服務(wù)組件，在管理成本和功能方面（比如熔斷、限流等）表現(xiàn)突出。