SpringCloud元件詳解（對於基礎的一些面試也是有用的）

這篇部落格也是因為一個朋友參加面試，回來後說今天面試官上來就問了微服務，為了鞏固自己，也為了方便一下廣大技術愛好者，我這裡根據面試官向他提問的問題，對微服務做了一個簡單的總結。
由於本人也是菜鳥一枚，有些知識點也是看了網上的一些資料，並沒有進行實際操作，所以整個文章中我就省略了程式碼和配置檔案。如果有什麼不對的地方，歡迎留言，不吝賜教。下面上正文吧。

SpringCloud元件介紹

這個元件我百度了一下，我看網上有些不一樣的，我這裡就不管那麼多了。有問題歡迎各位大牛留言，謝謝。外附一個連結
連結: link.

先介紹一下什麼是SpringCloud的吧：SpringCloud通俗易懂的理解方式，就是一系列框架的集合，內部整合了很多元件。核心元件主要有：

Eureka（註冊中心）

一個服務註冊與發現的元件。Eureka的體系主要包括服務的提供者，服務的消費者，服務註冊中心。服務的提供者和消費者都是Eureka的客戶端，服務註冊中心作為Eureka的服務端。我們在使用Eureka的時候，通過配置檔案的方式，將我們的API介面註冊到Eureka的註冊中心上，我們的服務的消費者可以向Eureka註冊中心拉取服務列表，然後根據獲取的服務列表選擇一個服務的提供者進行消費服務。

聽起來可能有人會覺得這跟Zookeeper差不多，Dubbo就是以Zookeeper作為註冊中心的。但是這兩者還是有區別的，（要不豈不是沒有Eureka什麼事了）：

Dubbo只是實現了服務治理，而SpringCloud的子專案分別覆蓋了微服務架構的很多元件。

Dubbo的效率略高於SpringCloud。因為Dubbo底層使用了RPC通訊協議，而SpringCloud使用的RESTful完成的通訊協議。大型的微服務架構專案，還是推薦使用SpringCloud。

Eureka可以通過搭建叢集實現Eureka的高可用，防止Eureka掛掉，導致Eureka的不可用。這我們需要注意搭叢集的時候，要保證每個Eureka服務註冊中心之間要實現相互註冊，防止資料的不一致或者資料丟失。這裡主要是通過配置檔案的方式進行實現，不過多解釋，可以查詢其他資料。

如何從EurekaServer中動態的獲取服務提供方的IP和端

1.注入DiscoveryClient物件,啟用
2.呼叫getInstances()方法

最後提一下Eureka的自我保護機制

Eureka的自我保護機制

Eureka的自我保護機制：Eureka客戶端會定時的向 Eureka服務端傳送心跳包，預設是30S傳送一次，目的是告訴 Eureka服務端當前客戶端例項還處於存活狀態，如果Eureka服務端在一定時間內沒有收到例項的心跳，便會把該例項從登錄檔中刪除（預設是90S）,但是，如果短時間內丟失大量的例項心跳，便會觸發Eureka服務端的自我保護機制的 ,預設自我保護機制處於開啟狀態。
這裡不多解釋了，參考這條連結
連結: link.
感謝link.

Ribbon（負載均衡）

一個基於HTTP和TCP的負載均衡工具，可以簡化我們的遠端呼叫。這裡有必要提一下負載均衡：
服務端的負載均衡：負載均衡演算法在服務端，由負載均衡器維護服務地址列表。在某些情況下，比如我們要搭叢集，實現伺服器端的高可用。我們需要配置多臺伺服器，每個伺服器都有不同的服務請求地址。當我們的客戶端向服務端傳送請求的時候，不會直接去訪問我們的伺服器，會先經過一個負載均衡器，內部通過負載均衡演算法，幫我們去訪問不同的伺服器。這主要是服務端的負載均衡。

還有客戶端負載均衡：我們的服務的消費者通過Eureka訪問我們的服務生產者（這裡我們配置了多個生產者，實現了高可用的叢集環境），然後我們的服務消費者通過Eureka將服務的提供者的路徑地址儲存在服務消費者內部，然後通過服務消費者自己寫的負載均衡演算法選擇不同的節點，和服務的提供者建立連線。

這裡我們提一下負載均衡的策略：隨機，輪詢（這也是Ribbon預設使用的負載均衡策略），最小併發，過濾，輪詢重試，效能可用性等。而我們的Ribbon也可以通過配置檔案的方式設定負載均衡策略。

這裡由於是配置檔案的方式，不過多闡述，有興趣的可以去查閱資料瞭解一下。以下文章涉及編碼和配置的全部省略。

那麼Ribbon是怎麼簡化遠端呼叫的呢？

這裡我就只做簡述，涉及的程式碼後期有時間再補上

1.我們在宣告RestTemplate的時候，新增一個@LoadBalanced註解。
2.在使用RestTemplate傳送請求，定義url時，host:port可以替換為服務提供者的應用名稱。

這裡就不過多闡述了，大家有時間可以去看其他的資料。

Feign

一個宣告式的REST客戶端，使用了基於註解的方式，方便了我們客戶端的配置。簡單總結一句話：Feign 的出現使得Eureka和Ribbon的使用更為簡單，同時支援SpringMVC註解。引入feign依賴，編寫Feign呼叫介面，啟動類新增@EnableFeignClients註解，開啟Feign功能。這裡具體的配置和程式碼不做講解了，後期有時間我會單獨寫一篇部落格補上來。

Hystrix（熔斷器）

這裡先提一下服務雪崩：

服務雪崩

服務雪崩： 在分散式系統或者微服務的架構下，各個系統之間的關係錯綜複雜，相互依賴。如果一個服務出現問題，可能會導致整個系統出錯，會造成一種雪崩的情況。所謂的雪崩就是一個服務失敗了，導致整條鏈路的服務都失敗的情形。這個時候，可以使用Hystrix（熔斷器）隔離遠端服務。

Hystrix（熔斷器）就是一個延遲容錯庫，用於隔離遠端服務、第三方庫，防止出現級聯失敗（雪崩）。

服務隔離：
執行緒池隔離：我們將執行緒池中的執行緒分別進行隔離，拆分成多個小的執行緒池，每個執行緒池中有若干執行緒。當一個服務掛掉以後，只會導致當前服務相對應的執行緒池中無可用執行緒。不會影響其他的服務。

訊號量隔離：限制我們的訪問量，訪問次數。

服務降級：
在進行程式開發的時候，我們要預判到我們的程式失敗的情況並進行處理。當程式服務出現失敗的情況後，我們採用我們的降級方案，遮蔽一下錯誤情況，進行一些友好提示。不管是服務的提供方還是消費方我們都需要進行降級方案的處理。防止消費方在對服務提供方呼叫之前就出現錯誤情況。

服務熔斷：
可以監控我們微服務的呼叫情況，當失敗的次數達到某個閾值的時候，會自動開啟斷路器，拒絕所有的請求，直到恢復正常。

這裡簡單提一下斷路器：斷路器有三種狀態：關閉，開啟，半開。預設是關閉的，當我們請求失敗次數達到閾值的時候，斷路器會自動開啟，拒絕所有的請求，開啟5秒以後，會切換為半開狀態，判斷請求是否正確。確定是否關閉斷路器。

服務限流
技術不夠，部落格來湊
連結：link.

zull（微服務閘道器）

連結：link.
感謝link.
Spring Cloud Zuul通過與Spring Cloud Eureka進行整合，將自身註冊為Eureka服務治理下的應用，同時從Eureka中獲得了所有其他微服務的例項資訊。對於路由規則的維護，Zuul預設會將通過以服務名作為ContextPath的方式來建立路由對映。Zuul提供了一套過濾器機制，可以支援在API閘道器無附上進行統一呼叫來對微服務介面做前置過濾，已實現對微服務介面的攔截和校驗。

Spring Cloud Config

這個就不說了，直接看這個連結吧，我也不是特別的懂
連結：link.

Gateway（閘道器）

​ 通過閘道器去配置後臺微服務的地址，使用者直接跟閘道器打交道，將請求傳送給閘道器，閘道器再將請求傳送給對應的微服務。旨在為微服務架構提供一種簡單而有效的統一的API路由管理方式。

​ 閘道器就是一個系統的入口，封裝了程式的內部結構。一些認證、監控、許可權驗證、快取等公共的邏輯可以在閘道器中實現。

Gateway的靜態路由： 通過Gateway進行請求轉發的時候，我們配置檔案中的uri地址是寫死的。

Gateway的動態路由（Gateway怎麼實現動態路由）：

當我們的一個微服務的uri發生變化的時候，閘道器的配置就要進行更改，顯然很不方便。所以我們需要配置動態路由。我們的微服務的IP埠會註冊到Eureak，閘道器可以直接從Eureak中拉取就可以了，這裡我們只需要讓閘道器成為Eureak的一個客戶端就行了。
將我們配置檔案中的uri改為：

uri:lb://Eureak中註冊的服務名稱

Gateway（閘道器）過濾器

Gateway中可以定義多個過濾器，形成一種過濾器鏈，對我們的請求和相應進行攔截，然後完成一些通用的操作。

兩種過濾器方式：pre 和 post

pre：在轉發之前執行

post：在轉發之後執行

兩種型別的過濾器：

GatewayFilter（區域性過濾器，針對的單個路由）：在配置檔案中進行配置生效。

GlobalFilter（全域性過濾器，針對所有路由）：不需要進行配置，系統初始化時載入。

如有不妥之處，希望各位技術大牛多多指教，及時留言，個人不吝賜教。
如有不妥之處，希望各位技術大牛多多指教，及時留言，個人不吝賜教。
如有不妥之處，希望各位技術大牛多多指教，及時留言，個人不吝賜教。