摘要：口服務(wù)的負(fù)載均衡。服務(wù)的注冊(cè)與發(fā)現(xiàn)接口管理服務(wù)注冊(cè)是指向服務(wù)注冊(cè)中心注冊(cè)一個(gè)服務(wù)實(shí)例，服務(wù)提供者將自己的服務(wù)信息如服務(wù)名地址等告知服務(wù)注冊(cè)中心。服務(wù)注冊(cè)中心會(huì)提供服務(wù)的健康檢查方案，檢查被注冊(cè)的服務(wù)是否可用。服務(wù)降級(jí)的功能。

微服務(wù)具有以下的特點(diǎn)。

口 按照業(yè)務(wù)來劃分服務(wù)，單個(gè)服務(wù)代碼量小，業(yè)務(wù)單一，易于維護(hù)。 
口 每個(gè)微服務(wù)都有自己獨(dú)立的基礎(chǔ)組件，例如數(shù)據(jù)庫、 緩存等，且運(yùn)行在獨(dú)立的進(jìn)程中。 
口 微服務(wù)之間的通信是通過 HTTP 協(xié)議或者消息組件，且具有容錯(cuò)能力。 
口 微服務(wù)有一套服務(wù)治理的解決方案，服務(wù)之間不相合，可以隨時(shí)加入和剔除服務(wù)。 
口 單個(gè)微服務(wù)能夠集群化部署，并且有負(fù)載均衡的能力。 
口 整個(gè)微服務(wù)系統(tǒng)應(yīng)該有一個(gè)完整的安全機(jī)制，包括用戶驗(yàn)證、權(quán)限驗(yàn)證、資源保護(hù)等。 
口 整個(gè)微服務(wù)系統(tǒng)有鏈路追蹤的能力。 
口 有一套完整的實(shí)時(shí)日志系統(tǒng)。

微服務(wù)的功能主要 體現(xiàn)在以下兒個(gè)方面。

口 服務(wù)的注冊(cè)和發(fā)現(xiàn)。 
口 服務(wù)的負(fù)載均衡。 
口 服務(wù)的容錯(cuò)。 
口 服務(wù)網(wǎng)關(guān)。 
口 服務(wù)配置的統(tǒng)一管理。 
口 鏈路追蹤。 
口 實(shí)時(shí)日志。

服務(wù)注冊(cè)是指向服務(wù)注冊(cè)中心注冊(cè)一個(gè)服務(wù)實(shí)例，服務(wù)提供者將自己的服務(wù)信息（如服務(wù) 名、 IP 地址等〉告知服務(wù)注冊(cè)中心。服務(wù)發(fā)現(xiàn)是指當(dāng)服務(wù)消費(fèi)者需要消費(fèi)另外一個(gè)服務(wù)時(shí)， 服務(wù)注冊(cè)中心能夠告知服務(wù)消費(fèi)者它所要消費(fèi)服務(wù)的實(shí)例信息（如服務(wù)名、 IP 地址等〉。通常 情況下， 一個(gè)服務(wù)既是服務(wù)提供者，也是服務(wù)消費(fèi)者。服務(wù)消費(fèi)者一般使用 HTTP 協(xié)議或者消息組件這種輕盤級(jí)的通信機(jī)制來進(jìn)行服務(wù)消費(fèi)。

服務(wù)注冊(cè)中心會(huì)提供服務(wù)的健康檢查方案，檢查被注冊(cè)的服務(wù)是否可用。通常一個(gè)服 務(wù)實(shí)例注冊(cè)后，會(huì)定時(shí)向服務(wù)注冊(cè)中心提供 “心跳”，以表明自己還處于可用的狀態(tài)。當(dāng)一個(gè)服務(wù)實(shí)例停止向服務(wù)注冊(cè)中心提供心跳一 段時(shí)間后，服務(wù)注冊(cè)中心會(huì)認(rèn)為該服務(wù)實(shí)例不可用，會(huì)將該服務(wù)實(shí)例從服務(wù)注冊(cè)列表中刪除。如果這個(gè)被刪除掉的服務(wù)實(shí)例過一段時(shí)間 后繼續(xù)向注冊(cè)中心提供心跳，那么服務(wù)注冊(cè)中心會(huì)將該服務(wù)實(shí)例重新加入服務(wù)注冊(cè)中心的列表中。另外，微服務(wù)的服務(wù)注冊(cè)組件都會(huì)提供服 務(wù)的健康狀況查看的 UI 界面，開發(fā)人員或者運(yùn)維人員只需要登錄相關(guān)的界面就可以知道服務(wù) 的健康狀態(tài)。

在微服務(wù)架構(gòu) ，服務(wù)之間的相互調(diào)用一般是通過 HTTP 通信協(xié)議來實(shí)現(xiàn)的。網(wǎng)絡(luò)往往具有不可靠性，為了保證服務(wù)的高可用（High Availability），服務(wù)單元往往是集群化部署。將服務(wù)提供者進(jìn)行集群化部署， 那么服務(wù)消費(fèi)者該調(diào)用哪個(gè)服務(wù)提供者的實(shí)例呢？這就涉及到 了服務(wù)的負(fù)載均衡。

所有的服務(wù)都向服務(wù)注冊(cè)中心注冊(cè)，服務(wù)注冊(cè)中心持有每個(gè)服務(wù)的應(yīng)用名和 IP 地址等信息，同時(shí)每個(gè)服務(wù)也會(huì)獲取所有服務(wù)注冊(cè)列表信息。

服務(wù)消費(fèi)者集成負(fù)載均衡組件，該組件會(huì)向服務(wù)消費(fèi)者獲取服務(wù)注冊(cè)列表信息，并每隔一段時(shí)間重新刷新獲取該列表。當(dāng)服務(wù)消費(fèi)者消費(fèi)服務(wù)時(shí)，負(fù)載均衡組件獲取服務(wù)提供者所 有實(shí)例的注冊(cè)信息，并通過一定的負(fù)載均衡策略（開發(fā)者可以配置〉，選擇一個(gè)服務(wù)提供者的 實(shí)例，向該實(shí)例進(jìn)行服務(wù)消費(fèi)，這樣就實(shí)現(xiàn)了負(fù)載均衡。
服務(wù)注冊(cè)中心不但需要定時(shí)接收每個(gè)服務(wù)的心跳（用來檢查服務(wù)是否可用），而且每 個(gè)服務(wù)會(huì)定期獲取服務(wù)注冊(cè)列表的信息，當(dāng)服務(wù)實(shí)例數(shù)量很多時(shí)，服務(wù)注冊(cè)中心承擔(dān)了 非常大的負(fù)載。由于服務(wù)注冊(cè)中心在微服務(wù)系統(tǒng)中起到了至關(guān)重要的作用，所以必須實(shí) 現(xiàn)高可用。 一般的做法是將服務(wù)注冊(cè)中心集群化，每個(gè)服務(wù)注冊(cè)中心的數(shù)據(jù)實(shí)時(shí)同步， 如圖 2-3 所示。

將資源進(jìn)行隔離，如果某個(gè)服務(wù)里的某個(gè) API 接口出現(xiàn)了故障，只會(huì)隔離該 API 接 口。不會(huì)影響到其他 API 接口。被隔離的 API 接口會(huì)執(zhí)行快速失敗的邏輯，不會(huì)等待，請(qǐng)求不會(huì)阻塞。如果不進(jìn)行這種隔離， 請(qǐng)求會(huì)一直處于阻塞狀態(tài)， 直到超時(shí)。若 有大量的請(qǐng)求同時(shí)涌入，都處于阻塞的狀態(tài)，服務(wù)器的線程資源， 迅速被消耗完。

服務(wù)降級(jí)的功能。當(dāng)服務(wù)處于正常的狀態(tài)時(shí)，大量的請(qǐng)求在短時(shí)間內(nèi)同時(shí)涌入，超過了服務(wù)的處理能力，這時(shí)熔斷器會(huì)被打開，將服務(wù)降級(jí)，以免服務(wù)器因負(fù)載過高而出 現(xiàn)故障。

自我修復(fù)能力。當(dāng)因某個(gè)微小的故障，例如網(wǎng)絡(luò)服務(wù)商的問題，導(dǎo)致網(wǎng)絡(luò)在短時(shí)間內(nèi) 不可用， 熔斷器被打開。如果不能自我監(jiān)控、自我檢測和自我修復(fù)， 那么需要開發(fā)人 員手動(dòng)地去關(guān)閉熔斷器，無疑會(huì)增加開發(fā)人員的工作量。

Netflix 的 Hystrix 熔斷器開源組件功能非常強(qiáng)大，不僅有烙斷器的功能，還有熔斷器的狀態(tài) 監(jiān)測，并提供界面友好的 UI， 開發(fā)人員或者運(yùn)維人員通過 UI 界面能夠直觀地看到熔斷器的狀 態(tài)和各種性能指標(biāo)。
其余就不做多余講解了，有興趣的同學(xué)可以看看前面的文章。

微服務(wù)系統(tǒng)通過將資源以 API 接口的形式暴露給外界來提供服務(wù)。在微服務(wù)系統(tǒng)中， API 接口資源通常是由服務(wù)網(wǎng)關(guān)（也稱 API 網(wǎng)關(guān)〉統(tǒng)一暴露，內(nèi)部服務(wù)不直接對(duì)外提供 API 資源 的暴露。 這樣做的好處是將內(nèi)部服務(wù)隱藏起來，外界還以為是一個(gè)服務(wù)在提供服務(wù)，在一定程 度上保護(hù)了微服務(wù)系統(tǒng)的安全。 API 網(wǎng)關(guān)通常有請(qǐng)求轉(zhuǎn)發(fā)的作用， 另外它可能需要負(fù)責(zé)一定的 安全驗(yàn)證，例如判斷某個(gè)請(qǐng)求是否合法，該請(qǐng)求對(duì)某一個(gè)資源是否具有操作權(quán)限等。通常情況 ，網(wǎng)關(guān)層以集群的形式存在。在服務(wù)網(wǎng)關(guān)層之前，有可能需要加上負(fù)載均衡層，通常為 Nginx 雙機(jī)熱備，通過一定的路由策略， 將請(qǐng)求轉(zhuǎn)發(fā)到網(wǎng)關(guān)層。到達(dá)網(wǎng)關(guān)層后，經(jīng)過一系列的用戶身 份驗(yàn)證、權(quán)限判斷， 最終轉(zhuǎn)發(fā)到具體的服務(wù)。具體的服務(wù)經(jīng)過一系列的邏輯運(yùn)算和數(shù)據(jù)操作， 最終將結(jié)果返回給用戶 ，此時(shí)的架構(gòu)如圖 2-6 所示。

網(wǎng)關(guān)層具有很重要的意義， 具體體現(xiàn)在以下方面。

網(wǎng)關(guān)將所有服務(wù)的 API 接口資源統(tǒng)一聚合，對(duì)外統(tǒng)一暴露，外界系統(tǒng)調(diào)用的 API 接口都是網(wǎng)關(guān)對(duì)外暴露的 API 接口。外界系統(tǒng)不需要知道微服務(wù)架構(gòu)中各服務(wù)相互調(diào)用的復(fù)雜性，微服務(wù)系統(tǒng)也保護(hù)了其內(nèi)部微服務(wù)單元的 API接口，防止被外界直接調(diào)用以及服務(wù)的敏感信息對(duì)外暴露。

網(wǎng)關(guān)可以做一些用戶身份認(rèn)證、權(quán)限認(rèn)證，防止非法請(qǐng)求操作 API 接口，對(duì)內(nèi)部服務(wù)起到保護(hù)作用。再前面講過就不再多做描述，有興趣學(xué)習(xí)的同學(xué)可以到前面再看下。

網(wǎng)關(guān)可以實(shí)現(xiàn)監(jiān)控功能，實(shí)時(shí)日志輸出，對(duì)請(qǐng)求進(jìn)行記錄。

網(wǎng)關(guān)可以用來做流量監(jiān)控，在高流量的情況下，對(duì)服務(wù)進(jìn)行降級(jí)。

實(shí)現(xiàn)這些功能，需要做高可用，否則網(wǎng)關(guān)很可能成為架構(gòu)中的瓶頸。 最常用的 網(wǎng)關(guān)組件有 Zuul、 Nginx 等。

在微服務(wù)架構(gòu)中，需要有統(tǒng)一管理配置文件的組件， 例如 Spring Cloud 的 Spring Cloud Config 組件、阿里的 Diamond、百度的 Disconf、攜程的 Apollo 等。 這些配置組件所實(shí)現(xiàn)的功 能大體相同，｛旦又有些差別，下面以 Spring Cloud Config 為例來闡述服務(wù)配置的統(tǒng)一管理。

首先， Config Server（配置服務(wù)〉讀取配置文件倉庫的配置信息，其中配置文件倉庫可以存放在配置服務(wù)的本地倉庫，也可以放在遠(yuǎn)程的 Git 倉庫（例如GitHub、 Coding 等〉。

配置服務(wù)啟動(dòng)后，讀取配置文件信息，讀取完成的配置信息存放在配置服務(wù)的內(nèi)存中。

當(dāng)啟動(dòng)服務(wù) A、B 時(shí)，由于服務(wù) A、B 指定了向配置服務(wù)讀取配置信息，服務(wù) A、B 向配置服務(wù)讀取配置信息。

當(dāng)服務(wù)的配置信息需要修改且修改完成后，向配置服務(wù)發(fā)送 Post 請(qǐng)求進(jìn)行刷新，這 時(shí)服務(wù) A、B 會(huì)向配置服務(wù)重寫讀取配置文件。

對(duì)于集群化的服務(wù)， 可以通過使用消息總線來刷新多個(gè)服務(wù)實(shí)例。如果服務(wù)數(shù)量較多，對(duì)配置 中心需要考慮集群化部署，從而使配置中心高可用，做分布式集群。

在微服務(wù)系統(tǒng)中 ， 一個(gè)來自用戶 的請(qǐng)求先達(dá)到前端 A C如前端界面），然后通過遠(yuǎn)程調(diào)用，達(dá)到 系統(tǒng)的中間件 B、 c （如負(fù)載均衡、網(wǎng)關(guān)等），最后達(dá)到后端服 務(wù) D、 E。后端經(jīng)過一系列的業(yè)務(wù)邏輯計(jì)算，最后將數(shù)據(jù)返回給 用戶。對(duì)于這樣一個(gè)請(qǐng)求， 經(jīng)歷了這么多服務(wù)， 怎么樣將它的 請(qǐng)求過程的數(shù)據(jù)記錄下來呢？這就需要用到服務(wù)鏈路追蹤。
目前，常見的鏈路追蹤組件有 Google 的 Dapper、 Twitter 的 Zipkin，以及阿里的 Eagleeye （鷹眼）等，都是非常優(yōu)秀的鏈路追蹤開源組件。