為什么大公司一定要使用微服務(wù)？

樂(lè)康居 2020-01-21

展開(kāi)全文

這幾年在 Java 工程師招聘時(shí)，會(huì)看到很多人的簡(jiǎn)歷都寫(xiě)著使用了 Spring Cloud 做微服務(wù)實(shí)現(xiàn)，使用 Docker 做自動(dòng)化部署，并且也會(huì)把這些做為自己的亮點(diǎn)。

而比較有趣的這其中以小公司出來(lái)的人為絕大多數(shù)，大的公司出來(lái)的人簡(jiǎn)歷上倒是很少提這些東西。

對(duì)于我自己來(lái)說(shuō)，從 2015 年就開(kāi)始關(guān)注這一塊，看過(guò)馬丁·福勒最開(kāi)始的關(guān)于微服務(wù)的論文、也看過(guò)不少對(duì)微服務(wù)的論證的英文文章和書(shū)，也研究過(guò) Spring Cloud、Sofa 等開(kāi)源實(shí)現(xiàn)以及 Service Mesh。

考慮到我們公司研發(fā)團(tuán)隊(duì)人力不足、基礎(chǔ)設(shè)施不完善，當(dāng)初是沒(méi)有推行微服務(wù)的。

但隨著看到上述的那種簡(jiǎn)歷越來(lái)越多，有時(shí)候我也會(huì)疑問(wèn)：難道真的不用微服務(wù)就落后了嗎？公司的同事如果不掌握這些就真的沒(méi)有競(jìng)爭(zhēng)力了嗎。

而隨著最近公司業(yè)務(wù)的逐步提升，研發(fā)人員越來(lái)越多，借著在梳理公司的微服務(wù)落地計(jì)劃時(shí)，也梳理了一下微服務(wù)的相關(guān)知識(shí)點(diǎn)，也是本文的主要內(nèi)容。

主要從以下幾個(gè)方面跟大家分享：

微服務(wù)是什么
為什么要采用微服務(wù)
微服務(wù)架構(gòu)
架構(gòu)設(shè)計(jì)模式
服務(wù)拆分
微服務(wù)框架

開(kāi)篇之前先聲明我對(duì)微服務(wù)的幾點(diǎn)態(tài)度：

架構(gòu)模式有很多，微服務(wù)不是唯一的選擇也不是什么銀彈。國(guó)內(nèi)絕大多數(shù)中小公司引入微服務(wù)都是在盲目追新，也能看出做此種技術(shù)選型的工程師基礎(chǔ)架構(gòu)素質(zhì)的不足。
“你必須長(zhǎng)的足夠高才能使用微服務(wù)”。微服務(wù)基礎(chǔ)設(shè)施，尤其是容器技術(shù)、自動(dòng)化部署、自動(dòng)化測(cè)試這些不完備，微服務(wù)形同虛設(shè)，不會(huì)帶來(lái)什么質(zhì)的提升。
微服務(wù)架構(gòu)的關(guān)鍵不在于具體的實(shí)現(xiàn)，而在于如何合理地劃分服務(wù)邊界以及組織架構(gòu)是否相匹配。不考慮研發(fā)團(tuán)隊(duì)的規(guī)模和組成就盲目上微服務(wù)是不良的技術(shù)選型。
Spring Boot 是 Spring 全家桶的上層封裝，并不是什么嶄新的技術(shù)，也不是什么值得成為自己殺手锏的技術(shù)。
Spring Cloud 中 Spring Cloud Netflix 的組件是經(jīng)過(guò)生產(chǎn)環(huán)境驗(yàn)證的，其他的則建議慎重選擇。

微服務(wù)是什么

微服務(wù)起源于 2005 年 Peter Rodgers 博士在云端運(yùn)算博覽會(huì)提出的微 Web 服務(wù)（Micro-Web-Service），根本思想類(lèi)似于 Unix 的管道設(shè)計(jì)理念。

2014 年，由 Martin Fowler 與 James Lewis 共同提出了微服務(wù)的概念，定義了微服務(wù)架構(gòu)風(fēng)格是一種通過(guò)一套小型服務(wù)來(lái)開(kāi)發(fā)單個(gè)應(yīng)用的方法，每個(gè)服務(wù)運(yùn)行在自己的進(jìn)程中，并通過(guò)輕量級(jí)的機(jī)制進(jìn)行通訊（HTTP API）。

關(guān)鍵的三點(diǎn)是：

small
automated
lightweight

對(duì)比 SOA，微服務(wù)可以看做是 SOA 的子集，是輕量級(jí)的 SOA，粒度更細(xì)的服務(wù)，獨(dú)立進(jìn)程、數(shù)據(jù)分離，更注重敏捷、持續(xù)交付、DevOps 以及去中心化實(shí)踐。

其共同的架構(gòu)原理：

單一職責(zé)
關(guān)注分離：控制與邏輯相分離
模塊化和分而治之

特點(diǎn)：

用服務(wù)進(jìn)行組件化
圍繞業(yè)務(wù)能力進(jìn)行組織
是產(chǎn)品而非項(xiàng)目
端點(diǎn)智能化和啞管道: 控制邏輯都在端點(diǎn)，管道僅僅是傳輸
全自動(dòng)化部署
語(yǔ)言和數(shù)據(jù)的去中心化控制
面向失敗設(shè)計(jì)
漸進(jìn)式設(shè)計(jì)

綜合來(lái)看，其優(yōu)缺點(diǎn)如下：

優(yōu)點(diǎn)：模塊的強(qiáng)邊界；獨(dú)立部署；技術(shù)選型的多樣性。
缺點(diǎn)：分布式帶來(lái)編程復(fù)雜度，遠(yuǎn)程調(diào)用的消耗；舍棄強(qiáng)一致性，實(shí)現(xiàn)最終一致性；操作復(fù)雜性要求有一個(gè)成熟的運(yùn)維團(tuán)隊(duì)或者運(yùn)維基礎(chǔ)設(shè)施。

為什么要采用微服務(wù)

是否選擇微服務(wù)取決于你要設(shè)計(jì)的系統(tǒng)的復(fù)雜度。微服務(wù)是用來(lái)把控復(fù)雜系統(tǒng)的，但是隨之而來(lái)的就是引入了微服務(wù)本身的復(fù)雜度。

需要解決包括自動(dòng)化部署、監(jiān)控、容錯(cuò)處理、最終一致性等其他分布式系統(tǒng)面臨的問(wèn)題。即使已經(jīng)有一些普遍使用的解決方案，但是仍然是有不小的成本的。

生產(chǎn)力和復(fù)雜度的關(guān)系如圖所示，可見(jiàn)系統(tǒng)越復(fù)雜，微服務(wù)帶來(lái)的收益越大。此外，無(wú)論是單體應(yīng)用還是微服務(wù)，團(tuán)隊(duì)的技能都需要能夠把控住。

馬丁·福勒的一個(gè)觀點(diǎn)是：除非管理單體應(yīng)用的成本已經(jīng)太復(fù)雜了（太大導(dǎo)致很難修改和部署），否則都不要考慮微服務(wù)。

大部分應(yīng)用都應(yīng)該選擇單體架構(gòu)，做好單體應(yīng)用的模塊化而不是拆分成服務(wù)。

因此，系統(tǒng)一開(kāi)始采用單體架構(gòu)，做好模塊化，之后隨著系統(tǒng)變得越來(lái)越復(fù)雜、模塊/服務(wù)間的邊界越來(lái)越清晰，再重構(gòu)為微服務(wù)架構(gòu)是一個(gè)合理的架構(gòu)演化路徑。

四個(gè)可以考慮上微服務(wù)的情況：

多人開(kāi)發(fā)一個(gè)模塊/項(xiàng)目，提交代碼頻繁出現(xiàn)大量沖突。
模塊間嚴(yán)重耦合，互相依賴(lài)，每次變動(dòng)需要牽扯多個(gè)團(tuán)隊(duì)，單次上線(xiàn)需求太多，風(fēng)險(xiǎn)大。
主要業(yè)務(wù)和次要業(yè)務(wù)耦合，橫向擴(kuò)展流程復(fù)雜。
熔斷降級(jí)全靠 if-else。

微服務(wù)的三個(gè)階段：

微服務(wù) 1.0：僅使用注冊(cè)發(fā)現(xiàn)，基于 Spring Cloud 或者 Dubbo 進(jìn)行開(kāi)發(fā)。
微服務(wù) 2.0：使用了熔斷、限流、降級(jí)等服務(wù)治理策略，并配備完整服務(wù)工具和平臺(tái)。
微服務(wù) 3.0：Service Mesh 將服務(wù)治理作為通用組件，下沉到平臺(tái)層實(shí)現(xiàn)，應(yīng)用層僅僅關(guān)注業(yè)務(wù)邏輯，平臺(tái)層可以根據(jù)業(yè)務(wù)監(jiān)控自動(dòng)調(diào)度和參數(shù)調(diào)整，實(shí)現(xiàn) AIOps 和智能調(diào)度。

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

先決條件

微服務(wù)的先決條件如下：

快速的環(huán)境提供能力：依賴(lài)于云計(jì)算、容器技術(shù)，快速交付環(huán)境。
基本的監(jiān)控能力：包括基礎(chǔ)的技術(shù)監(jiān)控和業(yè)務(wù)監(jiān)控。
快速的應(yīng)用部署能力：需要部署管道提供快速的部署能力。
Devops 文化：需要具有良好的持續(xù)交付能力，包括全鏈路追蹤、快速環(huán)境提供和部署等，還需要快速的反應(yīng)能力（對(duì)問(wèn)題、故障的快速響應(yīng)），開(kāi)發(fā)和運(yùn)維的協(xié)同工作。

此外，根據(jù)康威定律和逆康威定律（技術(shù)架構(gòu)倒逼組織架構(gòu)改進(jìn)），組織架構(gòu)也是一個(gè)很關(guān)鍵的因素。

對(duì)應(yīng)于微服務(wù)架構(gòu)，組織架構(gòu)需要遵循以下原則：

一個(gè)微服務(wù)由一個(gè)團(tuán)隊(duì)維護(hù)，團(tuán)隊(duì)成員以三人為宜。
單個(gè)團(tuán)隊(duì)的任務(wù)和發(fā)展是獨(dú)立的，不受其他因素影響。
團(tuán)隊(duì)是功能齊全、全棧、自治的，扁平、自我管理。

基礎(chǔ)設(shè)施

微服務(wù)的推行需要依賴(lài)于很多底層基礎(chǔ)設(shè)施，包括提供微服務(wù)的編譯、集成、打包、部署、配置等工作，采用 PaaS 平臺(tái)解決微服務(wù)從開(kāi)發(fā)到運(yùn)行的全生命周期管理，同時(shí)提供異構(gòu)環(huán)境管理、容器資源隔離與互通、服務(wù)伸縮漂移、服務(wù)升級(jí)與回退、服務(wù)熔斷與降級(jí)、服務(wù)注冊(cè)與發(fā)現(xiàn)。

①最基本的基礎(chǔ)設(shè)施

進(jìn)程間通訊機(jī)制：微服務(wù)是獨(dú)立進(jìn)程的，需要確定之間的通訊方式。

服務(wù)發(fā)現(xiàn)+服務(wù)路由：提供服務(wù)注冊(cè)中心，服務(wù)提供者和消費(fèi)者通過(guò)服務(wù)發(fā)現(xiàn)獲取服務(wù)的信息從而調(diào)用服務(wù)，實(shí)現(xiàn)服務(wù)的負(fù)載均衡等。

服務(wù)容錯(cuò)：微服務(wù)架構(gòu)中，由于服務(wù)非常多，往往是一個(gè)服務(wù)掛了，整個(gè)請(qǐng)求鏈路的服務(wù)都受到影響。

因此需要服務(wù)容錯(cuò)，在服務(wù)調(diào)用失敗的時(shí)候能夠處理錯(cuò)誤或者快速失敗，包括熔斷、Fallback、重試、流控和服務(wù)隔離等。

分布式事務(wù)支持：隨著業(yè)務(wù)拆分為服務(wù)，那么有時(shí)候不開(kāi)避免的就是跨服務(wù)的事務(wù)，即分布式事務(wù)的問(wèn)題。

原則是盡量避免分布式事務(wù)，如果無(wú)法避免那么可以使用消息系統(tǒng)或者 CQRS 和 Event Sourcing 方案來(lái)實(shí)現(xiàn)最終一致性。

如果需要強(qiáng)一致性，則有兩階段提交、三階段提交、TCC 等分布式事務(wù)解決方案。

②提升外部服務(wù)對(duì)接效率和內(nèi)部開(kāi)發(fā)效率

API 網(wǎng)關(guān)：負(fù)責(zé)外部系統(tǒng)的訪(fǎng)問(wèn)，跨橫切面的公共層面的工作，包括安全、日志、權(quán)限控制、傳輸加密、請(qǐng)求轉(zhuǎn)發(fā)、流量控制等。

典型的網(wǎng)關(guān)功能即對(duì)外暴露一個(gè)域名 xx.com，根據(jù)第一級(jí)目錄做反向路由 xx.com/user，xx.com/trade。

每一級(jí)目錄，如 user、trade 對(duì)應(yīng)一個(gè)服務(wù)的域名。此外，API 網(wǎng)關(guān)也可以有服務(wù)編排的功能（不推薦）。

接口框架：規(guī)范服務(wù)之間通訊使用的數(shù)據(jù)格式、解析包、自解釋文檔，便于服務(wù)使用方快速上手等。

③提升測(cè)試和運(yùn)維效率

配置中心: 運(yùn)行時(shí)配置管理能夠解決動(dòng)態(tài)修改配置并批量生效的問(wèn)題。包括配置版本管理、配置項(xiàng)管理、節(jié)點(diǎn)管理、配置同步等。

持續(xù)交付：包括持續(xù)集成、自動(dòng)化部署等流程。目的就是小步迭代，快速交付。

持續(xù)集成：這一部分并非是微服務(wù)特定的，對(duì)于之前的單體應(yīng)用，此部分一般來(lái)說(shuō)也是必要的。

主要是指通過(guò)自動(dòng)化手段，持續(xù)地對(duì)代碼進(jìn)程編譯構(gòu)建、自動(dòng)化測(cè)試，以得到快速有效的質(zhì)量反饋，從而保證代碼的順利交付。

自動(dòng)化測(cè)試包括代碼級(jí)別的單元測(cè)試、單個(gè)系統(tǒng)的集成測(cè)試、系統(tǒng)間的接口測(cè)試。

自動(dòng)化部署：微服務(wù)架構(gòu)，節(jié)點(diǎn)數(shù)動(dòng)輒上百上千，自動(dòng)化部署能夠提高部署速度和部署頻率，從而保證持續(xù)交付。

包括版本管理、資源管理、部署操作、回滾操作等功能。而對(duì)于微服務(wù)的部署方式，包括藍(lán)綠部署、滾動(dòng)部署以及金絲雀部署。

④進(jìn)一步提升運(yùn)維效率

服務(wù)監(jiān)控：微服務(wù)架構(gòu)下節(jié)點(diǎn)數(shù)目眾多，需要監(jiān)控的機(jī)器、網(wǎng)絡(luò)、進(jìn)程、接口等的數(shù)量大大增加，需要一個(gè)強(qiáng)大的監(jiān)控系統(tǒng)，能夠提供實(shí)時(shí)搜集信息進(jìn)行分析以及實(shí)時(shí)分析之上的預(yù)警。

包括監(jiān)控服務(wù)的請(qǐng)求次數(shù)、響應(yīng)時(shí)間分布、最大/最小響應(yīng)值、錯(cuò)誤碼分布等。

服務(wù)跟蹤：跟蹤一個(gè)請(qǐng)求的完整路徑，包括請(qǐng)求發(fā)起時(shí)間、響應(yīng)時(shí)間、響應(yīng)碼、請(qǐng)求參數(shù)、返回結(jié)果等信息，也叫做全鏈路跟蹤。

通常的服務(wù)可以和服務(wù)監(jiān)控做在一起，宏觀信息由服務(wù)跟蹤呈現(xiàn)，微觀單個(gè)服務(wù)/節(jié)點(diǎn)的信息由服務(wù)監(jiān)控呈現(xiàn)。服務(wù)跟蹤目前的實(shí)現(xiàn)理論基本都是 Google 的 Dapper 論文。

服務(wù)安全：內(nèi)網(wǎng)之間的微服務(wù)調(diào)用原則上講應(yīng)該是都可以互相訪(fǎng)問(wèn)寫(xiě)，一般并不需要權(quán)限控制，但有時(shí)候限于業(yè)務(wù)要求，會(huì)對(duì)接口、數(shù)據(jù)等方面有安全控制的要求。

此部分可以以配置的方式存在于服務(wù)注冊(cè)中心中，和服務(wù)綁定，在請(qǐng)求時(shí)由做為服務(wù)提供者的服務(wù)節(jié)點(diǎn)進(jìn)行安全策略控制。配置則可以存儲(chǔ)在配置中心以方便動(dòng)態(tài)修改。

在微服務(wù)數(shù)量很少的情況下，以上基礎(chǔ)設(shè)施的優(yōu)先級(jí)自上而下降低。否則，僅僅依賴(lài)人工操作，則投入產(chǎn)出比會(huì)很低。

還需要提到的是 Docker 容器技術(shù)。雖然這個(gè)對(duì)于微服務(wù)并不是必須的，但是容器技術(shù)輕量級(jí)、靈活、與應(yīng)用依存、屏蔽環(huán)境差異的特性對(duì)于持續(xù)交付的實(shí)現(xiàn)是至關(guān)重要的，即使對(duì)于傳統(tǒng)的單體應(yīng)用也能夠給其帶來(lái)交付效率的大幅提升。

架構(gòu)設(shè)計(jì)模式

在引入微服務(wù)之后，傳統(tǒng)的單體應(yīng)用變?yōu)榱艘粋€(gè)一個(gè)服務(wù)，之前一個(gè)應(yīng)用直接提供接口給客戶(hù)端訪(fǎng)問(wèn)的架構(gòu)不再適用。

微服務(wù)架構(gòu)下，針對(duì)不同設(shè)備的接口做為 BFF 層（Backend For Frontend），也叫做用戶(hù)體驗(yàn)適配層，負(fù)責(zé)聚合、編排微服務(wù)的數(shù)據(jù)轉(zhuǎn)換成前端需要的數(shù)據(jù)。

服務(wù)之間的調(diào)用則在允許的情況下（允許延遲）盡可能使用異步消息傳遞方式，如此形成面向用戶(hù)體驗(yàn)的微服務(wù)架構(gòu)設(shè)計(jì)模式。

如下圖所示：

Client→API Gateway→BFF（Backend For Frontend）→Downstream Microservices：

后臺(tái)采用微服務(wù)架構(gòu)，微服務(wù)可以采用不同的編程語(yǔ)言和不同的存儲(chǔ)機(jī)制。
前臺(tái)采用 BFF 模式對(duì)不同的用戶(hù)體驗(yàn)（如桌面瀏覽器，Native App，平板響應(yīng)式 Web）進(jìn)行適配。
BFF、API Orchestration Layer，Edge Service Layer，Device Wrapper Layer 是相同的概念。
BFF 不能過(guò)多，過(guò)多會(huì)造成代碼邏輯重復(fù)冗余。
可以將網(wǎng)關(guān)承擔(dān)的功能，如 Geoip、限流、安全認(rèn)證等跨橫切面功能和 BFF 做在同一層，雖然增加了 BFF 層的復(fù)雜性，但能夠得到性能優(yōu)勢(shì)。

服務(wù)拆分

微服務(wù)架構(gòu)最核心的環(huán)節(jié)，主要是對(duì)服務(wù)的橫向拆分。服務(wù)拆分就是將一個(gè)完整的業(yè)務(wù)系統(tǒng)解耦為服務(wù)，服務(wù)需要職責(zé)單一，之間沒(méi)有耦合關(guān)系，能夠獨(dú)立開(kāi)發(fā)和維護(hù)。

服務(wù)拆分不是一蹴而就的，需要在開(kāi)發(fā)過(guò)程中不斷地理清邊界。在完全理清服務(wù)之前，盡量推遲對(duì)服務(wù)的拆分，尤其是對(duì)數(shù)據(jù)庫(kù)的拆分。

拆分方法如下：

基于業(yè)務(wù)邏輯拆分
基于可擴(kuò)展拆分
基于可靠性拆分
基于性能拆分

其中，對(duì)于無(wú)法修改的遺留系統(tǒng)，采用絞殺者模式：在遺留系統(tǒng)外面增加新的功能做成微服務(wù)方式，而不是直接修改原有系統(tǒng)，逐步的實(shí)現(xiàn)對(duì)老系統(tǒng)替換。

拆分過(guò)程需要遵守的規(guī)范如下：

先少后多、先粗后細(xì)（粒度）
服務(wù)縱向拆分最多三層，兩次調(diào)用：Controller、組合服務(wù)、基礎(chǔ)服務(wù)
僅僅單向調(diào)用，禁止循環(huán)調(diào)用
串行調(diào)用改為并行調(diào)用或者異步化
接口應(yīng)該冪等
接口數(shù)據(jù)定義嚴(yán)禁內(nèi)嵌，透?jìng)?/span>
規(guī)范化工程名
先拆分服務(wù)，等服務(wù)粒度確定后再拆分?jǐn)?shù)據(jù)庫(kù)。

微服務(wù)框架

上面講述了微服務(wù)架構(gòu)的眾多基礎(chǔ)設(shè)施，如果每一個(gè)基礎(chǔ)設(shè)施都需要自己開(kāi)發(fā)的話(huà)是非常巨大的開(kāi)發(fā)工作。目前市面上已經(jīng)有不少開(kāi)源的微服務(wù)框架可以選擇。

Spring Boot

Spring Boot 是用來(lái)簡(jiǎn)化新 Spring 應(yīng)用的初始搭建以及開(kāi)發(fā)過(guò)程的。其雖然不是微服務(wù)框架，但其設(shè)計(jì)的初衷本質(zhì)就是微應(yīng)用的底層框架，因此非常適合用于微服務(wù)基礎(chǔ)設(shè)施的開(kāi)發(fā)以及微服務(wù)的應(yīng)用開(kāi)發(fā)。

尤其對(duì)于 Spring 技術(shù)棧的團(tuán)隊(duì)來(lái)說(shuō)，基于 Spring Boot 開(kāi)發(fā)微服務(wù)框架和應(yīng)用是自然而然的一個(gè)選擇。

Dubbo & Motan

Dubbo 是阿里開(kāi)源的服務(wù)治理框架。其出現(xiàn)在微服務(wù)理念興起之前，可以看做是 SOA 框架的集大成之作。

但其僅僅包含了微服務(wù)基礎(chǔ)設(shè)施的部分功能，諸如熔斷、服務(wù)跟蹤、網(wǎng)關(guān)等都沒(méi)有實(shí)現(xiàn)：

服務(wù)發(fā)現(xiàn)：服務(wù)發(fā)布、訂閱、通知。
高可用策略：失敗重試（Failover）、快速失?。‵ailfast）、資源隔離 - 負(fù)載均衡：最少活躍連接、一致性 Hash、隨機(jī)請(qǐng)求、輪詢(xún)等。
擴(kuò)展性：支持 SPI 擴(kuò)展（service provider interface）。
其他：調(diào)用統(tǒng)計(jì)、訪(fǎng)問(wèn)日志等。

Motan 則是微博開(kāi)源的類(lèi)似 Dubbo 的 RPC 框架，與 Dubbo 相比更輕量級(jí)。

Spring Cloud

Spring Cloud 是基于 Spring Boot 實(shí)現(xiàn)的微服務(wù)框架，也可以看做一套微服務(wù)實(shí)現(xiàn)規(guī)范。

基本涵蓋了微服務(wù)基礎(chǔ)設(shè)施的方方面面，包括配置管理、服務(wù)發(fā)現(xiàn)、斷路器、智能路由、微代理、控制總線(xiàn)、全局鎖、決策競(jìng)選、分布式會(huì)話(huà)和集群狀態(tài)管理等。

其基于 Spring 生態(tài)，社區(qū)支持非常好。但其很多組件都沒(méi)有經(jīng)過(guò)生產(chǎn)環(huán)境驗(yàn)證，需要慎重選擇。

Spring Cloud Netflix 是 Spring Cloud 的一個(gè)子項(xiàng)目，是 Spring 對(duì) Netflix OSS 的集成實(shí)現(xiàn)。

基于 Netflix 的大規(guī)模使用，其中的已經(jīng)被廣泛使用的組件包括：

Eureka：服務(wù)注冊(cè)和服務(wù)發(fā)現(xiàn)
Ribbon：彈性而智能的進(jìn)程間和服務(wù)通訊機(jī)制，客戶(hù)端負(fù)載均衡
Hystrix：熔斷器，在運(yùn)行時(shí)提供延遲和容錯(cuò)的隔離
Zuul：服務(wù)網(wǎng)關(guān)

此外，另一個(gè)子項(xiàng)目 Spring Cloud Alibaba 則是 Alibaba 開(kāi)源的基于 Spring Boot 的微服務(wù)框架，主要是對(duì)阿里云服務(wù)的支持。

Service Mesh

上述的微服務(wù)框架都是侵入式的，服務(wù)化的過(guò)程都需要進(jìn)行代碼改造。Service Mesh 則是下一代微服務(wù)架構(gòu)，最明顯的特征就是無(wú)入侵。采用 Sidecar 模式來(lái)解決系統(tǒng)架構(gòu)微服務(wù)化后的服務(wù)間通信和治理問(wèn)題。

如下圖所示：

目前主流的開(kāi)源實(shí)現(xiàn)包括：

Linkerd 和 Envoy：以 Sidecar 為核心，關(guān)注如何做好 Proxy，并完成一些通用控制平面的功能。缺乏對(duì)這些 Sidecar 的管理和控制。
Istio 和 Conduit：目前最為流行的 Service Mesh 實(shí)現(xiàn)方案，集中在更加強(qiáng)大的控制平面（Sidecar 被稱(chēng)為數(shù)據(jù)平面）功能。

前者由 Google 和 IBM 合作，并使用了 Envoy 作為 Sidecar 部分的實(shí)現(xiàn)；后者則是 Linkerd 作者的作品。

相比起來(lái)，Istio 有巨頭背景，功能強(qiáng)大，但可用性和易用性一直不高，Conduit 則相對(duì)簡(jiǎn)單、功能聚焦。

限于 Service Mesh 帶來(lái)的性能延遲的開(kāi)銷(xiāo)以及 Sidecar 對(duì)分布復(fù)雜性的增加，其對(duì)大規(guī)模部署（微服務(wù)數(shù)目多）、異構(gòu)復(fù)雜（交互協(xié)議/開(kāi)發(fā)語(yǔ)言類(lèi)型多）的微服務(wù)架構(gòu)帶來(lái)的收益會(huì)更大。

Sofastack

螞蟻金服開(kāi)源的構(gòu)建金融級(jí)分布式架構(gòu)的一套中間件。包括微服務(wù)開(kāi)發(fā)框架、RPC 框架、服務(wù)注冊(cè)中心、全鏈路追蹤、服務(wù)監(jiān)控、Service Mesh 等一整套分布式應(yīng)用開(kāi)發(fā)工具。

特別值得一提的是 SOFAMesh。其實(shí)對(duì)下一代微服務(wù)架構(gòu) Service Mesh 的大規(guī)模落地方案實(shí)踐，基于 Istio 改進(jìn)和擴(kuò)展而來(lái)，應(yīng)該是國(guó)內(nèi)最為成熟的開(kāi)源 Service Mesh 方案。

此外，需要提到 Kubernetes（K8s），其本身提供了部分的微服務(wù)特性支持（通過(guò)域名做服務(wù)發(fā)現(xiàn)），對(duì)代碼無(wú)侵入。但服務(wù)調(diào)用、熔斷這些都需要自己實(shí)現(xiàn)。

綜上，目前公司技術(shù)團(tuán)隊(duì)技術(shù)棧是 Spring，并且已有服務(wù)的實(shí)現(xiàn)都是基于 Dubbo。

因此選擇 Spring Cloud Netflix 做為基礎(chǔ)的微服務(wù)框架，對(duì)其中不成熟或者缺乏的組件，選擇業(yè)界更為成熟的組件替代即可：

API 網(wǎng)關(guān)：Zuul
服務(wù)注冊(cè)中心：Dubbo
配置中心：Disconf
服務(wù)監(jiān)控&全鏈路追蹤：CAT
服務(wù)開(kāi)發(fā)框架：Spring Boot
日志監(jiān)控、告警：ELK+Elasalert
流量控制：Sentinel
消息隊(duì)列：Kafka

原文鏈接：https://www./blog/2019/05/30/msa/

Kubernetes入門(mén)與實(shí)戰(zhàn)培訓(xùn)

Kubernetes入門(mén)與實(shí)戰(zhàn)培訓(xùn)將于2020年2月28日在北京開(kāi)課，3天時(shí)間帶你系統(tǒng)掌握Kubernetes，學(xué)習(xí)效果不好可以繼續(xù)學(xué)習(xí)。本次培訓(xùn)包括：Docker基礎(chǔ)、容器技術(shù)、Docker鏡像、數(shù)據(jù)共享與持久化、Docker實(shí)踐、Kubernetes基礎(chǔ)、Pod基礎(chǔ)與進(jìn)階、常用對(duì)象操作、服務(wù)發(fā)現(xiàn)、Helm、Kubernetes核心組件原理分析、Kubernetes服務(wù)質(zhì)量保證、調(diào)度詳解與應(yīng)用場(chǎng)景、網(wǎng)絡(luò)、基于Kubernetes的CI/CD、基于Kubernetes的配置管理等等，點(diǎn)擊下方圖片或者閱讀原文鏈接查看詳情。

本站是提供個(gè)人知識(shí)管理的網(wǎng)絡(luò)存儲(chǔ)空間，所有內(nèi)容均由用戶(hù)發(fā)布，不代表本站觀點(diǎn)。請(qǐng)注意甄別內(nèi)容中的聯(lián)系方式、誘導(dǎo)購(gòu)買(mǎi)等信息，謹(jǐn)防詐騙。如發(fā)現(xiàn)有害或侵權(quán)內(nèi)容，請(qǐng)點(diǎn)擊一鍵舉報(bào)。

轉(zhuǎn)藏 分享

QQ空間 QQ好友新浪微博微信

獻(xiàn)花（0） +1

來(lái)自：樂(lè)康居 > 《互聯(lián)物聯(lián)》

舉報(bào)/認(rèn)領(lǐng)