• 服務發現--Netflix Eureka

• 客戶端負載均衡--Netflix Ribbon

• 斷路器--Netflix Hystrix

• 服務閘道器--Netflix Zuul

• 分散式配置--Spring Cloud Config
  業務場景介紹：
  先來給大家說一個業務場景，假設咱們現在開發一個電商網站，要實現支付訂單的功能，流程如下：

• 建立一個訂單之後，如果使用者立刻支付了這個訂單，我們需要將訂單狀態更新為“已支付”

• 扣減相應的商品庫存

• 通知倉儲中心，進行發貨

• 給使用者的這次購物增加相應的積分

針對上述流程，我們需要有訂單服務、庫存服務、倉儲服務、積分服務。整個流程的大體思路如下：

• 使用者針對一個訂單完成支付之後，就會去找訂單服務，更新訂單狀態

• 訂單服務呼叫庫存服務，完成相應功能

• 訂單服務呼叫倉儲服務，完成相應功能

• 訂單服務呼叫積分服務，完成相應功能

至此，整個支付訂單的業務流程結束

1. 核心元件Eureke（服務發現）：
   是微服務架構中的註冊中心，由Eureka Client和Eureka Server兩部分組成，前者負責將各個服務的資訊註冊到Eureka Server中。後者為註冊中心，裡面有一個登錄檔，儲存了各個服務所在的機器和埠號；

2. 核心元件Feign(動態代理)：
   使用了動態代理的機制，用註解定義一個FeignClient介面，向指定的服務建立連線、發起請求、獲取響應，解析響應等等。
   Feign的動態代理機制：

• 首先，對某個介面定義了@FeignClient註解，Feign就會針對這個介面建立一個動態代理
• 接著你要是呼叫這個介面，本質就會呼叫Feign建立的動態代理，這是核心中的核心；
• Feign的動態代理會根據你介面上的@RequestMapping等註解，來動態構造出你要請求的服務地址；
• 最後針對這個地址，發起請求，解析響應；

3. 核心元件Ribbon（客戶端負載均衡）：

• Ribbon的作用是負載均衡，當我們要請求的服務部署在多臺機器上時，Feign就不知道該請求哪臺機器。此時具有負載均衡作用的Ribbon就會幫你在每次請求時選擇一臺機器，均勻的把請求分發到各臺機器上。
• Ribbon的負載均衡使用的是最經典的Round Robin輪詢演算法。簡單說就是對多臺機器進行輪流請求，然迴圈；
• 此外Ribbon是和Feign以及Eureka緊密協作的，具體如下：
• 首先Ribbon會從Eureka Client裡獲取到對應的服務登錄檔，知道所有的服務都部署在了哪些機器上，在監聽哪些埠號。
• 然後Ribbon就使用預設的Round Robin輪詢演算法，從中選擇一臺機器；
• 最後Feign就會針對這臺機器，構造併發起請求。

4. 核心元件Hystrix（斷路器）
   業務背景：

• 假設一個業務場景：訂單服務在一個業務流程裡需要呼叫三個服務。現在假設訂單服務自己最多隻有100個執行緒可以處理請求，然後呢，積分服務不幸的掛了，每次訂單服務呼叫積分服務的時候，都會卡住幾秒鐘，然後丟擲—個超時異常。這也是雪崩問題的雛形所在；
• 在上面的業務場景下，如果系統處於高併發狀態，大量的請求湧過來的時候。訂單服務的100個執行緒都會卡在請求積分服務這塊兒。導致訂單服務沒有一個執行緒可以處理請求。然後就會導致別人請求訂單服務的時候，發現訂單服務也掛了，不響應任何請求了————這個，就是微服務架構中恐怖的服務雪崩問題。
  這邊插入一個思考：就算積分服務掛了，訂單服務也可以不掛啊？為什麼？
  (1). 結合業務來看：支付訂單的時候，只要把庫存扣減了，然後通知倉庫發貨就OK了。
  (2). 如過積分服務掛了，大不了等他回覆之後，慢慢人肉手工恢復資料！為啥一定要因為一個積分服務掛了，就直接導致訂單服務也掛了呢？

分析了這麼多，就是為了引出我們的Hystrix

• Hystrix是隔離、熔斷以及降級的一個框架。Hystrix會為每個服務搞一個小小的執行緒池。
  下面來說說，當有Hystrix參與時，積分服務掛了會是啥樣的：
• 因為上面說了，Hystrix會為各個服務搞一個執行緒池，當積分服務掛了時，訂單服務那裡用來呼叫積分服務的執行緒會都卡死不能工作。但是，訂單服務呼叫庫存服務和倉儲服務的這兩個執行緒池都能正常工作，所以這兩個服務不會受到任何影響。
• 熔斷————這個時候如果別人呼叫訂單服務，訂單服務還可以正常呼叫庫存服務扣減庫存，呼叫倉儲服務通知發貨。當呼叫積分服務時每次都會報錯。但是既然積分服務掛了，每次呼叫都會卡幾秒，這樣顯然是沒有意義的。這裡就要用到所謂的熔斷：比如在五分鐘內請求積分服務直接就返回了，不要走網路請求卡住幾秒鐘。
• 降級————上面說了，積分服務掛了我們就熔斷然後直接返回，這顯然不是最好的解決方法。這個時候就要用到降級處理：每次呼叫積分服務時，就在資料庫裡記錄一條訊息，說給某某使用者增加了多少積分，因為積分服務掛了，導致沒增加成功！這樣等積分服務恢復了，就可以根據這些記錄手工加一下積分。這就是所謂的降級處理。
  小結：針對微服務框架的服務雪崩問題，我們會用到Hystrix元件，然後進行隔離、熔斷、降級處理。

5. 核心元件Zuul（服務閘道器）

• Zuul就是微服務閘道器。這個元件是負責網路路由。
• 如果不懂網路路由，那我們來看看，沒有Zuul的工作會是怎麼樣的：
  假設你後臺部署了幾百個服務，現在有個前端兄弟，人家請求是直接從瀏覽器那兒發過來的。比如：人家要請求一下庫存服務，你難道要讓人家記住這個服務的名字叫什麼什麼？部署在幾臺機器上？但是後臺可能有幾百個服務的名稱和地址，這顯然不能靠記；
• 上面這種情況壓根兒是行不通的。所以一般微服務架構中都必然會設計一個閘道器在裡面，像Android、iOS、PC前端、微信小程式、H5等等，不用去關心後端有幾百個服務，就知道有一個閘道器，所有的請求都走閘道器，閘道器會根據請求中的一些特徵，將請求轉發給後端各個服務；而且有了閘道器之後還可以做統一的降級、限流、認證授權、安全，等等；
  總結：
• Eureka：各個服務啟動時，Eureka Client都會將服務註冊到Eureka Server，並且Eureka Client還可以反過來從Eureka Server拉去登錄檔，從而知道其他服務在哪裡；
  （在spring cloud中，除了可以使用eureka作為註冊中心外，還可以使用zookeeper、Consul作為註冊中心。）
• Ribbon：服務間發起請求的時候，基於Ribbon做負載均衡，從一個服務的多臺機器中選擇一臺；
• Feign：基於Feign的動態代理機制，根據註解和選擇的機器，拼接請求的URL地址，發起請求；
• Hystrix：發起請求是通過Hystrix的執行緒池來走的，不同的服務走不同的執行緒池，實現了不同服務呼叫的隔離，避免了服務雪崩的問題；
  （Sentinel可以很好的替代Hystrix）
• Zuul：如果前端、移動端要呼叫後端系統，統一從Zuul閘道器進入，由Zuul閘道器轉發請求給對應的服務；
  （Gateway可以很好的替代Zuul）
  下面通過一張圖來將Spring Cloud五元件聯絡起來，直觀瞭解其底層的架構原理：
  
  （網路資源）

• 服務發現--Netflix Eureka

• 客戶端負載均衡--Netflix Ribbon

• 斷路器--Netflix Hystrix

• 服務閘道器--Netflix Zuul

• 分散式配置--Spring Cloud Config
  業務場景介紹：
  先來給大家說一個業務場景，假設咱們現在開發一個電商網站，要實現支付訂單的功能，流程如下：

• 建立一個訂單之後，如果使用者立刻支付了這個訂單，我們需要將訂單狀態更新為“已支付”

• 扣減相應的商品庫存

• 通知倉儲中心，進行發貨

• 給使用者的這次購物增加相應的積分

針對上述流程，我們需要有訂單服務、庫存服務、倉儲服務、積分服務。整個流程的大體思路如下：

• 使用者針對一個訂單完成支付之後，就會去找訂單服務，更新訂單狀態

• 訂單服務呼叫庫存服務，完成相應功能

• 訂單服務呼叫倉儲服務，完成相應功能

• 訂單服務呼叫積分服務，完成相應功能

至此，整個支付訂單的業務流程結束

1. 核心元件Eureke（服務發現）：
   是微服務架構中的註冊中心，由Eureka Client和Eureka Server兩部分組成，前者負責將各個服務的資訊註冊到Eureka Server中。後者為註冊中心，裡面有一個登錄檔，儲存了各個服務所在的機器和埠號；

2. 核心元件Feign(動態代理)：
   使用了動態代理的機制，用註解定義一個FeignClient介面，向指定的服務建立連線、發起請求、獲取響應，解析響應等等。
   Feign的動態代理機制：

• 首先，對某個介面定義了@FeignClient註解，Feign就會針對這個介面建立一個動態代理
• 接著你要是呼叫這個介面，本質就會呼叫Feign建立的動態代理，這是核心中的核心；
• Feign的動態代理會根據你介面上的@RequestMapping等註解，來動態構造出你要請求的服務地址；
• 最後針對這個地址，發起請求，解析響應；

3. 核心元件Ribbon（客戶端負載均衡）：

• Ribbon的作用是負載均衡，當我們要請求的服務部署在多臺機器上時，Feign就不知道該請求哪臺機器。此時具有負載均衡作用的Ribbon就會幫你在每次請求時選擇一臺機器，均勻的把請求分發到各臺機器上。
• Ribbon的負載均衡使用的是最經典的Round Robin輪詢演算法。簡單說就是對多臺機器進行輪流請求，然迴圈；
• 此外Ribbon是和Feign以及Eureka緊密協作的，具體如下：
• 首先Ribbon會從Eureka Client裡獲取到對應的服務登錄檔，知道所有的服務都部署在了哪些機器上，在監聽哪些埠號。
• 然後Ribbon就使用預設的Round Robin輪詢演算法，從中選擇一臺機器；
• 最後Feign就會針對這臺機器，構造併發起請求。

4. 核心元件Hystrix（斷路器）
   業務背景：

• 假設一個業務場景：訂單服務在一個業務流程裡需要呼叫三個服務。現在假設訂單服務自己最多隻有100個執行緒可以處理請求，然後呢，積分服務不幸的掛了，每次訂單服務呼叫積分服務的時候，都會卡住幾秒鐘，然後丟擲—個超時異常。這也是雪崩問題的雛形所在；
• 在上面的業務場景下，如果系統處於高併發狀態，大量的請求湧過來的時候。訂單服務的100個執行緒都會卡在請求積分服務這塊兒。導致訂單服務沒有一個執行緒可以處理請求。然後就會導致別人請求訂單服務的時候，發現訂單服務也掛了，不響應任何請求了————這個，就是微服務架構中恐怖的服務雪崩問題。
  這邊插入一個思考：就算積分服務掛了，訂單服務也可以不掛啊？為什麼？
  (1). 結合業務來看：支付訂單的時候，只要把庫存扣減了，然後通知倉庫發貨就OK了。
  (2). 如過積分服務掛了，大不了等他回覆之後，慢慢人肉手工恢復資料！為啥一定要因為一個積分服務掛了，就直接導致訂單服務也掛了呢？

分析了這麼多，就是為了引出我們的Hystrix

• Hystrix是隔離、熔斷以及降級的一個框架。Hystrix會為每個服務搞一個小小的執行緒池。
  下面來說說，當有Hystrix參與時，積分服務掛了會是啥樣的：
• 因為上面說了，Hystrix會為各個服務搞一個執行緒池，當積分服務掛了時，訂單服務那裡用來呼叫積分服務的執行緒會都卡死不能工作。但是，訂單服務呼叫庫存服務和倉儲服務的這兩個執行緒池都能正常工作，所以這兩個服務不會受到任何影響。
• 熔斷————這個時候如果別人呼叫訂單服務，訂單服務還可以正常呼叫庫存服務扣減庫存，呼叫倉儲服務通知發貨。當呼叫積分服務時每次都會報錯。但是既然積分服務掛了，每次呼叫都會卡幾秒，這樣顯然是沒有意義的。這裡就要用到所謂的熔斷：比如在五分鐘內請求積分服務直接就返回了，不要走網路請求卡住幾秒鐘。
• 降級————上面說了，積分服務掛了我們就熔斷然後直接返回，這顯然不是最好的解決方法。這個時候就要用到降級處理：每次呼叫積分服務時，就在資料庫裡記錄一條訊息，說給某某使用者增加了多少積分，因為積分服務掛了，導致沒增加成功！這樣等積分服務恢復了，就可以根據這些記錄手工加一下積分。這就是所謂的降級處理。
  小結：針對微服務框架的服務雪崩問題，我們會用到Hystrix元件，然後進行隔離、熔斷、降級處理。

5. 核心元件Zuul（服務閘道器）

• Zuul就是微服務閘道器。這個元件是負責網路路由。
• 如果不懂網路路由，那我們來看看，沒有Zuul的工作會是怎麼樣的：
  假設你後臺部署了幾百個服務，現在有個前端兄弟，人家請求是直接從瀏覽器那兒發過來的。比如：人家要請求一下庫存服務，你難道要讓人家記住這個服務的名字叫什麼什麼？部署在幾臺機器上？但是後臺可能有幾百個服務的名稱和地址，這顯然不能靠記；
• 上面這種情況壓根兒是行不通的。所以一般微服務架構中都必然會設計一個閘道器在裡面，像Android、iOS、PC前端、微信小程式、H5等等，不用去關心後端有幾百個服務，就知道有一個閘道器，所有的請求都走閘道器，閘道器會根據請求中的一些特徵，將請求轉發給後端各個服務；而且有了閘道器之後還可以做統一的降級、限流、認證授權、安全，等等；
  總結：
• Eureka：各個服務啟動時，Eureka Client都會將服務註冊到Eureka Server，並且Eureka Client還可以反過來從Eureka Server拉去登錄檔，從而知道其他服務在哪裡；
  （在spring cloud中，除了可以使用eureka作為註冊中心外，還可以使用zookeeper、Consul作為註冊中心。）
• Ribbon：服務間發起請求的時候，基於Ribbon做負載均衡，從一個服務的多臺機器中選擇一臺；
• Feign：基於Feign的動態代理機制，根據註解和選擇的機器，拼接請求的URL地址，發起請求；
• Hystrix：發起請求是通過Hystrix的執行緒池來走的，不同的服務走不同的執行緒池，實現了不同服務呼叫的隔離，避免了服務雪崩的問題；
  （Sentinel可以很好的替代Hystrix）
• Zuul：如果前端、移動端要呼叫後端系統，統一從Zuul閘道器進入，由Zuul閘道器轉發請求給對應的服務；
  （Gateway可以很好的替代Zuul）
  下面通過一張圖來將Spring Cloud五元件聯絡起來，直觀瞭解其底層的架構原理：
  
  （網路資源）