7個點說清楚spring cloud微服務架構

前言

spring cloud做爲當下主流的微服務框架，讓咱們實現微服務架構簡單快捷，spring cloud中各個組件在微服務架構中扮演的角色以下圖所示，黑線表示註釋說明，藍線由A指向B，表示B從A處獲取服務。

spring cloud組成的微服務架構圖

由上圖所示微服務架構大體由上圖的邏輯結構組成，其包括各類微服務、註冊發現、服務網關、熔斷器、統一配置、跟蹤服務等。下面說說spring cloud中的組件分別充當其中的什麼角色。

Feign

Feign(接口調用)：微服務之間經過Rest接口通信，spring Cloud提供Feign框架來支持Rest的調用，Feign使得不一樣進程的Rest接口調用得以用優雅的方式進行，這種優雅表現得就像同一個進程調用同樣。

Eureka

Netflix eureka(註冊發現)：微服務模式下，一個大的Web應用一般都被拆分爲不少比較小的web應用(服務)，這個時候就須要有一個地方保存這些服務的相關信息，才能讓各個小的應用彼此知道對方，這個時候就須要在註冊中心進行註冊。每一個應用啓動時向配置的註冊中心註冊本身的信息（ip地址，端口號, 服務名稱等信息），註冊中心將他們保存起來，服務間相互調用的時候，經過服務名稱就能夠到註冊中心找到對應的服務信息，從而進行通信。註冊與發現服務爲微服務之間的調用帶來了方便，解決了硬編碼的問題。服務間只經過對方的服務id，而無需知道其ip和端口便可以獲取對方方服務。

Ribbon

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

Hystrix

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

包裹請求：

使用HystrixCommand（或HystrixObservableCommand）包裹對依賴的調用邏輯，每一個命令在獨立線程中執行。這使用了設計模式中的「命令模式」。

跳閘機制：

當某服務的錯誤率超過必定閾值時，Hystrix能夠自動或者手動跳閘，中止請求該服務一段時間。

資源隔離：

Hystrix爲每一個依賴都維護了一個小型的線程池（或者信號量）。若是該線程池已滿，發往該依賴的請求就被當即拒絕，而不是排隊等候，從而加速失敗斷定。

監控：

Hystrix能夠近乎實時地監控運行指標和配置的變化，例如成功、失敗、超時和被拒絕的請求等。

回退機制：

當請求失敗、超時、被拒絕，或當斷路器打開時，執行回退邏輯。回退邏輯可由開發人員指定。

Zuul

Zuul(微服務網關) ：不一樣的微服務通常會有不一樣的網絡地址，而外部客戶端可能須要調用多個服務的接口才能完成一個業務需求。例如一個電影購票的手機APP，可能調用多個微服務的接口才能完成一次購票的業務流程，若是讓客戶端直接與各個微服務通訊，會有如下的問題：

客戶端會屢次請求不一樣的微服務，增長了客戶端的複雜性。

存在跨域請求，在必定場景下處理相對複雜。

認證複雜，每一個服務都須要獨立認證。

難以重構，隨着項目的迭代，可能須要從新劃分微服務。例如，可能將多個服務合併成一個或者將一個服務拆分紅多個。若是客戶端直接與微服務通訊，那麼重構將很難實施。

某些微服務可能使用了對防火牆/瀏覽器不友好的協議，直接訪問時會有必定的困難。

以上問題可藉助微服務網關解決。微服務網關是介於客戶端和服務器端之間的中間層，全部的外部請求都會先通過微服務網關。使用微服務網關後，微服務網關將封裝應用程序的內部結構，客戶端只用跟網關交互，而無須直接調用特定微服務的接口。這樣，開發就能夠獲得簡化。不只如此，使用微服務網關還有如下優勢：

易於監控。可在微服務網關收集監控數據並將其推送到外部系統進行分析。

易於認證。可在微服務網關上進行認證，而後再將請求轉發到後端的微服務，而無須在每一個微服務中進行認證。

減小了客戶端與各個微服務之間的交互次數。

Config

spring cloud Config（ 統一配置服務）：對於傳統的單體應用，常使用配置文件管理全部配置。例如一個springBoot開發的單體應用，可將配置內容放在application.yml文件中。若是須要切換環境，可設置多個Profile，並在啓動應用時指定spring.profiles.active={profile}。然而，在微服務架構中，微服務的配置管理通常有如下需求：

集中管理配置。一個使用微服務架構的應用系統可能會包含成百上千個微服務，所以集中管理配置是很是有必要的。

不一樣環境，不一樣配置。例如，數據源配置在不一樣的環境（開發、測試、預發佈、生產等）中是不一樣的。

運行期間可動態調整。例如，可根據各個微服務的負載狀況，動態調整數據源鏈接池大小或熔斷閾值，而且在調整配置時不中止微服務。

配置修改後可自動更新。如配置內容發生變化，微服務可以自動更新配置。綜上所述，對於微服務架構而言，一個通用的配置管理機制是必不可少的，常見作法是使用配置服務器管理配置。spring cloud bus利用Git或SVN等管理配置、採用Kafka或者RabbitMQ等消息總線通知全部應用，從而實現配置的自動更新而且刷新全部微服務實例的配置。

Zipkin

Sleuth+ZipKin(跟蹤服務)：Sleuth和Zipkin結合使用能夠經過圖形化的界面查看微服務請求的延遲狀況以及各個微服務的依賴狀況。須要注意的是spring boot2及以上不在支持Zipkin的自定義，須要到官方網站下載ZipKin相關的jar包。

其它

另外須要提一點的是spring boot actuator，提供了不少監控端點如/actuator/info、/actuator/health、/acutator/refresh等，能夠查看微服務的信息、健康情況、刷新配置等。

最後

歡迎你們關注個人公種浩【程序員追風】，整理了2019年多家公司java面試題資料100多頁pdf文檔，文章都會在裏面更新，整理的資料也會放在裏面。