Eureka

首先，我們得說說服務注冊中心 Eureka 了，它應該是SpringCloud 技術棧中最核心的東西。

服務注冊與發現怎么實現的

服務注冊與發現是 Eureka 中最核心的東西。

比如現在我們有一個服務消費者 服務A，和兩個節點的服務提供者，服務B。服務A 和服務B 在啟動的時候都會向注冊中心進行服務注冊。

服務A 也會定時從服務注冊中心定時去拉取服務注冊表信息到本地來，這個過程叫服務發現，默認是30S 一次，當然了可以自己去配置。

如下圖：

實際上當服務在拉取服務注冊表的時候，其實客戶端不是直接從 Eureka 中的 服務注冊表中獲取數據的。

Eureka 做了二級緩存，第一級叫做 ReadOnly 緩存，二級叫做 ReadWrite 緩存。

客戶端會直接從ReadOnly 緩存中讀取注冊表信息。

當服務在進行注冊的時候，先往服務注冊表中寫入注冊信息，服務注冊表更新了，立馬會同步一份數據到 ReadWrite 緩存中去。

那什么時候 ReadWrite 緩存中的數據會到 ReadOnly 緩存中去?

此時有一個定時任務會定時去檢查 ReadWrite 是否跟  ReadOnly 不一致,不一致就把數據同步到 ReadOnly 中去。

這個定時任務也默認是 30S。也可以自己配置。

大家可以考慮一下，這么做的好處是什么，為什么要這么去做二級緩存？

這么做的好處在于，優化并發讀寫的沖突。

如果服務進行注冊的時候，同時有服務來讀去注冊表信息，就會存在頻繁的讀寫加鎖的操作，寫的時候就不能讀，導致性能下降，所以我們需要避免大量的讀寫都去操作一個表。

那么有了這兩層，其實大部分的讀操作都會走 ReadOnly 緩存。只需要定時把 ReadWrite 緩存中的數據寫入到 ReadOnly 就好了。

心跳與故障檢測

服務注冊中心還有一個很重要的功能就是 心跳與故障檢查。心跳跟故障檢測其實就是為了知道注冊上來的這些服務是不是還活著的。

Eureka 還會開啟一個定時任務定時去檢查心跳，默認也是30秒，也可以自己設置。

當出現機器故障沒有在約定的時間間隔內上報自己的狀態，那么Eureka 就會把這臺機器剔除注冊表，同時更新到 ReadWrite 緩存中去。如圖：

但是把數據從ReadWrite 緩存同步到 ReadOnly 緩存是有時間間隔的。當服務消費者A 也只有等待下一次請求更新的時候才會把自己列表里面的服務給更新掉。

所以有時候會出現你注冊上去的服務經過及時秒才被服務消費者發現，或者服務的某個節點出現故障，沒有及時剔除掉。這里就是同步機制的時間差問題。

以上就是 Eureka 的核心運行原理了。

Feign & Ribbon

Feign，它其實就是對一個接口打了一個注解，它會針對這個注解標注的接口生成動態代理對象，然后針對你的 feign 的動態代理代理對象去調用他方法的時候，此時會在底層生成，http 協議格式的請求如：/order/create?productId=1

Feign底層的使用的HTTP 通信框架 HttpClient ,先會使用 Ribbon 從本地的 Eureka 注冊表的緩存里面取出要調用服務的機器列表出來，然后根據負載均衡算法，選擇一臺機器出來，然后針對選擇出來的機器發送 Http 請求過去。

Zuul

Zuul 配置請求路徑與服務的對應關系,你的請求到網關,他就直接查找到匹配的服務,然后就直接把請求轉發給那個服務的某臺機器, Ribbon 從 Eureka 本地緩存列表里面獲取一臺機器,然后通過負載均衡算法選擇一臺,把請求直接用 http 通信框架發送到指定的機器上面去。

Hystrix

在微服務的架構中，會存在很多的服務調用，如果一個服務出現故障，就很容易導致整個調用鏈發生故障，發生服務雪崩的情況。

例如，當一個服務出現故障，或者超時的問題，但是服務調用方不知道，一直在發送請求過去，那么等待的請求越來越多，形成任務積壓，最終導致服務崩潰，癱瘓。

Hystrix 的出現就是為了解決這種問題。它提供了服務降級、服務熔斷、線程和信號隔離、請求緩存、請求合并以及服務監控等強大功能。

Hystrix使用艙壁模式實現線程池的隔離，它會為每一個依賴服務創建一個獨立的線程池，這樣就算某個依賴服務出現延遲過高的情況，也只是對該依賴服務的調用產生影響，而不會拖慢其他的依賴服務。