一張圖瞭解Spring Cloud微服務架構
Spring Cloud作為當下主流的微服務框架，可以讓我們更簡單快捷地實現微服務架構。Spring Cloud並沒有重複製造輪子，它只是將目前各家公司開發的比較成熟、經得起實際考驗的服務框架組合起來，通過Spring Boot風格進行再封裝遮蔽掉了複雜的配置和實現原理，最終給開發者留出了一套簡單易懂、易部署和易維護的分散式系統開發工具包。Spring Cloud中各個元件在微服務架構中扮演的角色如下圖所示，黑線表示註釋說明，藍線由A指向B，表示B從A處獲取服務。
Spring Cloud組成的微服務架構圖
由上圖所示微服務架構大致由上圖的邏輯結構組成，其包括各種微服務、註冊發現、服務閘道器、熔斷器、統一配置、跟蹤服務等。下面說說Spring Cloud中的元件分別充當其中的什麼角色。
Fegin（介面呼叫）：微服務之間通過Rest介面通訊，Spring Cloud提供Feign框架來支援Rest的呼叫，Feign使得不同程序的Rest介面呼叫得以用優雅的方式進行，這種優雅表現得就像同一個程序呼叫一樣。
Netflix eureka（註冊發現）：微服務模式下，一個大的Web應用通常都被拆分為很多比較小的Web應用（服務），這個時候就需要有一個地方儲存這些服務的相關資訊，才能讓各個小的應用彼此知道對方，這個時候就需要在註冊中心進行註冊。每個應用啟動時向配置的註冊中心註冊自己的資訊（IP地址，埠號, 服務名稱等資訊），註冊中心將他們儲存起來，服務間相互呼叫的時候，通過服務名稱就可以到註冊中心找到對應的服務資訊，從而進行通訊。註冊與發現服務為微服務之間的呼叫帶來了方便，解決了硬編碼的問題。服務間只通過對方的服務ID，而無需知道其IP和埠即可以獲取對方方服務。
Ribbon（負載均衡）：Ribbon是Netflix釋出的負載均衡器，它有助於控制HTTP和TCP客戶端的行為。為Ribbon，配置服務提供者的地址列表後，Ribbon就可基於某種負載均衡演算法，自動地幫助服務消費者去請求。Ribbon預設為我們提供了很多的負載均衡演算法，例如輪詢、隨機等。當然，我們也可為Ribbon實現自定義的負載均衡演算法。在Spring Cloud中，當Ribbon與Eureka配合使用時，Ribbon可自動從EurekaServer獲取服務提供者的地址列表，並基於負載均衡演算法，請求其中一個服務提供者的例項（為了服務的可靠性，一個微服務可能部署多個例項）。
Hystrix（熔斷器）：當服務提供者響應非常緩慢，那麼消費者對提供者的請求就會被強制等待，直到提供者響應或超時。在高負載場景下，如果不做任何處理，此類問題可能會導致服務消費者的資源耗竭甚至整個系統的崩潰（雪崩效應）。Hystrix正是為了防止此類問題發生。Hystrix是由Netflix開源的一個延遲和容錯庫，用於隔離訪問遠端系統、服務或者第三方庫，防止級聯失敗，從而提升系統的可用性與容錯性。Hystrix主要通過以下幾點實現延遲和容錯。
- 包裹請求：使用HystrixCommand（或HystrixObservableCommand）包裹對依賴的呼叫邏輯，每個命令在獨立執行緒中執行。這使用了設計模式中的“命令模式”。
- 跳閘機制：當某服務的錯誤率超過一定閾值時，Hystrix可以自動或者手動跳閘，停止請求該服務一段時間。
- 資源隔離：Hystrix為每個依賴都維護了一個小型的執行緒池（或者訊號量）。如果該執行緒池已滿，發往該依賴的請求就被立即拒絕，而不是排隊等候，從而加速失敗判定。
- 監控：Hystrix可以近乎實時地監控執行指標和配置的變化，例如成功、失敗、超時和被拒絕的請求等。
- 回退機制：當請求失敗、超時、被拒絕，或當斷路器開啟時，執行回退邏輯。回退邏輯可由開發人員指定。
Zuul（微服務閘道器）：不同的微服務一般會有不同的網路地址，而外部客戶端可能需要呼叫多個服務的接口才能完成一個業務需求。例如一個電影購票的手機APP，可能呼叫多個微服務的接口才能完成一次購票的業務流程，如果讓客戶端直接與各個微服務通訊，會有以下的問題：
- 客戶端會多次請求不同的微服務，增加了客戶端的複雜性。
- 存在跨域請求，在一定場景下處理相對複雜。
- 認證複雜，每個服務都需要獨立認證。
- 難以重構，隨著專案的迭代，可能需要重新劃分微服務。例如，可能將多個服務合併成一個或者將一個服務拆分成多個。如果客戶端直接與微服務通訊，那麼重構將很難實施。
- 某些微服務可能使用了對防火牆/瀏覽器不友好的協議，直接訪問時會有一定的困難。
以上問題可藉助微服務閘道器解決。微服務閘道器是介於客戶端和伺服器端之間的中間層，所有的外部請求都會先經過微服務閘道器。使用微服務閘道器後，微服務閘道器將封裝應用程式的內部結構，客戶端只用跟閘道器互動，而無須直接呼叫特定微服務的介面。這樣，開發就可以得到簡化。不僅如此，使用微服務閘道器還有以下優點：
- 易於監控。可在微服務閘道器收集監控資料並將其推送到外部系統進行分析。
- 易於認證。可在微服務閘道器上進行認證，然後再將請求轉發到後端的微服務，而無須在每個微服務中進行認證。
- 減少了客戶端與各個微服務之間的互動次數。
Spring Cloud Bus（ 統一配置服務）：對於傳統的單體應用，常使用配置檔案管理所有配置。例如一個SpringBoot開發的單體應用，可將配置內容放在application.yml檔案中。如果需要切換環境，可設定多個Profile，並在啟動應用時指定spring.profiles.active={profile}。然而，在微服務架構中，微服務的配置管理一般有以下需求：
- 集中管理配置。一個使用微服務架構的應用系統可能會包含成百上千個微服務，因此集中管理配置是非常有必要的。
- 不同環境，不同配置。例如，資料來源配置在不同的環境（開發、測試、預釋出、生產等）中是不同的。
- 執行期間可動態調整。例如，可根據各個微服務的負載情況，動態調整資料來源連線池大小或熔斷閾值，並且在調整配置時不停止微服務。
- 配置修改後可自動更新。如配置內容發生變化，微服務能夠自動更新配置。綜上所述，對於微服務架構而言，一個通用的配置管理機制是必不可少的，常見做法是使用配置伺服器管理配置。Spring Cloud Bus利用Git或SVN等管理配置、採用Kafka或者RabbitMQ等訊息匯流排通知所有應用，從而實現配置的自動更新並且重新整理所有微服務例項的配置。
Sleuth+ZipKin（跟蹤服務）：Sleuth和Zipkin結合使用可以通過圖形化的介面檢視微服務請求的延遲情況以及各個微服務的依賴情況。需要注意的是Spring Boot 2及以上不在支援Zipkin的自定義，需要到官方網站下載ZipKin相關的jar包。另外需要提一點的是Spring Boot Actuator，提供了很多監控端點如/actuator/info、/actuator/health、/acutator/refresh等，可以檢視微服務的資訊、健康狀況、重新整理配置等。
原文連結： 一張圖瞭解Spring Cloud微服務架構 （作者：SimpleEasy）