首先看一張springCloud的圖片:

二、簡單介紹下什么是springCloud

“Spring Cloud為開發(fā)人員提供了快速構(gòu)建分布式系統(tǒng)中一些常見模式的工具（例如配置管理，服務(wù)發(fā)現(xiàn)，斷路器，智能路由，微代理，控制總線）。分布式系統(tǒng)的協(xié)調(diào)導(dǎo)致了樣板模式, 使用Spring Cloud開發(fā)人員可以快速地支持實現(xiàn)這些模式的服務(wù)和應(yīng)用程序。他們將在任何分布式環(huán)境中運行良好，包括開發(fā)人員自己的筆記本電腦，裸機數(shù)據(jù)中心，以及Cloud Foundry等托管平臺。” -----來自官網(wǎng)

三、為了方便理解假設(shè)一個業(yè)務(wù)場景

假設(shè)現(xiàn)在開發(fā)一個電商網(wǎng)站,要實現(xiàn)支付訂單功能，流程如下：

1.創(chuàng)建一個訂單后,如果用戶立刻支付了這個訂單,我們需要將這個訂單狀態(tài)更新為(已經(jīng)支付)

2.扣減相對應(yīng)的商品庫存

3.通知倉儲中心,進行發(fā)貨

4.給用戶這次購物怎加相對應(yīng)的積分

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

1.用戶針對一個訂單完成支付后,就回去找訂單服務(wù),更新訂單狀態(tài)；

2.訂單服務(wù)調(diào)用庫存服務(wù),完成相應(yīng)的功能；

3.訂單服務(wù)調(diào)用倉儲服務(wù),完成相應(yīng)的功能；

4.訂單服務(wù)調(diào)用積分服務(wù),完成相應(yīng)的功能；

整個過程可以如下圖所示:

四、SpringCloud核心組件Eureka（類似于zookeeper）

首先考慮一個問題，訂單服務(wù)要調(diào)用庫存服務(wù)、倉儲服務(wù)、積分服務(wù)，如何調(diào)用呢？

答：訂單服務(wù)根本不知道上述服務(wù)在哪臺服務(wù)器上，所以沒法調(diào)用，而Eureka的作用就是來告訴訂單服務(wù)它想調(diào)用的服務(wù)在哪臺服務(wù)器上，Eureka有客戶端和服務(wù)端，每一個服務(wù)上面都有Eureka客戶端，可以把本服務(wù)的相關(guān)信息注冊到Eureka服務(wù)端上，那么我們的訂單服務(wù)就可以就可以找到庫存服務(wù)、倉儲服務(wù)、積分服務(wù)了我們上述的業(yè)務(wù)使用Eureka后如下圖：

總結(jié)：

Eurake客戶端：負責(zé)將這個服務(wù)的信息注冊到Eureka服務(wù)端中

Eureka服務(wù)端：相當(dāng)于一個注冊中心，里面有注冊表，注冊表中保存了各個服務(wù)所在的機器和端口號，可以通過Eureka服務(wù)端找到各個服務(wù)。

五、SpringCloud核心組件：Feign（類似于dubbo）

通過上面的Eureka，現(xiàn)在訂單服務(wù)確實知道庫存服務(wù)、積分服務(wù)、倉儲服務(wù)在哪了，但是我們?nèi)绾稳フ{(diào)用這些服務(wù)呢，如果我們自己去寫很多代碼調(diào)用那就太麻煩了，而SpringCloud已經(jīng)為我們準備好了一個核心組件：Feign，接下來看如何通過Feign讓訂單服務(wù)調(diào)用庫存服務(wù)，注意Feign也是用在消費者端的；

訂單服務(wù)：

庫存服務(wù)：

沒有底層的建立連接、構(gòu)造請求、解析響應(yīng)的代碼，直接就是用注解定義一個 FeignClient接口，然后調(diào)用那個接口就可以了。人家Feign Client會在底層根據(jù)你的注解，跟你指定的服務(wù)建立連接、構(gòu)造請求、發(fā)起靕求、獲取響應(yīng)、解析響應(yīng)，等等。這一系列臟活累活，人家Feign全給你干了。

問題來了，F(xiàn)eign是如何做到的呢?其實Feign的一個機制就是使用了動態(tài)代理：

首先，如果你對某個接口定義了@FeignClient注解，F(xiàn)eign就會針對這個接口創(chuàng)建一個動態(tài)代理，接著你要是調(diào)用那個接口，本質(zhì)就是會調(diào)用 Feign創(chuàng)建的動態(tài)代理，這是核心中的核心，F(xiàn)eign的動態(tài)代理會根據(jù)你在接口上的@RequestMapping等注解，來動態(tài)構(gòu)造出你要請求的服務(wù)的地址，最后針對這個地址，發(fā)起請求、解析響應(yīng)。

六、springCloud核心組件：Ribbon

上面可以通過Eureka可以找到服務(wù)，然后通過Feign去調(diào)用服務(wù)，但是如果有多臺機器上面都部署了庫存服務(wù)，我應(yīng)該使用Feign去調(diào)用哪一臺上面的服務(wù)呢，這個時候就需要Ribbon閃亮登場了，它在服務(wù)消費者端配置和使用，它的作用就是負載均衡，然后默認使用的負載均衡算法是輪詢算法，Ribbon會從Eureka服務(wù)端中獲取到對應(yīng)的服務(wù)注冊表，然后就知道相應(yīng)服務(wù)的位置，然后Ribbon根據(jù)設(shè)計的負載均衡算法去選擇一臺機器，F(xiàn)eigin就會針對這些機器構(gòu)造并發(fā)送請求，如下圖所示：

七、SpringCloud的核心組件：Hystrix

在微服務(wù)架構(gòu)里，一個系統(tǒng)會有多個服務(wù)，以本文的電子商務(wù)平臺建設(shè)業(yè)務(wù)場景為例：訂單服務(wù)在一個業(yè)務(wù)流程里需要調(diào)用三個服務(wù)，現(xiàn)在假設(shè)訂單服務(wù)自己最多只有100個線程可以處理請求，如果積分服務(wù)出錯，每次訂單服務(wù)調(diào)用積分服務(wù)的時候，都會卡住幾秒鐘，然后拋出—個超時異常。

分析下這樣會導(dǎo)致什么問題呢？如果系統(tǒng)在高并發(fā)的情況下，大量請求涌過來的時候，訂單服務(wù)的100個線程會卡在積分服務(wù)這塊，導(dǎo)致訂單服務(wù)沒有一個多余的線程可以處理請求，這種問題就是微服務(wù)架構(gòu)中恐怖的服務(wù)器雪崩問題，這么多的服務(wù)互相調(diào)用要是不做任何保護的話,某一個服務(wù)掛掉會引起連鎖反應(yīng)，導(dǎo)致別的服務(wù)掛掉
上述描述如下圖所示：

但是我們想一下，即使積分服務(wù)掛了，那訂單服務(wù)也不應(yīng)該掛掉啊，我們只要讓存儲服務(wù)和倉儲服務(wù)正常工作就可以了，至于積分服務(wù)我們后期可以手動給用戶加上積分，這個時候就輪到Hystrix閃亮登場了，Hystrix是隔離、熔斷以及降級的一個框架，說白了就是Hystrix會搞很多小線程池然后讓這些小線程池去請求服務(wù)，返回結(jié)果，Hystrix相當(dāng)于是個中間過濾區(qū)，如果我們的積分服務(wù)掛了，那我們請求積分服務(wù)直接就返回了，不需要等待超時時間結(jié)束拋出異常，這就是所謂的熔斷，但是也不能啥都不干就返回啊，不然我們之后手動加積分咋整啊，那我們每次調(diào)用積分服務(wù)就在數(shù)據(jù)庫里記錄一條消息，這就是所謂的降級，Hystrix隔離、熔斷和降級的全流程如下：

八、SpringCloud核心組件：zull（類似于服務(wù)器端的nginx）

該組件是負責(zé)網(wǎng)絡(luò)路由的，假設(shè)你后臺部署了幾百個服務(wù)，現(xiàn)在有個前端兄弟，人家請求是直接從瀏覽器那兒發(fā)過來的。打個比方：人家要請求一下庫存服務(wù)，你難道還讓人家記著這服務(wù)的名字叫做inventory-service，并且部署在5臺機器上，就算人家肯記住這一個，那你后臺可有幾百個服務(wù)的名稱和地址呢？難不成人家請求一個，就得記住一個？

上面這種情況，壓根兒是不現(xiàn)實的。所以一般微服務(wù)架構(gòu)中都必然會設(shè)計一個網(wǎng)關(guān)在里面，像android、ios、pc前端、微信小程序、H5等等，不用去關(guān)心后端有幾百個服務(wù)，就知道有一個網(wǎng)關(guān)，所有請求都往網(wǎng)關(guān)走，網(wǎng)關(guān)會根據(jù)請求中的一些特征，將請求轉(zhuǎn)發(fā)給后端的各個服務(wù)。

九、簡單總結(jié)

Eureka：

服務(wù)啟動的時候，服務(wù)上的Eureka客戶端會把自身注冊到Eureka服務(wù)端，并且可以通過Eureka服務(wù)端知道其他注冊的服務(wù)。

Ribbon：

服務(wù)間發(fā)起請求的時候，服務(wù)消費者方基于Ribbon服務(wù)做到負載均衡，從服務(wù)提供者存儲的多臺機器中選擇一臺，如果一個服務(wù)只在一臺機器上面，那就用不到Ribbon選擇機器了，如果有多臺機器，那就需要使用Ribbon選擇之后再去使用。

Feign：

Feign使用的時候會集成Ribbon，Ribbon去Eureka服務(wù)端中找到服務(wù)提供者的所在的服務(wù)器信息，然后根據(jù)隨機策略選擇一個，拼接Url地址后發(fā)起請求。

Hystrix：

發(fā)起的請求是通過Hystrix的線程池去訪問服務(wù)，不同的服務(wù)通過不同的線程池，實現(xiàn)了不同的服務(wù)調(diào)度隔離，如果服務(wù)出現(xiàn)故障，通過服務(wù)熔斷，避免服務(wù)雪崩的問題 ，并且通過服務(wù)降級，保證可以手動實現(xiàn)服務(wù)正常功能。

Zuul：

如果前端調(diào)用后臺系統(tǒng)，統(tǒng)一走zull網(wǎng)關(guān)進入，通過zull網(wǎng)關(guān)轉(zhuǎn)發(fā)請求給對應(yīng)的服務(wù)。

圖片總結(jié)更清晰：

文章來源：CSDN，作者：大胡子哈噔；

編輯：云朵匠 | 數(shù)商云(微信ID：shushangyun_com)

【數(shù)商云www.zhimaihui.cn】致力于提供企業(yè)級的電商平臺服務(wù)，長期為大中型企業(yè)打造數(shù)據(jù)化、商業(yè)化、智能化的電商網(wǎng)站建設(shè)解決方案，同時我們還提供B2B交易系統(tǒng)、B2B2C多用戶商城系統(tǒng)、B2C電子商務(wù)系統(tǒng)、跨境進口電商平臺、供應(yīng)商系統(tǒng)、SRM供應(yīng)商管理系統(tǒng)、SCM系統(tǒng)、渠道管理系統(tǒng)等一系列系統(tǒng)定制開發(fā)服務(wù)，通過大數(shù)據(jù)、云計算等新技術(shù)協(xié)助企業(yè)打造供應(yīng)端—渠道端—營銷端—數(shù)據(jù)端等全鏈數(shù)字化運營體系，提升企業(yè)運營效益與智慧數(shù)字化商業(yè)轉(zhuǎn)型。