SpringCloud服務間內部調用原理

前言

SpringCloud中各個服務分佈在不一樣的服務器上，咱們經常使用內部服務調用去調用其餘服務，那麼他們內部究竟是怎麼調用的呢？這裏咱們以一個購物APP爲例子：包含商品服務，倉儲服務，支付服務，購物車服務；

那麼咱們這裏從商品服務獲取了商品，加入了購物車，而後準備支付商品款，再通知倉儲進行發貨。那麼這個過程當中就設計到服務間調用。

在說明調用原理以前咱們先來屢一下思路：每一個服務在不一樣的服務器上，這些服務直接如何發現彼此？

註冊中心

這就引出了註冊中心（服務註冊與發現）；首先每一個服務中都會有一個註解@EurekaClient,就是告訴註冊中心關於本身服務的信息，並且每一個服務都有一個註冊中心EurekaServer的地址，（定時）不停地往註冊中心發送心跳告訴本身是否中斷,註冊中心就維護了一張註冊表，這張註冊表記錄了每一個服務的IP，監聽的端口，服務狀態等信息

那麼若是購物車服務要調用支付服務，那麼它就會問註冊中心：支付服務的註冊信息是啥？而後購物車拿支付服務註冊信息以後就緩存到本地服務中。那麼問題又來了,不一樣服務器之間調用確定須要經過網絡請求到對應服務器上的服務監聽端口？那麼誰來作這個事情呢？

一般咱們在沒有使用微服務框架時，都是經過HttpClient去調用請求，傳遞參數，而後獲取到相應結果進行處理，但這樣每次都寫重複的代碼是否是很煩人？那微服務SpringCloud中誰來幹這個活呢？這裏就引出了Feign這個組件了。

Feign

咱們寫過微服務的你們應該都知道，咱們在實現控制器時，一般都會以實現一個接口，這個接口在服務間進行調用顯示寫法，那麼這個Feign的底層實現原理是啥呢？
咱們前面說了要調用不一樣服務器之間的服務呀就得使用HttpClient形式去調用，Feign就是用來幹這個的。

前面咱們拿到了支付服務的IP與端口，那麼Feign就會將這些信息拼接起來，造成一個網絡請求：Http://服務地址：監聽端口/服務註冊標識/對應的請求MAPPING

Feign實現原理

一般咱們都知道加上@FeignClient註解的都是一個接口，其實這個Feign的原理就是使用的動態代理，經過@FeignClient\@RequestsMapping\@PathValue或者@RequestBody將請求發送到目標HandleMapping上。

這樣咱們就解決了不一樣服務器之間通訊請求鏈接的問題，可是咱們微服務一般都會實現分佈式部署，同一個服務會部署在不一樣的多個服務器上，那麼Feign它又怎麼知道我發給那個服務IP上呢？這個工做是誰來作呢？誰來告訴Feign呢？那麼這裏又引出了一個組件：Ribbon；

Ribbon

沒錯，Ribbon就是來告訴Feign具體發送到那個Ip上的一個負載均衡組件。根據Ribbon中的負載均衡策略，每次都會返回給Feign一個Ip地址用於服務調用。默認狀況下，是均分方式，好比有ip1,ip2,ip3,那麼這個時候來了10個請求，那麼他就先給Ip1,再給ip2,再給ip3,這種輪詢策略將請求分佈到不用別的服務器上

那麼若是這個時候其中一臺服務器的服務掛掉了，會怎麼樣呢？內部服務調用還能繼續嗎？內部又會發生什麼操做呢？

首先固然本次內部調用確定會報服務內部錯誤，由於服務都調不通了嘛。接着出現問題的服務器沒法與註冊中心進行心跳檢查，這個時候註冊中心就會將這個註冊信息狀態改變將其實例下架。而後各客戶端就會更新本地註冊表。那麼當再次內部服務調用時就能夠調用到可用的服務器上的服務。

那麼若是當一個一個服務器上的服務都崩潰了，這個時候支付服務都無法提供服務了，這個時候又會怎麼樣呢？那這個時候全部調用該服務的線程都會卡在這個服務的調用沒法往下走，這個時候嚴重時會致使調用該服務的服務也奔潰沒法服務。

這個地方顯然是不合理的，A服務掛了，關我B服務啥事，最起碼不要讓我也掛了呀。這個時候就會引入一個新東西：Hystrix(熔斷器)

Hystrix服務熔斷與降級

咱們能夠把熔斷器想象爲一個保險絲，在電路系統中，通常在全部的家電系統鏈接外部供電的線路中間都會加一個保險絲，當外部電壓太高，達到保險絲的熔點時候，保險絲就會被熔斷，從而能夠切斷家電系統與外部電路的聯通，進而保障家電系統不會由於電壓太高而損壞。

Hystrix提供的熔斷器就有相似功能，當在必定時間段內服務調用方調用服務提供方的服務的次數達到設定的閾值，而且出錯的次數也達到設置的出錯閾值，就會進行服務降級，讓服務調用方之間執行本地設置的降級策略，而再也不發起遠程調用。可是Hystrix提供的熔斷器具備自我反饋，自我恢復的功能，Hystrix會根據調用接口的狀況，讓熔斷器在closed,open,half-open三種狀態之間自動切換。

open狀態說明打開熔斷，也就是服務調用方執行本地降級策略，不進行遠程調用。
closed狀態說明關閉了熔斷，這時候服務調用方直接發起遠程調用。
half-open狀態，則是一箇中間狀態，當熔斷器處於這種狀態時候，直接發起遠程調用。

使用了熔斷器以後，那麼服務之間就不會有強耦合，不會致使服務間崩潰連鎖反應。從而保證了服務的高可用行，提升了服務的可服務時間。