首先看一張springCloud的圖片:
二、簡單介紹下什么是springCloud?
“Spring Cloud為開發人員提供了快速構建分布式系統中一些常見模式的工具（例如配置管理，服務發現，斷路器，智能路由，微代理，控制總線）。分布式系統的協調導致了樣板模式, 使用Spring Cloud開發人員可以快速地支持實現這些模式的服務和應用程序。他們將在任何分布式環境中運行良好，包括開發人員自己的筆記本電腦，裸機數據中心，以及Cloud Foundry等托管平台。” -----來自官網
三、為了方便理解假設一個業務場景
假設現在開發一個電商網站,要實現支付訂單功能:流程如下–
1.創建一個訂單后,如果用戶立刻支付了這個訂單,我們需要將這個訂單狀態更新為(已經支付)
2.扣減相對應的商品庫存
3.通知倉儲中心,進行發貨
4.給用戶這次購物怎加相對應的積分
針對上述流程，我們需要有訂單服務、庫存服務、倉儲服務、積分服務，整個流程的大體思路如下：
- 用戶針對一個訂單完成支付后,就回去找訂單服務,更新訂單狀態
- 訂單服務調用庫存服務,完成相應的功能
- 訂單服務調用倉儲服務,完成相應的功能
- 訂單服務調用積分服務,完成相應的功能
整個過程可以如下圖所示:
四、SpringCloud核心組件Eureka（類似於zookeeper）
首先考慮一個問題，訂單服務要調用庫存服務、倉儲服務、積分服務，如何調用呢？
答：訂單服務根本不知道上述服務在哪台服務器上，所以沒法調用，而Eureka的作用就是來告訴訂單服務它想調用的服務在哪台服務器上，Eureka有客戶端和服務端，每一個服務上面都有Eureka客戶端，可以把本服務的相關信息注冊到Eureka服務端上，那么我們的訂單服務就可以就可以找到庫存服務、倉儲服務、積分服務了
我們上述的業務使用Eureka后如下圖：
總結：
Eurake客戶端：負責將這個服務的信息注冊到Eureka服務端中
Eureka服務端：相當於一個注冊中心，里面有注冊表，注冊表中保存了各個服務所在的機器和端口號，可以通過Eureka服務端找到各個服務
五、SpringCloud核心組件：Feign（類似於dubbo）
通過上面的Eureka，現在訂單服務確實知道庫存服務、積分服務、倉儲服務在哪了，但是我們如何去調用這些服務呢，如果我們自己去寫很多代碼調用那就太麻煩了，而SpringCloud已經為我們准備好了一個核心組件：Feign，接下來看如何通過Feign讓訂單服務調用庫存服務，注意Feign也是用在消費者端的；
訂單服務：
庫存服務：
沒有底層的建立連接、構造請求、解析響應的代碼，直接就是用注解定義一個 FeignClient接口，然后調用那個接口就可以了。人家Feign Client會在底層根據你的注解，跟你指定的服務建立連接、構造請求、發起靕求、獲取響應、解析響應，等等。這一系列臟活累活，人家Feign全給你干了。
問題來了,Feign是如何做到的呢?其實Feign的一個機制就是使用了動態代理：
- 首先，如果你對某個接口定義了@FeignClient注解，Feign就會針對這個接口創建一個動態代理
- 接着你要是調用那個接口，本質就是會調用 Feign創建的動態代理，這是核心中的核心
- Feign的動態代理會根據你在接口上的@RequestMapping等注解，來動態構造出你要請求的服務的地址
- 最后針對這個地址，發起請求、解析響應
六、springCloud核心組件:Ribbon
上面可以通過Eureka可以找到服務，然后通過Feign去調用服務，但是如果有多台機器上面都部署了庫存服務，我應該使用Feign去調用哪一台上面的服務呢，這個時候就需要Ribbon閃亮登場了，它在服務消費者端配置和使用，它的作用就是負載均衡，然后默認使用的負載均衡算法是輪詢算法，Ribbon會從Eureka服務端中獲取到對應的服務注冊表，然后就知道相應服務的位置，然后Ribbon根據設計的負載均衡算法去選擇一台機器，Feigin就會針對這些機器構造並發送請求，如下圖所示：
七、SpringCloud的核心組件：Hystrix
在微服務架構里，一個系統會有多個服務，以本文的業務場景為例：訂單服務在一個業務流程里需要調用三個服務，現在假設訂單服務自己最多只有100個線程可以處理請求，如果積分服務出錯，每次訂單服務調用積分服務的時候，都會卡住幾秒鍾，然后拋出—個超時異常。
分析下這樣會導致什么問題呢？如果系統在高並發的情況下，大量請求涌過來的時候，訂單服務的100個線程會卡在積分服務這塊，導致訂單服務沒有一個多余的線程可以處理請求，這種問題就是微服務架構中恐怖的服務器雪崩問題，這么多的服務互相調用要是不做任何保護的話,某一個服務掛掉會引起連鎖反應,導致別的服務掛掉，上述描述如下圖所示：
但是我們想一下，即使積分服務掛了，那訂單服務也不應該掛掉啊，我們只要讓存儲服務和倉儲服務正常工作就可以了，至於積分服務我們后期可以手動給用戶加上積分，這個時候就輪到Hystrix閃亮登場了，Hystrix是隔離、熔斷以及降級的一個框架，說白了就是Hystrix會搞很多小線程池然后讓這些小線程池去請求服務，返回結果，Hystrix相當於是個中間過濾區，如果我們的積分服務掛了，那我們請求積分服務直接就返回了，不需要等待超時時間結束拋出異常，這就是所謂的熔斷，但是也不能啥都不干就返回啊，不然我們之后手動加積分咋整啊，那我們每次調用積分服務就在數據庫里記錄一條消息，這就是所謂的降級，Hystrix隔離、熔斷和降級的全流程如下：
八、SpringCloud核心組件：zull（類似於服務器端的nginx）
該組件是負責網絡路由的，假設你后台部署了幾百個服務，現在有個前端兄弟，人家請求是直接從瀏覽器那兒發過來的。打個比方：人家要請求一下庫存服務，你難道還讓人家記着這服務的名字叫做inventory-service，並且部署在5台機器上，就算人家肯記住這一個，那你后台可有幾百個服務的名稱和地址呢？難不成人家請求一個，就得記住一個？哈哈哈
上面這種情況，壓根兒是不現實的。所以一般微服務架構中都必然會設計一個網關在里面，像android、ios、pc前端、微信小程序、H5等等，不用去關心后端有幾百個服務，就知道有一個網關，所有請求都往網關走，網關會根據請求中的一些特征，將請求轉發給后端的各個服務。
九、簡單總結
Eureka：
服務啟動的時候，服務上的Eureka客戶端會把自身注冊到Eureka服務端，並且可以通過Eureka服務端知道其他注冊的服務
Ribbon：
服務間發起請求的時候，服務消費者方基於Ribbon服務做到負載均衡，從服務提供者存儲的多台機器中選擇一台，如果一個服務只在一台機器上面，那就用不到Ribbon選擇機器了，如果有多台機器，那就需要使用Ribbon選擇之后再去使用
Feign：
Feign使用的時候會集成Ribbon，Ribbon去Eureka服務端中找到服務提供者的所在的服務器信息，然后根據隨機策略選擇一個，拼接Url地址后發起請求
Hystrix：
發起的請求是通過Hystrix的線程池去訪問服務，不同的服務通過不同的線程池，實現了不同的服務調度隔離，如果服務出現故障，通過服務熔斷，避免服務雪崩的問題 ，並且通過服務降級，保證可以手動實現服務正常功能
Zuul：
如果前端調用后台系統，統一走zull網關進入，通過zull網關轉發請求給對應的服務
圖片總結更清晰：
原文轉載於:https://blog.csdn.net/CoreyXuu/article/details/87865274