深刻理解Spring Cloud與微服務構建【二】 - 2.1 微服務應該具有的功能

微服務具備如下的特色。

口 按照業務來劃分服務，單個服務代碼量小，業務單一，易於維護。 
口 每一個微服務都有本身獨立的基礎組件，例如數據庫、 緩存等，且運行在獨立的進程中。 
口 微服務之間的通訊是經過 HTTP 協議或者消息組件，且具備容錯能力。 
口 微服務有一套服務治理的解決方案，服務之間不相合，能夠隨時加入和剔除服務。 
口 單個微服務可以集羣化部署，而且有負載均衡的能力。 
口 整個微服務系統應該有一個完整的安全機制，包括用戶驗證、權限驗證、資源保護等。 
口 整個微服務系統有鏈路追蹤的能力。 
口 有一套完整的實時日誌系統。

微服務的功能主要 體如今如下兒個方面。

口 服務的註冊和發現。 
口 服務的負載均衡。 
口 服務的容錯。 
口 服務網關。 
口 服務配置的統一管理。 
口 鏈路追蹤。 
口 實時日誌。

2.1.1 服務的註冊與發現（接口管理）

• 服務註冊是指向服務註冊中心註冊一個服務實例，服務提供者將本身的服務信息（如服務 名、 IP 地址等〉告知服務註冊中心。服務發現是指當服務消費者須要消費另一個服務時， 服務註冊中心可以告知服務消費者它所要消費服務的實例信息（如服務名、 IP 地址等〉。一般 狀況下， 一個服務既是服務提供者，也是服務消費者。服務消費者通常使用 HTTP 協議或者消息組件這種輕盤級的通訊機制來進行服務消費。

• 服務註冊中心會提供服務的健康檢查方案，檢查被註冊的服務是否可用。一般一個服 務實例註冊後，會定時向服務註冊中心提供 「心跳」，以代表本身還處於可用的狀態。當一個服務實例中止向服務註冊中心提供心跳一 段時間後，服務註冊中心會認爲該服務實例不可用，會將該服務實例從服務註冊列表中刪除。若是這個被刪除掉的服務實例過一段時間 後繼續向註冊中心提供心跳，那麼服務註冊中心會將該服務實例從新加入服務註冊中心的列表中。另外，微服務的服務註冊組件都會提供服 務的健康情況查看的 UI 界面，開發人員或者運維人員只須要登陸相關的界面就能夠知道服務 的健康狀態。

2.1 .2 服務的負載均衡（分發請求）

• 在微服務架構 ，服務之間的相互調用通常是經過 HTTP 通訊協議來實現的。網絡每每具備不可靠性，爲了保證服務的高可用（High Availability），服務單元每每是集羣化部署。將服務提供者進行集羣化部署， 那麼服務消費者該調用哪一個服務提供者的實例呢？這就涉及到 了服務的負載均衡。

全部的服務都向服務註冊中心註冊，服務註冊中心持有每一個服務的應用名和 IP 地址等信息，同時每一個服務也會獲取全部服務註冊列表信息。

服務消費者集成負載均衡組件，該組件會向服務消費者獲取服務註冊列表信息，並每隔一段時間從新刷新獲取該列表。當服務消費者消費服務時，負載均衡組件獲取服務提供者所 有實例的註冊信息，並經過必定的負載均衡策略（開發者能夠配置〉，選擇一個服務提供者的 實例，向該實例進行服務消費，這樣就實現了負載均衡。
服務註冊中心不但須要定時接收每一個服務的心跳（用來檢查服務是否可用），並且每 個服務會按期獲取服務註冊列表的信息，當服務實例數量不少時，服務註冊中心承擔了 很是大的負載。因爲服務註冊中心在微服務系統中起到了相當重要的做用，因此必須實 現高可用。 通常的作法是將服務註冊中心集羣化，每一個服務註冊中心的數據實時同步， 如圖 2-3 所示。

2.1.3 服務的容錯（防止雪崩效應）

1. 將資源進行隔離，若是某個服務裏的某個 API 接口出現了故障，只會隔離該 API 接 口。不會影響到其餘 API 接口。被隔離的 API 接口會執行快速失敗的邏輯，不會等待，請求不會阻塞。若是不進行這種隔離， 請求會一直處於阻塞狀態， 直到超時。若 有大量的請求同時涌入，都處於阻塞的狀態，服務器的線程資源， 迅速被消耗完。
2. 服務降級的功能。當服務處於正常的狀態時，大量的請求在短期內同時涌入，超過了服務的處理能力，這時熔斷器會被打開，將服務降級，以避免服務器因負載太高而出 現故障。
3. 自我修復能力。當因某個微小的故障，例如網絡服務商的問題，致使網絡在短期內 不可用， 熔斷器被打開。若是不能自我監控、自我檢測和自我修復， 那麼須要開發人 員手動地去關閉熔斷器，無疑會增長開發人員的工做量。

Netflix 的 Hystrix 熔斷器開源組件功能很是強大，不只有烙斷器的功能，還有熔斷器的狀態 監測，並提供界面友好的 UI， 開發人員或者運維人員經過 UI 界面可以直觀地看到熔斷器的狀 態和各類性能指標。
其他就不作多餘講解了，有興趣的同窗能夠看看前面的文章。

2.1.4 服務網關（接口統一暴露）

微服務系統經過將資源以 API 接口的形式暴露給外界來提供服務。在微服務系統中， API 接口資源一般是由服務網關（也稱 API 網關〉統一暴露，內部服務不直接對外提供 API 資源 的暴露。 這樣作的好處是將內部服務隱藏起來，外界還覺得是一個服務在提供服務，在必定程 度上保護了微服務系統的安全。 API 網關一般有請求轉發的做用， 另外它可能須要負責必定的 安全驗證，例如判斷某個請求是否合法，該請求對某一個資源是否具備操做權限等。一般狀況 ，網關層以集羣的形式存在。在服務網關層以前，有可能須要加上負載均衡層，一般爲 Nginx 雙機熱備，經過必定的路由策略， 將請求轉發到網關層。到達網關層後，通過一系列的用戶身 份驗證、權限判斷， 最終轉發到具體的服務。具體的服務通過一系列的邏輯運算和數據操做， 最終將結果返回給用戶 ，此時的架構如圖 2-6 所示。

網關層具備很重要的意義， 具體體如今如下方面。

• 網關將全部服務的 API 接口資源統一聚合，對外統一暴露，外界系統調用的 API 接口都是網關對外暴露的 API 接口。外界系統不須要知道微服務架構中各服務相互調用的複雜性，微服務系統也保護了其內部微服務單元的 API接口，防止被外界直接調用以及服務的敏感信息對外暴露。
• 網關能夠作一些用戶身份認證、權限認證，防止非法請求操做 API 接口，對內部服務起到保護做用。再前面講過就再也不多作描述，有興趣學習的同窗能夠到前面再看下。
• 網關能夠實現監控功能，實時日誌輸出，對請求進行記錄。
• 網關能夠用來作流量監控，在高流量的狀況下，對服務進行降級。

實現這些功能，須要作高可用，不然網關極可能成爲架構中的瓶頸。 最經常使用的 網關組件有 Zuul、 Nginx 等。

2.1 .5 服務配置的統一管理

在微服務架構中，須要有統一管理配置文件的組件， 例如 Spring Cloud 的 Spring Cloud Config 組件、阿里的 Diamond、百度的 Disconf、攜程的 Apollo 等。 這些配置組件所實現的功 能大致相同，｛旦又有些差異，下面以 Spring Cloud Config 爲例來闡述服務配置的統一管理。

1. 首先， Config Server（配置服務〉讀取配置文件倉庫的配置信息，其中配置文件倉庫能夠存放在配置服務的本地倉庫，也能夠放在遠程的 Git 倉庫（例如GitHub、 Coding 等〉。
2. 配置服務啓動後，讀取配置文件信息，讀取完成的配置信息存放在配置服務的內存中。
3. 當啓動服務 A、B 時，因爲服務 A、B 指定了向配置服務讀取配置信息，服務 A、B 向配置服務讀取配置信息。
4. 當服務的配置信息須要修改且修改完成後，向配置服務發送 Post 請求進行刷新，這 時服務 A、B 會向配置服務重寫讀取配置文件。

對於集羣化的服務， 能夠經過使用消息總線來刷新多個服務實例。若是服務數量較多，對配置 中心須要考慮集羣化部署，從而使配置中心高可用，作分佈式集羣。

2.1.6 服務鏈路追蹤

在微服務系統中 ， 一個來自用戶 的請求先達到前端 A C如前端界面），而後經過遠程調用，達到 系統的中間件 B、 c （如負載均衡、網關等），最後達到後端服 務 D、 E。後端通過一系列的業務邏輯計算，最後將數據返回給 用戶。對於這樣一個請求， 經歷了這麼多服務， 怎麼樣將它的 請求過程的數據記錄下來呢？這就須要用到服務鏈路追蹤。
目前，常見的鏈路追蹤組件有 Google 的 Dapper、 Twitter 的 Zipkin，以及阿里的 Eagleeye （鷹眼）等，都是很是優秀的鏈路追蹤開源組件。