解構(gòu)微服務(wù)

郭濤

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

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

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

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

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

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

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

什么是微服務(wù)？

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

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

讓我們慢慢一步步梳理它的來龍去脈。

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

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

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

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

微服務(wù)架構(gòu)是一種創(chuàng)建松散耦合且自主化服務(wù)的新型架構(gòu)風(fēng)格。從業(yè)界的實(shí)踐來看，微服務(wù)核心技術(shù)架構(gòu)主要包括以下幾個方面：進(jìn)程間通信、服務(wù)注冊/服務(wù)發(fā)現(xiàn)、負(fù)載均衡、配置管理、熔斷器、API網(wǎng)關(guān)。以微服務(wù)架構(gòu)的興起為標(biāo)志，DevOps、平臺即服務(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è)計該架構(gòu)的團(tuán)隊能力。有人認(rèn)為，SOA創(chuàng)建的并非是兼具松散耦合和自主化特點(diǎn)的系統(tǒng)，而是一個需要復(fù)雜基礎(chǔ)架構(gòu)的相對脆弱的系統(tǒng)。而且，早期的SOA實(shí)施會造成供應(yīng)商鎖定，因?yàn)閷Ｓ兄虚g件往往只專注于集中化邏輯與持久化治理。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

UMCloud

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

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

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

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

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

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

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

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

紅帽

企業(yè)在向微服務(wù)架構(gòu)過渡的過程中，除了設(shè)計合理的軟件和組建高效團(tuán)隊之外，構(gòu)建高度可擴(kuò)展的架構(gòu)還需要適合的工具，主要包括服務(wù)注冊和發(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等庫；服務(wù)監(jiān)控、提醒和事件工具，例如ELK（ElasticSearch、LogStash和Kibana）堆棧。紅帽O(jiān)penShift可提供滿足上述需求的可靠開源技術(shù)產(chǎn)品。

時速云

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

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

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

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

靈雀云

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

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

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

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