一張圖了解Spring Cloud微服務架構(gòu)

liang1234_ 2019-05-26

展開全文

作者：SimpleEasy
原文鏈接：https://www.jianshu.com/p/84d2824980fe

Spring Cloud作為當下主流的微服務框架，可以讓我們更簡單快捷地實現(xiàn)微服務架構(gòu)。Spring Cloud并沒有重復制造輪子，它只是將目前各家公司開發(fā)的比較成熟、經(jīng)得起實際考驗的服務框架組合起來，通過Spring Boot風格進行再封裝屏蔽掉了復雜的配置和實現(xiàn)原理，最終給開發(fā)者留出了一套簡單易懂、易部署和易維護的分布式系統(tǒng)開發(fā)工具包。Spring Cloud中各個組件在微服務架構(gòu)中扮演的角色如下圖所示，黑線表示注釋說明，藍線由A指向B，表示B從A處獲取服務。

Spring Cloud組成的微服務架構(gòu)圖

由上圖所示微服務架構(gòu)大致由上圖的邏輯結(jié)構(gòu)組成，其包括各種微服務、注冊發(fā)現(xiàn)、服務網(wǎng)關(guān)、熔斷器、統(tǒng)一配置、跟蹤服務等。下面說說Spring Cloud中的組件分別充當其中的什么角色。

Fegin（接口調(diào)用）：微服務之間通過Rest接口通訊，Spring Cloud提供Feign框架來支持Rest的調(diào)用，F(xiàn)eign使得不同進程的Rest接口調(diào)用得以用優(yōu)雅的方式進行，這種優(yōu)雅表現(xiàn)得就像同一個進程調(diào)用一樣。

Netflix eureka（注冊發(fā)現(xiàn)）：微服務模式下，一個大的Web應用通常都被拆分為很多比較小的Web應用（服務），這個時候就需要有一個地方保存這些服務的相關(guān)信息，才能讓各個小的應用彼此知道對方，這個時候就需要在注冊中心進行注冊。每個應用啟動時向配置的注冊中心注冊自己的信息（IP地址，端口號, 服務名稱等信息），注冊中心將他們保存起來，服務間相互調(diào)用的時候，通過服務名稱就可以到注冊中心找到對應的服務信息，從而進行通訊。注冊與發(fā)現(xiàn)服務為微服務之間的調(diào)用帶來了方便，解決了硬編碼的問題。服務間只通過對方的服務ID，而無需知道其IP和端口即可以獲取對方方服務。

Ribbon（負載均衡）：Ribbon是Netflix發(fā)布的負載均衡器，它有助于控制HTTP和TCP客戶端的行為。為Ribbon，配置服務提供者的地址列表后，Ribbon就可基于某種負載均衡算法，自動地幫助服務消費者去請求。Ribbon默認為我們提供了很多的負載均衡算法，例如輪詢、隨機等。當然，我們也可為Ribbon實現(xiàn)自定義的負載均衡算法。在Spring Cloud中，當Ribbon與Eureka配合使用時，Ribbon可自動從EurekaServer獲取服務提供者的地址列表，并基于負載均衡算法，請求其中一個服務提供者的實例（為了服務的可靠性，一個微服務可能部署多個實例）。

Hystrix（熔斷器）：當服務提供者響應非常緩慢，那么消費者對提供者的請求就會被強制等待，直到提供者響應或超時。在高負載場景下，如果不做任何處理，此類問題可能會導致服務消費者的資源耗竭甚至整個系統(tǒng)的崩潰（雪崩效應）。Hystrix正是為了防止此類問題發(fā)生。Hystrix是由Netflix開源的一個延遲和容錯庫，用于隔離訪問遠程系統(tǒng)、服務或者第三方庫，防止級聯(lián)失敗，從而提升系統(tǒng)的可用性與容錯性。Hystrix主要通過以下幾點實現(xiàn)延遲和容錯。

包裹請求：使用HystrixCommand（或HystrixObservableCommand）包裹對依賴的調(diào)用邏輯，每個命令在獨立線程中執(zhí)行。這使用了設計模式中的“命令模式”。
跳閘機制：當某服務的錯誤率超過一定閾值時，Hystrix可以自動或者手動跳閘，停止請求該服務一段時間。
資源隔離：Hystrix為每個依賴都維護了一個小型的線程池（或者信號量）。如果該線程池已滿，發(fā)往該依賴的請求就被立即拒絕，而不是排隊等候，從而加速失敗判定。
監(jiān)控：Hystrix可以近乎實時地監(jiān)控運行指標和配置的變化，例如成功、失敗、超時和被拒絕的請求等。
回退機制：當請求失敗、超時、被拒絕，或當斷路器打開時，執(zhí)行回退邏輯。回退邏輯可由開發(fā)人員指定。

Zuul（微服務網(wǎng)關(guān)）：不同的微服務一般會有不同的網(wǎng)絡地址，而外部客戶端可能需要調(diào)用多個服務的接口才能完成一個業(yè)務需求。例如一個電影購票的手機APP，可能調(diào)用多個微服務的接口才能完成一次購票的業(yè)務流程，如果讓客戶端直接與各個微服務通信，會有以下的問題：

客戶端會多次請求不同的微服務，增加了客戶端的復雜性。
存在跨域請求，在一定場景下處理相對復雜。
認證復雜，每個服務都需要獨立認證。
難以重構(gòu)，隨著項目的迭代，可能需要重新劃分微服務。例如，可能將多個服務合并成一個或者將一個服務拆分成多個。如果客戶端直接與微服務通信，那么重構(gòu)將很難實施。
某些微服務可能使用了對防火墻/瀏覽器不友好的協(xié)議，直接訪問時會有一定的困難。

以上問題可借助微服務網(wǎng)關(guān)解決。微服務網(wǎng)關(guān)是介于客戶端和服務器端之間的中間層，所有的外部請求都會先經(jīng)過微服務網(wǎng)關(guān)。使用微服務網(wǎng)關(guān)后，微服務網(wǎng)關(guān)將封裝應用程序的內(nèi)部結(jié)構(gòu)，客戶端只用跟網(wǎng)關(guān)交互，而無須直接調(diào)用特定微服務的接口。這樣，開發(fā)就可以得到簡化。不僅如此，使用微服務網(wǎng)關(guān)還有以下優(yōu)點：

易于監(jiān)控?？稍谖⒎站W(wǎng)關(guān)收集監(jiān)控數(shù)據(jù)并將其推送到外部系統(tǒng)進行分析。
易于認證。可在微服務網(wǎng)關(guān)上進行認證，然后再將請求轉(zhuǎn)發(fā)到后端的微服務，而無須在每個微服務中進行認證。
減少了客戶端與各個微服務之間的交互次數(shù)。

Spring Cloud Bus（統(tǒng)一配置服務）：對于傳統(tǒng)的單體應用，常使用配置文件管理所有配置。例如一個SpringBoot開發(fā)的單體應用，可將配置內(nèi)容放在application.yml文件中。如果需要切換環(huán)境，可設置多個Profile，并在啟動應用時指定spring.profiles.active={profile}。然而，在微服務架構(gòu)中，微服務的配置管理一般有以下需求：

集中管理配置。一個使用微服務架構(gòu)的應用系統(tǒng)可能會包含成百上千個微服務，因此集中管理配置是非常有必要的。
不同環(huán)境，不同配置。例如，數(shù)據(jù)源配置在不同的環(huán)境（開發(fā)、測試、預發(fā)布、生產(chǎn)等）中是不同的。
運行期間可動態(tài)調(diào)整。例如，可根據(jù)各個微服務的負載情況，動態(tài)調(diào)整數(shù)據(jù)源連接池大小或熔斷閾值，并且在調(diào)整配置時不停止微服務。
配置修改后可自動更新。如配置內(nèi)容發(fā)生變化，微服務能夠自動更新配置。綜上所述，對于微服務架構(gòu)而言，一個通用的配置管理機制是必不可少的，常見做法是使用配置服務器管理配置。Spring Cloud Bus利用Git或SVN等管理配置、采用Kafka或者RabbitMQ等消息總線通知所有應用，從而實現(xiàn)配置的自動更新并且刷新所有微服務實例的配置。

Sleuth ZipKin（跟蹤服務）：Sleuth和Zipkin結(jié)合使用可以通過圖形化的界面查看微服務請求的延遲情況以及各個微服務的依賴情況。需要注意的是Spring Boot 2及以上不在支持Zipkin的自定義，需要到官方網(wǎng)站下載ZipKin相關(guān)的jar包。另外需要提一點的是Spring Boot Actuator，提供了很多監(jiān)控端點如/actuator/info、/actuator/health、/acutator/refresh等，可以查看微服務的信息、健康狀況、刷新配置等。