先講五大核心組件，（偷個懶，嘻嘻）這裏我引用一位大佬講解的，原文地址是：https://juejin.im/post/5be13b83f265da6116393fc7
一、業務場景介紹
先來給大家說一個業務場景，假設咱們現在開發一個電商網站，要實現支付訂單的功能，流程如下：
- 創建一個訂單後，如果用戶立刻支付了這個訂單，我們需要將訂單狀態更新爲“已支付”
- 扣減相應的商品庫存
- 通知倉儲中心，進行發貨
- 給用戶的這次購物增加相應的積分
針對上述流程，我們需要有訂單服務、庫存服務、倉儲服務、積分服務。整個流程的大體思路如下：
- 用戶針對一個訂單完成支付之後，就會去找訂單服務，更新訂單狀態
- 訂單服務調用庫存服務，完成相應功能
- 訂單服務調用倉儲服務，完成相應功能
- 訂單服務調用積分服務，完成相應功能
至此，整個支付訂單的業務流程結束
下圖這張圖，清晰表明了各服務間的調用過程：
好！有了業務場景之後，咱們就一起來看看Spring Cloud微服務架構中，這幾個組件如何相互協作，各自發揮的作用以及其背後的原理。
二、Spring Cloud核心組件：Eureka
咱們來考慮第一個問題：訂單服務想要調用庫存服務、倉儲服務，或者積分服務，怎麼調用？
- 訂單服務壓根兒就不知道人家庫存服務在哪臺機器上啊！他就算想要發起一個請求，都不知道發送給誰，有心無力！
- 這時候，就輪到Spring Cloud Eureka出場了。Eureka是微服務架構中的註冊中心，專門負責服務的註冊與發現。
咱們來看看下面的這張圖，結合圖來仔細剖析一下整個流程：
如上圖所示，庫存服務、倉儲服務、積分服務中都有一個Eureka Client組件，這個組件專門負責將這個服務的信息註冊到Eureka Server中。說白了，就是告訴Eureka Server，自己在哪臺機器上，監聽着哪個端口。而Eureka Server是一個註冊中心，裏面有一個註冊表，保存了各服務所在的機器和端口號
訂單服務裏也有一個Eureka Client組件，這個Eureka Client組件會找Eureka Server問一下：庫存服務在哪臺機器啊？監聽着哪個端口啊？倉儲服務呢？積分服務呢？然後就可以把這些相關信息從Eureka Server的註冊表中拉取到自己本地緩存起來。
這時如果訂單服務想要調用庫存服務，不就可以找自己本地的Eureka Client問一下庫存服務在哪臺機器？監聽哪個端口嗎？收到響應後，緊接着就可以發送一個請求過去，調用庫存服務扣減庫存的那個接口！同理，如果訂單服務要調用倉儲服務、積分服務，也是如法炮製。
總結一下：
- Eureka Client：負責將這個服務的信息註冊到Eureka Server中
- Eureka Server：註冊中心，裏面有一個註冊表，保存了各個服務所在的機器和端口號
三、Spring Cloud核心組件：Feign
現在訂單服務確實知道庫存服務、積分服務、倉庫服務在哪裏了，同時也監聽着哪些端口號了。但是新問題又來了：難道訂單服務要自己寫一大堆代碼，跟其他服務建立網絡連接，然後構造一個複雜的請求，接着發送請求過去，最後對返回的響應結果再寫一大堆代碼來處理嗎？
這是上述流程翻譯的代碼片段，咱們一起來看看，體會一下這種絕望而無助的感受！！！
友情提示，前方高能：
看完上面那一大段代碼，有沒有感到後背發涼、一身冷汗？實際上你進行服務間調用時，如果每次都手寫代碼，代碼量比上面那段要多至少幾倍，所以這個事壓根兒就不是地球人能幹的。
既然如此，那怎麼辦呢？別急，Feign早已爲我們提供好了優雅的解決方案。來看看如果用Feign的話，你的訂單服務調用庫存服務的代碼會變成啥樣？
看完上面的代碼什麼感覺？是不是感覺整個世界都乾淨了，又找到了活下去的勇氣！沒有底層的建立連接、構造請求、解析響應的代碼，直接就是用註解定義一個 FeignClient接口，然後調用那個接口就可以了。人家Feign Client會在底層根據你的註解，跟你指定的服務建立連接、構造請求、發起靕求、獲取響應、解析響應，等等。這一系列髒活累活，人家Feign全給你幹了。
那麼問題來了，Feign是如何做到這麼神奇的呢？很簡單，Feign的一個關鍵機制就是使用了動態代理。咱們一起來看看下面的圖，結合圖來分析：
- 首先，如果你對某個接口定義了@FeignClient註解，Feign就會針對這個接口創建一個動態代理
- 接着你要是調用那個接口，本質就是會調用 Feign創建的動態代理，這是核心中的核心
- Feign的動態代理會根據你在接口上的@RequestMapping等註解，來動態構造出你要請求的服務的地址
- 最後針對這個地址，發起請求、解析響應
四、Spring Cloud核心組件：Ribbon
說完了Feign，還沒完。現在新的問題又來了，如果人家庫存服務部署在了5臺機器上，如下所示：
- 192.168.169:9000
- 192.168.170:9000
- 192.168.171:9000
- 192.168.172:9000
- 192.168.173:9000
這下麻煩了！人家Feign怎麼知道該請求哪臺機器呢？
- 這時Spring Cloud Ribbon就派上用場了。Ribbon就是專門解決這個問題的。它的作用是負載均衡，會幫你在每次請求時選擇一臺機器，均勻的把請求分發到各個機器上
- Ribbon的負載均衡默認使用的最經典的Round Robin輪詢算法。這是啥？簡單來說，就是如果訂單服務對庫存服務發起10次請求，那就先讓你請求第1臺機器、然後是第2臺機器、第3臺機器、第4臺機器、第5臺機器，接着再來—個循環，第1臺機器、第2臺機器。。。以此類推。
此外，Ribbon是和Feign以及Eureka緊密協作，完成工作的，具體如下：
- 首先Ribbon會從 Eureka Client裏獲取到對應的服務註冊表，也就知道了所有的服務都部署在了哪些機器上，在監聽哪些端口號。
- 然後Ribbon就可以使用默認的Round Robin算法，從中選擇一臺機器
- Feign就會針對這臺機器，構造併發起請求。
對上述整個過程，再來一張圖，幫助大家更深刻的理解：
五、Spring Cloud核心組件：Hystrix
在微服務架構裏，一個系統會有很多的服務。以本文的業務場景爲例：訂單服務在一個業務流程裏需要調用三個服務。現在假設訂單服務自己最多隻有100個線程可以處理請求，然後呢，積分服務不幸的掛了，每次訂單服務調用積分服務的時候，都會卡住幾秒鐘，然後拋出—個超時異常。
咱們一起來分析一下，這樣會導致什麼問題？
- 如果系統處於高併發的場景下，大量請求湧過來的時候，訂單服務的100個線程都會卡在請求積分服務這塊。導致訂單服務沒有一個線程可以處理請求
- 然後就會導致別人請求訂單服務的時候，發現訂單服務也掛了，不響應任何請求了
上面這個，就是微服務架構中恐怖的服務雪崩問題，
如下圖所示：
如上圖，這麼多服務互相調用，要是不做任何保護的話，某一個服務掛了，就會引起連鎖反應，導致別的服務也掛。比如積分服務掛了，會導致訂單服務的線程全部卡在請求積分服務這裏，沒有一個線程可以工作，瞬間導致訂單服務也掛了，別人請求訂單服務全部會卡住，無法響應。
但是我們思考一下，就算積分服務掛了，訂單服務也可以不用掛啊！爲什麼？
- 我們結合業務來看：支付訂單的時候，只要把庫存扣減了，然後通知倉庫發貨就OK了
- 如果積分服務掛了，大不了等他恢復之後，慢慢人肉手工恢復數據！爲啥一定要因爲一個積分服務掛了，就直接導致訂單服務也掛了呢？不可以接受！
現在問題分析完了，如何解決？
這時就輪到Hystrix閃亮登場了。Hystrix是隔離、熔斷以及降級的一個框架。啥意思呢？說白了，Hystrix會搞很多個小小的線程池，比如訂單服務請求庫存服務是一個線程池，請求倉儲服務是一個線程池，請求積分服務是一個線程池。每個線程池裏的線程就僅僅用於請求那個服務。
打個比方：現在很不幸，積分服務掛了，會咋樣？
當然會導致訂單服務裏那個用來調用積分服務的線程都卡死不能工作了啊！但由於訂單服務調用庫存服務、倉儲服務的這兩個線程池都是正常工作的，所以這兩個服務不會受到任何影響。
這個時候如果別人請求訂單服務，訂單服務還是可以正常調用庫存服務扣減庫存，調用倉儲服務通知發貨。只不過調用積分服務的時候，每次都會報錯。但是如果積分服務都掛了，每次調用都要去卡住幾秒鐘幹啥呢？有意義嗎？當然沒有！所以我們直接對積分服務熔斷不就得了，比如在5分鐘內請求積分服務直接就返回了，不要去走網絡請求卡住幾秒鐘，這個過程，就是所謂的熔斷！
那人家又說，兄弟，積分服務掛了你就熔斷，好歹你乾點兒什麼啊！別啥都不幹就直接返回啊？沒問題，咱們就來個降級：每次調用積分服務，你就在數據庫裏記錄一條消息，說給某某用戶增加了多少積分，因爲積分服務掛了，導致沒增加成功！這樣等積分服務恢復了，你可以根據這些記錄手工加一下積分。這個過程，就是所謂的降級。
爲幫助大家更直觀的理解，接下來用一張圖，梳理一下Hystrix隔離、熔斷和降級的全流程：
六、Spring Cloud核心組件：Zuul
說完了Hystrix，接着給大家說說最後一個組件：Zuul，也就是微服務網關。這個組件是負責網絡路由的。不懂網絡路由？行，那我給你說說，如果沒有Zuul的日常工作會怎樣？
假設你後臺部署了幾百個服務，現在有個前端兄弟，人家請求是直接從瀏覽器那兒發過來的。打個比方：人家要請求一下庫存服務，你難道還讓人家記着這服務的名字叫做inventory-service？部署在5臺機器上？就算人家肯記住這一個，你後臺可有幾百個服務的名稱和地址呢？難不成人家請求一個，就得記住一個？你要這樣玩兒，那真是友誼的小船，說翻就翻！
上面這種情況，壓根兒是不現實的。所以一般微服務架構中都必然會設計一個網關在裏面，像android、ios、pc前端、微信小程序、H5等等，不用去關心後端有幾百個服務，就知道有一個網關，所有請求都往網關走，網關會根據請求中的一些特徵，將請求轉發給後端的各個服務。
而且有一個網關之後，還有很多好處，比如可以做統一的降級、限流、認證授權、安全，等等。
七、總結：
最後再來總結一下，上述幾個Spring Cloud核心組件，在微服務架構中，分別扮演的角色：
- Eureka：各個服務啓動時，Eureka Client都會將服務註冊到Eureka Server，並且Eureka Client還可以反過來從Eureka Server拉取註冊表，從而知道其他服務在哪裏
- Ribbon：服務間發起請求的時候，基於Ribbon做負載均衡，從一個服務的多臺機器中選擇一臺
- Feign：基於Feign的動態代理機制，根據註解和選擇的機器，拼接請求URL地址，發起請求
- Hystrix：發起請求是通過Hystrix的線程池來走的，不同的服務走不同的線程池，實現了不同服務調用的隔離，避免了服務雪崩的問題
- Zuul：如果前端、移動端要調用後端系統，統一從Zuul網關進入，由Zuul網關轉發請求給對應的服務
以上就是我們通過一個電商業務場景，闡述了Spring Cloud微服務架構幾個核心組件的底層原理。
文字總結還不夠直觀？沒問題！我們將Spring Cloud的5個核心組件通過一張圖串聯起來，再來直觀的感受一下其底層的架構原理：
五大核心組件講完了，面試官心中已經知道你對SpringCould的有一定的瞭解了，但這還不夠，你如果講到這個層面，部分面試官還會繼續問，因爲你講解的這些其他面試者也講過，可能也就你講的比較細一些，但本質還是和他們差不了太多，有些公司可能集中招人，負責面試的可能就一個，你想想他這一天可以面試多少個人，這個時候你就需要繼續拓展其他組件，來突出你的不同了。
Spring Cloud Sleuth（服務鏈路追蹤），Spring Cloud Bus（消息總線），Spring Cloud Config（分佈式配置中心）之類的，這裏我就不繼續寫了，給上一個SpringCould專欄（一位大佬寫的，挺不錯的）你去看看吧，最好能實現動手敲上一套，後面你會發現自己對SpringCould的理解遠超其他人。專欄地址是：https://blog.csdn.net/forezp/article/details/70148833
CAP 定論
一個分佈式系統最多隻能同時滿足一致性（Consistency）、可用性（Availability）和分區容錯性（Partition tolerance）這三項中的兩項。
C 一致性即更新操作成功並返回客戶端完成後，所有節點在同一時間的數據完全一致。
A 可用性服務一直可用，而且是正常響應時間。
P 分區容錯性即分佈式系統在遇到某節點或網絡分區故障的時候，仍然能夠對外提供滿足一致性和可用性的服務。
- 對於多數大型互聯網應用的場景，一般保證滿足 P 和 A，捨棄 C（一致性無法保證，退而求其次保證最終一致性）。雖然某些地方會影響客戶體驗，但沒達到造成用戶流失的嚴重程度。如原來同步架構的時候如果沒有庫存，就馬上告訴客戶庫存不足無法下單。但在微服務框架下訂單和庫存可能是兩個微服務對應兩個數據庫，用戶下單時訂單服務是立即生成的，很可能過了一會系統通知你訂單被取消掉（最終一致性）。就像搶購“小米手機”一樣，幾十萬人在排隊，排了很久告訴你沒貨了，明天再來吧。
- 對於涉及到錢財這樣不能有一絲讓步的場景，C 必須保證。網絡發生故障寧可停止服務，這是保證 CA，捨棄 P。
- 還有一種是保證 CP，捨棄 A。例如網絡故障事只讀不寫。
BASE
BASE 是 Basically Available(基本可用)、Soft state(軟狀態)和 Eventually consistent (最終一致性)三個短語的縮寫。是對 CAP 中 AP 的一個擴展
- 基本可用：分佈式系統在出現故障時，允許損失部分可用功能，保證核心功能可用。
- 軟狀態：允許系統中存在中間狀態，這個狀態不影響系統可用性，這裏指的是 CAP 中的不一致。
- 最終一致：最終一致是指經過一段時間後，所有節點數據都將會達到一致。
BASE 解決了 CAP 中理論沒有網絡延遲，在 BASE 中用軟狀態和最終一致，保證了延遲後的一致性。BASE 和 ACID 是相反的，它完全不同於 ACID 的強一致性模型，而是通過犧牲強一致性來獲得可用性，並允許數據在一段時間內是不一致的，但最終達到一致狀態。