從 0 開(kāi)始學(xué)微服務(wù)
說(shuō)起微服務(wù)，大家應(yīng)該并不陌生，不只是一線大廠，很多中小規(guī)模團(tuán)隊(duì)也已經(jīng)將這項(xiàng)技術(shù)引入并在實(shí)際業(yè)務(wù)中落地。
那作為一名開(kāi)發(fā)人員，應(yīng)該如何學(xué)習(xí)微服務(wù)呢？
雖然現(xiàn)在開(kāi)源的微服務(wù)框架有很多，各種編程語(yǔ)言的都有，花上幾個(gè)小時(shí)搭建一套可運(yùn)行的開(kāi)發(fā)環(huán)境也并不是一件難事。但畢竟微服務(wù)涉及的組件還是挺多的，相比于單體架構(gòu)來(lái)說(shuō)，復(fù)雜度提升了不少。
不知道你有沒(méi)有和我一樣的困擾，有時(shí)候想要深入學(xué)習(xí)一下，但卻不知道從什么地方入手，結(jié)果就是對(duì)其了解只是浮于表面。
所以我最近看了極客時(shí)間的專欄《從 0 開(kāi)始學(xué)微服務(wù)》，覺(jué)得作為入門還是不錯(cuò)的。
同時(shí)，我總結(jié)了專欄中的部分內(nèi)容，并加入一些自己的思考，形成了這篇文章。算是學(xué)習(xí)微服務(wù)的一個(gè)大綱，然后再按照這個(gè)大綱去深入學(xué)習(xí)，不斷充實(shí)這套技術(shù)體系。
好了，下面正文開(kāi)始。
什么是微服務(wù)
微服務(wù)是指開(kāi)發(fā)應(yīng)用所用的一種架構(gòu)形式。通過(guò)微服務(wù)，可將大型應(yīng)用分解成多個(gè)獨(dú)立的組件，其中每個(gè)組件都有各自的責(zé)任領(lǐng)域。在處理一個(gè)用戶請(qǐng)求時(shí)，基于微服務(wù)的應(yīng)用可能會(huì)調(diào)用許多內(nèi)部微服務(wù)來(lái)共同生成其響應(yīng)。
微服務(wù)的特點(diǎn)：
服務(wù)拆分粒度： 小到一個(gè)子模塊，只要該模塊依賴的資源與其他模塊都沒(méi)有關(guān)系，那么就可以拆分為一個(gè)微服務(wù)。 服務(wù)獨(dú)立部署： 每個(gè)微服務(wù)都嚴(yán)格遵循獨(dú)立打包部署的準(zhǔn)則，互不影響。比如一臺(tái)物理機(jī)上可以部署多個(gè) Docker 實(shí)例，每個(gè) Docker 實(shí)例可以部署一個(gè)微服務(wù)的代碼。 服務(wù)獨(dú)立維護(hù)： 每個(gè)微服務(wù)都可以交由一個(gè)小團(tuán)隊(duì)甚至個(gè)人來(lái)開(kāi)發(fā)、測(cè)試、發(fā)布和運(yùn)維，并對(duì)整個(gè)生命周期負(fù)責(zé)。 服務(wù)治理能力要求高： 因?yàn)椴鸱譃槲⒎?wù)之后，服務(wù)的數(shù)量變多，因此需要有統(tǒng)一的服務(wù)治理平臺(tái)，來(lái)對(duì)各個(gè)服務(wù)進(jìn)行管理。
服務(wù)發(fā)布和引用
想要構(gòu)建微服務(wù)，首先要解決的問(wèn)題是，服務(wù)提供者如何發(fā)布一個(gè)服務(wù)，服務(wù)消費(fèi)者如何引用這個(gè)服務(wù)。具體來(lái)說(shuō)，就是這個(gè)服務(wù)的接口名是什么？調(diào)用這個(gè)服務(wù)需要傳遞哪些參數(shù)？接口的返回值是什么類型？以及一些其他接口描述信息。
最常見(jiàn)的服務(wù)發(fā)布和引用的方式有三種：
RESTful API XML 配置 IDL 文件
RESTful API
這種方式就比較常見(jiàn)了，主要被用作 HTTP 或者 HTTPS 協(xié)議的接口定義，即使在非微服務(wù)架構(gòu)體系下，也被廣泛采用。而且學(xué)習(xí)成本低，比較適合用作跨業(yè)務(wù)平臺(tái)之間的服務(wù)協(xié)議。
XML 配置
這種方式下需要在服務(wù)提供者和服務(wù)消費(fèi)者之間維持一份對(duì)等的 XML 配置文件，來(lái)保證服務(wù)調(diào)用。比如提供者維護(hù) server.xml，消費(fèi)者維護(hù) client.xml。
在接口變更時(shí)，需要同時(shí)修改這兩個(gè)接口描述文件。
IDL 文件
IDL 就是接口描述語(yǔ)言（interface description language）的縮寫，通過(guò)一種中立的方式來(lái)描述接口，使得在不同的平臺(tái)上運(yùn)行的對(duì)象和不同語(yǔ)言編寫的程序可以相互通信交流。
也就是說(shuō) IDL 主要是用作跨語(yǔ)言平臺(tái)的服務(wù)之間的調(diào)用，有兩種最常用的 IDL：一個(gè)是 Facebook 開(kāi)源的 Thrift 協(xié)議，另一個(gè)是 Google 開(kāi)源的 gRPC 協(xié)議。
小結(jié)
每種方式都有各自的優(yōu)缺點(diǎn)，具體應(yīng)該如何選擇，需要根據(jù)自身的業(yè)務(wù)特點(diǎn)。
| 描述方式 | 使用場(chǎng)景 | 缺點(diǎn) |
|---|---|---|
| RESTful API | 跨語(yǔ)言平臺(tái)，組織內(nèi)外皆可 | 使用 HTTP 作為通信協(xié)議，相比于 TCP，性能較差 |
| XML 配置 | Java 平臺(tái)，一般用于組織內(nèi)部 | 不支持跨語(yǔ)言平臺(tái) |
| IDL 文件 | 跨語(yǔ)言平臺(tái)，組織內(nèi)外皆可 | 修改和刪除字段不支持向前兼容 |
注冊(cè)中心
服務(wù)拆分之后，服務(wù)的提供者和消費(fèi)者分別運(yùn)行在不同的機(jī)器上，而且服務(wù)眾多，有幾十個(gè)，甚至上百個(gè)。這就涉及到一個(gè)問(wèn)題，消費(fèi)者如何才能找到服務(wù)提供者，這也是注冊(cè)中心需要解決的問(wèn)題。
注冊(cè)中心需要實(shí)現(xiàn)哪些 API？
服務(wù)注冊(cè)接口： 服務(wù)提供者通過(guò)調(diào)用服務(wù)注冊(cè)接口來(lái)完成服務(wù)注冊(cè)。 服務(wù)反注冊(cè)接口： 服務(wù)提供者通過(guò)調(diào)用服務(wù)反注冊(cè)接口來(lái)完成服務(wù)注銷。 心跳匯報(bào)接口： 服務(wù)提供者通過(guò)調(diào)用心跳匯報(bào)接口完成節(jié)點(diǎn)存活狀態(tài)上報(bào)。 服務(wù)訂閱接口： 服務(wù)消費(fèi)者通過(guò)調(diào)用服務(wù)訂閱接口完成服務(wù)訂閱，獲取可用的服務(wù)提供者節(jié)點(diǎn)列表。 服務(wù)變更查詢接口： 服務(wù)消費(fèi)者通過(guò)調(diào)用服務(wù)變更查詢接口，獲取最新的可用服務(wù)節(jié)點(diǎn)列表。
除此之外，為了便于管理，注冊(cè)中心還必須提供一些后臺(tái)管理的 API，例如：
服務(wù)查詢接口： 查詢注冊(cè)中心當(dāng)前注冊(cè)了哪些服務(wù)信息。 服務(wù)修改接口： 修改注冊(cè)中心中某一服務(wù)的信息。
配置中心
在拆分為微服務(wù)架構(gòu)前，單體應(yīng)用只需要管理一套配置；而拆分為微服務(wù)后，每一個(gè)系統(tǒng)都有自己的配置，并且都各不相同，而且因?yàn)榉?wù)治理的需要，有些配置還需要能夠動(dòng)態(tài)改變，以達(dá)到動(dòng)態(tài)降級(jí)、切流量、擴(kuò)縮容等目的，所以如何管理配置十分重要。
配置中心一般包含下面幾個(gè)功能：
配置注冊(cè) 配置反注冊(cè) 配置查看 配置變更訂閱
API 網(wǎng)關(guān)
API 網(wǎng)關(guān)可以被視為一種充當(dāng)應(yīng)用程序服務(wù)和不同客戶端之間的中間件，可以管理許多事情，例如：
路由： 網(wǎng)關(guān)接收所有 API 請(qǐng)求并將它們轉(zhuǎn)發(fā)到目標(biāo)服務(wù) 記錄日志： 能夠在一處記錄所有請(qǐng)求 權(quán)限認(rèn)證： 檢查用戶是否有資格訪問(wèn)該服務(wù)，如果沒(méi)有，可以拒絕該請(qǐng)求 性能分析： 估計(jì)每個(gè)請(qǐng)求的執(zhí)行時(shí)間并檢查性能瓶頸 緩存： 通過(guò)在網(wǎng)關(guān)級(jí)別處理緩存，可以降低服務(wù)的流量壓力
事實(shí)上，它是作為一個(gè)反向代理工作的，客戶端只需要知道系統(tǒng)的網(wǎng)關(guān)，應(yīng)用服務(wù)就可以隱藏起來(lái)，不直接向其他系統(tǒng)暴露。
如果沒(méi)有 API 網(wǎng)關(guān)，可能需要在每個(gè)服務(wù)中做一些橫切關(guān)注點(diǎn)，比如想記錄服務(wù)的請(qǐng)求和響應(yīng)。此外，如果應(yīng)用程序由多個(gè)服務(wù)組成，客戶端需要知道每個(gè)服務(wù)地址，并且在更改服務(wù)地址的情況下，需要更新多個(gè)地方。
負(fù)載均衡
微服務(wù)架構(gòu)擁有很好的可擴(kuò)展性，我們能夠通過(guò)運(yùn)行更多服務(wù)實(shí)例來(lái)處理更多請(qǐng)求，但問(wèn)題是，哪個(gè)實(shí)例應(yīng)該接收請(qǐng)求，或客戶端如何知道哪個(gè)服務(wù)實(shí)例應(yīng)該處理請(qǐng)求？
這些問(wèn)題的答案是負(fù)載均衡。負(fù)載均衡是高可用網(wǎng)絡(luò)基礎(chǔ)架構(gòu)的關(guān)鍵組件，通常用于將工作負(fù)載分布到多個(gè)服務(wù)器來(lái)提高網(wǎng)站、應(yīng)用、數(shù)據(jù)庫(kù)或其他服務(wù)的性能和可靠性。
常用的負(fù)載均衡算法有一下五種：
隨機(jī)算法
顧名思義就是從可用的服務(wù)節(jié)點(diǎn)中，隨機(jī)挑選一個(gè)節(jié)點(diǎn)來(lái)訪問(wèn)。
實(shí)現(xiàn)比較簡(jiǎn)單，在請(qǐng)求量遠(yuǎn)超可用服務(wù)節(jié)點(diǎn)數(shù)量的情況下，各個(gè)服務(wù)節(jié)點(diǎn)被訪問(wèn)的概率基本相同，主要應(yīng)用在各個(gè)服務(wù)節(jié)點(diǎn)的性能差異不大的情況下。
輪詢算法
跟隨機(jī)算法類似，各個(gè)服務(wù)節(jié)點(diǎn)被訪問(wèn)的概率也基本相同，也主要應(yīng)用在各個(gè)服務(wù)節(jié)點(diǎn)性能差異不大的情況下。
加權(quán)輪詢算法
在輪詢算法基礎(chǔ)上的改進(jìn)，可以通過(guò)給每個(gè)節(jié)點(diǎn)設(shè)置不同的權(quán)重來(lái)控制訪問(wèn)的概率，因此主要被用在服務(wù)節(jié)點(diǎn)性能差異比較大的情況。
比如經(jīng)常會(huì)出現(xiàn)一種情況，因?yàn)椴少?gòu)時(shí)間的不同，新的服務(wù)節(jié)點(diǎn)的性能往往要高于舊的節(jié)點(diǎn)，這個(gè)時(shí)候可以給新的節(jié)點(diǎn)設(shè)置更高的權(quán)重，讓它承擔(dān)更多的請(qǐng)求，充分發(fā)揮新節(jié)點(diǎn)的性能優(yōu)勢(shì)。
最少活躍連接算法
與加權(quán)輪詢算法預(yù)先定義好每個(gè)節(jié)點(diǎn)的訪問(wèn)權(quán)重不同，采用最少活躍連接算法，客戶端同服務(wù)端節(jié)點(diǎn)的連接數(shù)是在時(shí)刻變化的，理論上連接數(shù)越少代表此時(shí)服務(wù)端節(jié)點(diǎn)越空閑，選擇最空閑的節(jié)點(diǎn)發(fā)起請(qǐng)求，能獲取更快的響應(yīng)速度。
尤其在服務(wù)端節(jié)點(diǎn)性能差異較大，而又不好做到預(yù)先定義權(quán)重時(shí)，采用最少活躍連接算法是比較好的選擇。
一致性 hash 算法
因?yàn)樗軌虮ＷC同一個(gè)客戶端的請(qǐng)求始終訪問(wèn)同一個(gè)服務(wù)節(jié)點(diǎn)，所以適合服務(wù)端節(jié)點(diǎn)處理不同客戶端請(qǐng)求差異較大的場(chǎng)景。
比如服務(wù)端緩存里保存著客戶端的請(qǐng)求結(jié)果，如果同一客戶端一直訪問(wèn)一個(gè)服務(wù)節(jié)點(diǎn)，那么就可以一直從緩存中獲取數(shù)據(jù)。
服務(wù)監(jiān)控
不管是單體架構(gòu)，還是微服務(wù)架構(gòu)，監(jiān)控都是必不可少的。只不過(guò)微服務(wù)架構(gòu)更加復(fù)雜，監(jiān)控起來(lái)也就更加不容易。
對(duì)于一個(gè)微服務(wù)來(lái)說(shuō)，必須明確要監(jiān)控哪些對(duì)象、哪些指標(biāo)，并且還要從不同的維度進(jìn)行監(jiān)控，才能掌握微服務(wù)的調(diào)用情況。
監(jiān)控對(duì)象
監(jiān)控對(duì)象可以分為四個(gè)層次，由上到下可歸納為：
用戶端監(jiān)控： 通常是指業(yè)務(wù)直接對(duì)用戶提供的功能的監(jiān)控。 接口監(jiān)控： 通常是指業(yè)務(wù)提供的功能所依賴的具體 RPC 接口的監(jiān)控。 資源監(jiān)控： 通常是指某個(gè)接口依賴的資源的監(jiān)控。 基礎(chǔ)監(jiān)控： 通常是指對(duì)服務(wù)器本身的健康狀況的監(jiān)控。主要包括 CPU 利用率、內(nèi)存使用量、I/O 讀寫量、網(wǎng)卡帶寬等。
監(jiān)控指標(biāo)
搞清楚要監(jiān)控的對(duì)象之后，需要監(jiān)控具體哪些指標(biāo)呢？
請(qǐng)求量： 請(qǐng)求量監(jiān)控分為兩個(gè)維度，一個(gè)是實(shí)時(shí)請(qǐng)求量，一個(gè)是統(tǒng)計(jì)請(qǐng)求量。實(shí)時(shí)請(qǐng)求量用 QPS（Queries Per Second）即每秒查詢次數(shù)來(lái)衡量，它反映了服務(wù)調(diào)用的實(shí)時(shí)變化情況。統(tǒng)計(jì)請(qǐng)求量一般用 PV（Page View）即一段時(shí)間內(nèi)用戶的訪問(wèn)量來(lái)衡量，比如一天的 PV 代表了服務(wù)一天的請(qǐng)求量，通常用來(lái)統(tǒng)計(jì)報(bào)表。 響應(yīng)時(shí)間： 大多數(shù)情況下，可以用一段時(shí)間內(nèi)所有調(diào)用的平均耗時(shí)來(lái)反映請(qǐng)求的響應(yīng)時(shí)間。但它只代表了請(qǐng)求的平均快慢情況，有時(shí)候我們更關(guān)心慢請(qǐng)求的數(shù)量。為此需要把響應(yīng)時(shí)間劃分為多個(gè)區(qū)間，比如 0～10ms、10ms～50ms、50ms～100ms、100ms～500ms、500ms 以上這五個(gè)區(qū)間，其中 500ms 以上這個(gè)區(qū)間內(nèi)的請(qǐng)求數(shù)就代表了慢請(qǐng)求量，正常情況下，這個(gè)區(qū)間內(nèi)的請(qǐng)求數(shù)應(yīng)該接近于 0；在出現(xiàn)問(wèn)題時(shí)，這個(gè)區(qū)間內(nèi)的請(qǐng)求數(shù)會(huì)大幅增加，可能平均耗時(shí)并不能反映出這一變化。 錯(cuò)誤率： 錯(cuò)誤率的監(jiān)控通常用一段時(shí)間內(nèi)調(diào)用失敗的次數(shù)占調(diào)用總次數(shù)的比率來(lái)衡量，比如對(duì)于接口的錯(cuò)誤率一般用接口返回錯(cuò)誤碼為 503 的比率來(lái)表示。
監(jiān)控維度
一般來(lái)說(shuō)，要從多個(gè)維度來(lái)對(duì)業(yè)務(wù)進(jìn)行監(jiān)控，包括下面幾個(gè)維度：
全局維度： 從整體角度監(jiān)控對(duì)象的的請(qǐng)求量、平均耗時(shí)以及錯(cuò)誤率，全局維度的監(jiān)控一般是為了讓你對(duì)監(jiān)控對(duì)象的調(diào)用情況有個(gè)整體了解。 分機(jī)房維度： 一般為了業(yè)務(wù)的高可用性，服務(wù)通常部署在不止一個(gè)機(jī)房，因?yàn)椴煌瑱C(jī)房地域的不同，同一個(gè)監(jiān)控對(duì)象的各種指標(biāo)可能會(huì)相差很大，所以需要深入到機(jī)房?jī)?nèi)部去了解。 單機(jī)維度： 即便是在同一個(gè)機(jī)房?jī)?nèi)部，可能由于采購(gòu)年份和批次的不同，位于不同機(jī)器上的同一個(gè)監(jiān)控對(duì)象的各種指標(biāo)也會(huì)有很大差異。一般來(lái)說(shuō)，新采購(gòu)的機(jī)器通常由于成本更低，配置也更高，在同等請(qǐng)求量的情況下，可能表現(xiàn)出較大的性能差異，因此也需要從單機(jī)維度去監(jiān)控同一個(gè)對(duì)象。 時(shí)間維度： 同一個(gè)監(jiān)控對(duì)象，在每天的同一時(shí)刻各種指標(biāo)通常也不會(huì)一樣，這種差異要么是由業(yè)務(wù)變更導(dǎo)致，要么是運(yùn)營(yíng)活動(dòng)導(dǎo)致。為了了解監(jiān)控對(duì)象各種指標(biāo)的變化，通常需要與一天前、一周前、一個(gè)月前，甚至三個(gè)月前做比較。 核心維度： 業(yè)務(wù)上一般會(huì)依據(jù)重要性程度對(duì)監(jiān)控對(duì)象進(jìn)行分級(jí)，最簡(jiǎn)單的是分成核心業(yè)務(wù)和非核心業(yè)務(wù)。核心業(yè)務(wù)和非核心業(yè)務(wù)在部署上必須隔離，分開(kāi)監(jiān)控，這樣才能對(duì)核心業(yè)務(wù)做重點(diǎn)保障。
服務(wù)追蹤
在調(diào)試單體應(yīng)用時(shí)，非常直觀容易。但是在微服務(wù)架構(gòu)上，因?yàn)橐粋€(gè)請(qǐng)求可能會(huì)通過(guò)不同的服務(wù)，而不同的服務(wù)又不在一個(gè)地方，這使得調(diào)試和跟蹤變得困難。
所以服務(wù)追蹤是分布式系統(tǒng)中必不可少的功能，它能夠幫助我們查詢一次用戶請(qǐng)求在系統(tǒng)中的具體執(zhí)行路徑，以及每一條路徑的上下游的詳細(xì)情況，對(duì)于追查問(wèn)題十分有用。
它的核心理念就是調(diào)用鏈：通過(guò)一個(gè)全局唯一的 ID 將分布在各個(gè)服務(wù)節(jié)點(diǎn)上的同一次請(qǐng)求串聯(lián)起來(lái)，從而還原原有的調(diào)用關(guān)系，可以追蹤系統(tǒng)問(wèn)題、分析調(diào)用數(shù)據(jù)并統(tǒng)計(jì)各種系統(tǒng)指標(biāo)。
traceId： 用于標(biāo)識(shí)某一次具體的請(qǐng)求 ID。當(dāng)用戶的請(qǐng)求進(jìn)入系統(tǒng)后，會(huì)在 RPC 調(diào)用網(wǎng)絡(luò)的第一層生成一個(gè)全局唯一的 traceId，并且會(huì)隨著每一層的 RPC 調(diào)用，不斷往后傳遞，這樣的話通過(guò) traceId 就可以把一次用戶請(qǐng)求在系統(tǒng)中調(diào)用的路徑串聯(lián)起來(lái)。 spanId： 用于標(biāo)識(shí)一次 RPC 調(diào)用在分布式請(qǐng)求中的位置。當(dāng)用戶的請(qǐng)求進(jìn)入系統(tǒng)后，處在 RPC 調(diào)用網(wǎng)絡(luò)的第一層 A 時(shí) spanId 初始值是 0，進(jìn)入下一層 RPC 調(diào)用 B 的時(shí)候 spanId 是 0.1，繼續(xù)進(jìn)入下一層 RPC 調(diào)用 C 時(shí) spanId 是 0.1.1，而與 B 處在同一層的 RPC 調(diào)用 E 的 spanId 是 0.2，這樣的話通過(guò) spanId 就可以定位某一次 RPC 請(qǐng)求在系統(tǒng)調(diào)用中所處的位置，以及它的上下游依賴分別是誰(shuí)。 annotation： 用于業(yè)務(wù)自定義埋點(diǎn)數(shù)據(jù)，可以是業(yè)務(wù)感興趣的想上傳到后端的數(shù)據(jù)，比如一次請(qǐng)求的用戶 UID。
小結(jié)一下，traceId 是用于串聯(lián)某一次請(qǐng)求在系統(tǒng)中經(jīng)過(guò)的所有路徑，spanId 是用于區(qū)分系統(tǒng)不同服務(wù)之間調(diào)用的先后關(guān)系，而 annotation 是用于業(yè)務(wù)自定義一些自己感興趣的數(shù)據(jù)，在上傳 traceId 和 spanId 這些基本信息之外，添加一些自己感興趣的信息。
故障處理
系統(tǒng)故障是避免不了的，雖然微服務(wù)架構(gòu)做了服務(wù)拆分，不至于像單體架構(gòu)那樣整體崩潰，但由于其整體復(fù)雜度也大大提升，故障處理也更加困難。
限流
顧名思義，限流就是限制流量。通常情況下，系統(tǒng)能夠承載的流量根據(jù)集群規(guī)模的大小是固定的，可以稱之為系統(tǒng)的最大容量。
當(dāng)真實(shí)流量超過(guò)了系統(tǒng)的最大容量后，就會(huì)導(dǎo)致系統(tǒng)響應(yīng)變慢，服務(wù)調(diào)用出現(xiàn)大量超時(shí)，反映給用戶的感覺(jué)就是卡頓、無(wú)響應(yīng)。
所以，應(yīng)該根據(jù)系統(tǒng)的最大容量，給系統(tǒng)設(shè)置一個(gè)閾值，超過(guò)這個(gè)閾值的請(qǐng)求會(huì)被自動(dòng)拋棄，這樣的話可以最大限度地保證系統(tǒng)提供的服務(wù)正常。
熔斷
熔斷和限流還不太一樣，上面我們可以看到限流是控制請(qǐng)求速率，只要還能承受，那么都會(huì)處理，但熔斷不是。
在一條調(diào)用鏈上，如果發(fā)現(xiàn)某個(gè)服務(wù)異常，比如響應(yīng)超時(shí)。那么調(diào)用者為了避免過(guò)多請(qǐng)求導(dǎo)致資源消耗過(guò)大，最終引發(fā)系統(tǒng)雪崩，會(huì)直接返回錯(cuò)誤，而不是瘋狂調(diào)用這個(gè)服務(wù)。
降級(jí)
什么是降級(jí)呢？降級(jí)就是通過(guò)停止系統(tǒng)中的某些功能，來(lái)保證系統(tǒng)整體的可用性。
降級(jí)可以說(shuō)是一種被動(dòng)防御的措施，為什么這么說(shuō)呢？因?yàn)樗话闶窍到y(tǒng)已經(jīng)出現(xiàn)故障后所采取的一種止損措施。
容器化
單體應(yīng)用拆分成多個(gè)微服務(wù)后，能夠?qū)崿F(xiàn)快速開(kāi)發(fā)迭代，但隨之帶來(lái)的問(wèn)題是測(cè)試和運(yùn)維部署成本的提升。
而容器技術(shù)正好可以很好的解決這些問(wèn)題，目前最流行的當(dāng)屬 Docker 莫屬。
微服務(wù)容器化運(yùn)維主要涉及到以下幾點(diǎn)：
鏡像倉(cāng)庫(kù) 容器調(diào)度 服務(wù)編排
鏡像倉(cāng)庫(kù)
鏡像倉(cāng)庫(kù)的概念其實(shí)跟 Git 代碼倉(cāng)庫(kù)類似，就是有一個(gè)集中存儲(chǔ)的地方，把鏡像存儲(chǔ)在這里，在服務(wù)發(fā)布的時(shí)候，各個(gè)服務(wù)器都訪問(wèn)這個(gè)集中存儲(chǔ)來(lái)拉取鏡像，然后啟動(dòng)容器。
容器調(diào)度
這個(gè)階段主要是解決在哪些機(jī)器上啟動(dòng)容器的問(wèn)題，特別是規(guī)模比較大的公司，一般有物理機(jī)集群，虛擬機(jī)集群，私有云和公有云。對(duì)接這么多不同的平臺(tái)，難度還是不小的。
需要統(tǒng)一管理來(lái)自不同集群的機(jī)器權(quán)限管理、成本核算以及環(huán)境初始化等操作，這個(gè)時(shí)候就需要有一個(gè)統(tǒng)一的層來(lái)完成這個(gè)操作。
很顯然，靠人工是肯定不行的，需要搭建統(tǒng)一的部署運(yùn)維平臺(tái)。
服務(wù)編排
大部分情況下，微服務(wù)之間是相互獨(dú)立的，在進(jìn)行容器調(diào)度的時(shí)候不需要考慮彼此。
但有時(shí)候也會(huì)存在一些場(chǎng)景，比如服務(wù) A 調(diào)度的前提必須是先有服務(wù) B，這樣的話就要求在進(jìn)行容器調(diào)度的時(shí)候，還需要考慮服務(wù)之間的依賴關(guān)系。
Service Mesh
Service Mesh 的概念最早是由 Buoyant 公司的 CEO William Morgan 提出，他給出的服務(wù)網(wǎng)格的定義是：
A service mesh is a dedicated infrastructure layer for handling service-to-service communication. It’s responsible for the reliable delivery of requests through the complex topology of services that comprise a modern, cloud native application. In practice, the service mesh is typically implemented as an array of lightweight network proxies that are deployed alongside application code, without the application needing to be aware.
被很多人定義為下一代的微服務(wù)架構(gòu)。
目前，Service Mesh 的代表產(chǎn)品當(dāng)屬 Google 和 IBM 的 lstio。
Istio 的架構(gòu)可以說(shuō)由兩部分組成，分別是 Proxy 和 Control Plane。
Proxy： 與應(yīng)用程序部署在同一個(gè)主機(jī)上，應(yīng)用程序之間的調(diào)用都通過(guò) Proxy 來(lái)轉(zhuǎn)發(fā)，目前支持 HTTP/1.1、HTTP/2、gRPC 以及 TCP 請(qǐng)求。 Control Plane： 與 Proxy 通信，來(lái)實(shí)現(xiàn)各種服務(wù)治理功能，包括三個(gè)基本組件：Pilot、Mixer 以及 Citadel。
以上就是本文的全部?jī)?nèi)容，如果覺(jué)得還不錯(cuò)的話歡迎點(diǎn)贊，轉(zhuǎn)發(fā)和關(guān)注，感謝支持。
如果你也想學(xué)習(xí)微服務(wù)的話，我整理了一些資料，公眾號(hào)后臺(tái)回復(fù)「微服務(wù)」即可獲得。
參考資料：
《從 0 開(kāi)始學(xué)微服務(wù)》- 極客時(shí)間專欄
推薦閱讀：