轉載地址：https://blog.csdn.net/qiuyinthree/article/details/80408751

微服務的理解：  就是把一個專案拆分為多個專案， 專案之間進行獨立執行。 通過Http或者Socket來進行通訊處理資料和呼叫。

Spring  Cloud  Eureka（服務治理）: 

       服務治理： 服務治理是微服務架構中最為核心和基礎的模組，它主要用來實現各個微服務例項的自動化註冊和發現。

       服務註冊：

      服務發現： 在服務治理框架下，服務間的呼叫不再通過指定具體的例項地址來實現，而是通過服務名發起請求呼叫實現。服務呼叫方通過服務名從服務註冊中心的服務清單中獲取服務例項的列表清單，通過指定的負載均衡策略取出一個服務例項位置來進行服務呼叫。

     Eureka服務端：Eureka服務端，即服務註冊中心。它同其他服務註冊中心一樣，支援高可用配置。依託於強一致性提供良好的服務例項可用性，可以應對多種不同的故障場景。Eureka服務端支援叢集模式部署，當叢集中有分片發生故障的時候，Eureka會自動轉入自我保護模式。它允許在分片發生故障的時候繼續提供服務的發現和註冊，當故障分配恢復時，叢集中的其他分片會把他們的狀態再次同步回來。叢集中的的不同服務註冊中心通過非同步模式互相複製各自的狀態，這也意味著在給定的時間點每個例項關於所有服務的狀態可能存在不一致的現象。

詳細介紹地址： https://blog.csdn.net/sunhuiliang85/article/details/76222517 

Spring  Cloud  Ribbon（客戶端負載均衡）:

      Spring Cloud Ribbon 是一個基於Http和TCP的客服端負載均衡工具，它是基於Netflix Ribbon實現的。它不像服務註冊中心、配置中心、API閘道器那樣獨立部署，但是它幾乎存在於每個微服務的基礎設施中。包括前面的提供的宣告式服務呼叫也是基於該Ribbon實現的。理解Ribbon對於我們使用Spring Cloud來講非常的重要，因為負載均衡是對系統的高可用、網路壓力的緩解和處理能力擴容的重要手段之一。

     使用springcloud ribbon實現與eureka的配合

 ribbon可從eureka服務登錄檔中獲取服務提供者的地址列表，使用一定的負載均衡演算法，Ribbon的工作主要分為2步。

1.先選擇eureka service ，優先選擇一個zone負載較小的service。

2.根據使用者制定策，從service取得eureka 服務登錄檔中選擇一個地址。

提供的策略：輪詢Round Robin、隨機Random、ResponseTime加權

Spring Cloud Hystrix（服務容錯保護）:

    在微服務架構中通常會有多個服務層呼叫，基礎服務的故障可能會導致級聯故障，進而造成整個系統不可用的情況，這種現象被稱為服務雪崩效應。服務雪崩效應是一種因“服務提供者”的不可用導致“服務消費者”的不可用,並將不可用逐漸放大的過程。

    熔斷器的原理很簡單，如同電力過載保護器。它可以實現快速失敗，如果它在一段時間內偵測到許多類似的錯誤，會強迫其以後的多個呼叫快速失敗，不再訪問遠端伺服器，從而防止應用程式不斷地嘗試執行可能會失敗的操作，使得應用程式繼續執行而不用等待修正錯誤，或者浪費CPU時間去等到長時間的超時產生。熔斷器也可以使應用程式能夠診斷錯誤是否已經修正，如果已經修正，應用程式會再次嘗試呼叫操作。

熔斷器模式就像是那些容易導致錯誤的操作的一種代理。這種代理能夠記錄最近呼叫發生錯誤的次數，然後決定使用允許操作繼續，或者立即返回錯誤。

  斷路器很好理解, 當Hystrix Command請求後端服務失敗數量超過一定比例(預設50%), 斷路器會切換到開路狀態(Open). 這時所有請求會直接失敗而不會發送到後端服務. 斷路器保持在開路狀態一段時間後(預設5秒), 自動切換到半開路狀態(HALF-OPEN). 這時會判斷下一次請求的返回情況, 如果請求成功, 斷路器切回閉路狀態(CLOSED), 否則重新切換到開路狀態(OPEN). Hystrix的斷路器就像我們家庭電路中的保險絲, 一旦後端服務不可用, 斷路器會直接切斷請求鏈, 避免傳送大量無效請求影響系統吞吐量, 並且斷路器有自我檢測並恢復的能力.

   詳細介紹地址： https://www.cnblogs.com/ityouknow/p/6868833.html

Spring  Cloud  Feign（宣告式服務呼叫）:

      Feign是一種宣告式、模板化的HTTP客戶端。在Spring Cloud中使用Feign, 我們可以做到使用HTTP請求遠端服務時能與呼叫本地方法一樣的編碼體驗，開發者完全感知不到這      是遠端方法，更感知不到這是個HTTP請求

       詳細介紹地址：https://blog.csdn.net/neosmith/article/details/52449921

Spring Cloud   Zuul（API閘道器服務）:   過濾:安全、監控、限流、路由

基於Spring的微服務結點在能力上沒有高低貴賤之分，但是在角色上會分為邊緣服務和內部服務兩部分。內部服務顧名思義是為對內暴露服務的結點，供架構內部來呼叫；邊緣服務是對外部網路暴露的服務結點，也就是對外API介面。

開發人員頭疼的地方：為了防止我的程式在網路上被人攻擊，我們需要寫各種許可權機制，這些機制在每個微服務結點都要實現一次。一旦鑑權上有什麼bug，又要全部節點上推倒重來，噩夢。

運維人員頭疼的地方：邊緣服務前段都會架一個F5或者Nginx等負載均衡的代理，需要手動維護一份服務列表和服務地址的路由資訊，隨著結點的擴充套件或地址調整這份列表要變來變去。

為了解決鑑權重複的問題，使業務結點本身只關心實現自己的業務，將對許可權的處理抽離到上層。外部客戶先請求到Zuul上，在Zuul服務上對許可權進行統一實現和過濾，以實現微服務結點的過濾和驗證。

為了解決請求路由和安全過濾，Spring Cloud推出了一個API gateway元件：Spring Cloud Zuul。

在路由方面，Zuul將自己作為一個微服務結點註冊到Eureka上，就獲取了所有微服務的例項資訊，同時又以服務名為ContextPath的方式建立路由對映。

詳細介紹： https://blog.csdn.net/yejingtao703/article/details/77816555/

Spring Cloud   Config（分散式配置中心）:

       在分散式系統中，每一個功能模組都能拆分成一個獨立的服務，一次請求的完成，可能會呼叫很多個服務協調來完成，為了方便服務配置檔案統一管理，更易於部署、維護，所以就需要分散式配置中心元件了，在spring cloud中，有分散式配置中心元件spring cloud config，它支援配置檔案放在在配置服務的記憶體中，也支援放在遠端Git倉庫裡。引入spring cloud config後，我們的外部配置檔案就可以集中放置在一個git倉庫裡，再新建一個config server，用來管理所有的配置檔案，維護的時候需要更改配置時，只需要在本地更改後，推送到遠端倉庫，所有的服務例項都可以通過config server來獲取配置檔案，這時每個服務例項就相當於配置服務的客戶端config client,為了保證系統的穩定，配置服務端config server可以進行叢集部署，即使某一個例項，因為某種原因不能提供服務，也還有其他的例項保證服務的繼續進行。

詳細介紹： https://blog.csdn.net/fox9916/article/details/79499854/

Spring Cloud    Bus（訊息匯流排）:

Spring Cloud Bus 將分散式的節點用輕量的訊息代理連線起來。它可以用於廣播配置檔案的更改或者服務之間的通訊，也可以用於監控。

訊息匯流排是一種通訊工具，可以在機器之間互相傳輸訊息、檔案等。訊息匯流排扮演著一種訊息路由的角色，擁有一套完備的路由機制來決定訊息傳輸方向。傳送段只需要向訊息匯流排發出訊息而不用管訊息被如何轉發。Spring cloud bus 通過輕量訊息代理連線各個分佈的節點。管理和傳播所有分散式專案中的訊息，本質是利用了MQ的廣播機制在分散式的系統中傳播訊息，目前常用的有Kafka和RabbitMQ。

        1、提交程式碼觸發post請求給bus/refresh
        2、server端接收到請求併發送給Spring Cloud Bus
        3、Spring Cloud bus接到訊息並通知給其它客戶端
        4、其它客戶端接收到通知，請求Server端獲取最新配置
        5、全部客戶端均獲取到最新的配置
  詳細介紹： https://blog.csdn.net/jack281706/article/details/73742522

Spring Cloud    Stream（訊息驅動微服務）:

訊息驅動理解： Windows訊息是，當一個窗體或者控制元件需要讓另外一個窗體或者訊息執行某個動作，就向那個窗體發一個訊息，放到對方的訊息佇列中，然後對方有一個訊息迴圈不停的讀取訊息佇列，並執行相應的動作。

簡單的講就是一種生產者，消費者模式。釋出者是生產，將輸出釋出到資料中心，訂閱者是消費者，訂閱自己感興趣的資料。當有資料到達資料中心時，就把資料傳送給對應的訂閱者。

訊息中介軟體簡介：   詳細介紹：https://www.cnblogs.com/bluestorm/p/6633492.html

Spring Cloud    Sleuth（分散式服務跟蹤）:

在微服務框架中，一個由客戶端發起的請求在後端系統中會經過多個不同的的服務節點呼叫來協同產生最後的請求結果，每一個前段請求都會形成一條複雜的分散式服務呼叫鏈路，鏈路中的任何一環出現高延時或錯誤都會引起整個請求最後的失敗。

Spring Cloud Sleuth提供了一套完整的服務跟蹤的解決方案。

Spring  Cloud  Shiro（安全許可權控制）:    

這個是進入系統了， 然後進行處理。 Zuul這個是路由器的管理，在系統未進入之前管理。 

什麼是反向代理？