微服務高可用方案

微服務高可用方案

1、微服務的高可用

在註冊中心、配置中心高可用方案以前，瞭解一下注冊中心的工做原理，下面分爲兩個部分來解釋，一是註冊中心和各個微服務的註冊表的獲取與同步，二是註冊中心如何去維護註冊表。

1.一、註冊表的獲取與同步

Eureka Server和Eureka Client之間的關係，經過註冊表來維護，而註冊表的經過Eureka Server集中化管理，每一個Client在本地進行註冊表的緩存，經過週期性的任務拉取最新的註冊表信息。簡單的示例圖以下。

根據上圖所展現的流程，能夠了解到註冊中心與微服務之間的基本聯繫的流程：

1．服務A啓動時，向Eureka Server註冊本身的相關信息

2．當服務B向Eureka Server拉取最新的註冊表時，就能夠拿到服務A的一臺機器註冊信息

3．服務A的另外兩臺機器再去註冊，服務B 30s後再次去拉取時，就會獲得服務A的三臺機器的註冊信息

4．服務A、每30s向Eureka Server發送一次心跳信息，代表本身的註冊信息仍是有效的

以上是註冊中心與微服務之間交互的大致流程，在具體的實踐中，Eureka Server會提供多級緩存，其中的註冊表的信息的獲取與同步，又會有細微的差異。

1．Eureka Server的註冊表直接基於純內存，即在內存裏維護了一個數據結構。

2．各個服務的註冊、服務下線、服務故障，所有會在內存裏維護和更新這個註冊表。

3．各個服務每隔30秒拉取註冊表的時候，Eureka Server就是直接提供內存裏存儲的有變化的註冊表數據給他們就能夠了。

4．一樣，每隔30秒發起心跳時，也是在這個純內存的Map數據結構裏更新心跳時間。

Eureka Server的註冊表是純內存處理的，所以處理速度會很快，同時提供 readWriteCacheMap 和 readOnlyCacheMap 作緩存，保障了頻繁讀寫不會衝突。示意圖以下。

上圖介紹了Eureka Server多級緩存的工做原理：

1．當第一臺服務A註冊時，它的註冊信息會更新到內存的註冊表中，若是 readWriteCacheMap 中有相應的信息，則過時掉，若是沒有則不作操做

2．當服務B去拉取註冊表信息時，先找 readOnlyCacheMap ，沒有再找 readWriteCacheMap ，再沒有就去內存的註冊表查找註冊信息，查到就更新到 readWriteCacheMap 中，返回給服務B，服務B的註冊表中，就會有一臺服務A的機器註冊信息

3．readOnlyCacheMap 和 readWriteCacheMap 之間的同步是有一個後臺的定時任務，每隔30s去同步一次，緩存同步任務

4．第二臺服務A註冊時，更新內存的註冊表，同時把 readWriteCacheMap 過時掉

5．在緩存同步任務執行以前服務B去拉取註冊表時，都是從 readOnlyCacheMap 中拿到數據，新的註冊表的信息，不會被服務B拿到

6．30s後，緩存同步任務會同步 readWriteCacheMap 和 readOnlyCacheMap 中的數據，把readOnlyCacheMap 中的註冊表過時掉，這時服務B就會找 readWriteCacheMap 拿數據，readWriteCacheMap 從內存中拿到數據後緩存，返回給服務B，服務B的註冊表中，就會有兩臺服務A的機器註冊信息

7．在下一個30s，緩存同步任務把 readWriteCacheMap 同步到 readOnlyCacheMap 以前， readOnlyCacheMap 沒有第二臺服務A的註冊緩存，所以都是從 readWriteCacheMap 中取到最新數據

注：

readOnlyCacheMap 緩存更新的定時器時間間隔，默認爲30秒

readWriteCacheMap 緩存過時時間，默認爲 180 秒

由以上流程說明可知，Eureka Server採起了多級緩存策略，同時最新的註冊表生效有30s的時延。多級緩存機制的優勢是什麼：

1．儘量保證了內存註冊表數據不會出現頻繁的讀寫衝突問題。

2．而且進一步保證對Eureka Server的大量請求，都是快速從純內存走，性能極高。

1.二、註冊中心維護微服務的註冊表

Eureka Client與註冊表相關的行爲以下所示：

1．服務註冊(Registry)——初始化時執行一次，向服務端註冊本身服務實例節點信息包括ip、端口、實例名等，基於POST請求。

2．服務續約(renew)——默認每隔30s向服務端PUT一次，保證當前服務節點狀態信息實時更新，不被服務端失效剔除。

3．更新已經註冊服務列表(fetchRegistry)——默認每隔30s從服務端GET一次增量版本信息，而後和本地比較併合並，保證本地能獲取到其餘節點最新註冊信息。

4．服務下線(cancel)——在服務shutdown的時候，須要及時通知服務端把本身剔除，以免客戶端調用已經下線的服務。

Eureka Client是經過Jersey Client基於Http協議與Eureka Server交互來註冊服務、續約服務、取消服務、服務查詢等。同時，Server端還會維護一份服務實例清單，並每隔90s對未續約的實例進行失效剔除。

Eureka Server有一個自我保護機制，當網絡發生故障時，客戶端與服務端不通，這是須要啓動Eureka Server的自我保護機制，這樣不會剔除服務，當網絡恢復時，退出自我保護。自我保護有兩個參數，最後一分鐘收到的心跳數（Renews (last min)）、指望收到的心跳數（Renews threshold），當Renews threshold > Renews (last min) 時，進入自我保護模式。

Renews (last min) = 實例數 * 2 #實例數算上Eureka Server自注冊服務

Renews threshold = Renews (last min) * 0.85 # 0.85可配置

下圖的註冊中有10個實例：

推薦多個Eureka Server部署時，開啓自我保護

eureka.client.register-with-eureka = true

1.三、分佈式註冊中心

瞭解了註冊中心的工做原理，下面開始研究分佈式服務，多註冊中心、多服務實例的狀況。

當微服務僅向一臺註冊中心註冊時，當這個註冊中心發生故障時，新服務沒法繼續註冊上去，舊服務的註冊信息，緩存在其餘註冊中心和客戶端中，依舊可使用，當重啓以後，沒法向註冊中心註冊，也是沒法使用的。

所以構建高可用的註冊中心時，須要交叉註冊，每一個註冊中心既當服務端，又當客戶端，向其餘註冊中心註冊本身，同時微服務須要向每一個註冊中心進行註冊，由註冊中心本身過濾互備，防止單個註冊中心故障而致使只往它上面註冊微服務重啓後不可用。示意圖以下所示。

目前註冊中心與配置中心集中在一塊兒，可拆可不拆，對總體影響不大，拆分是爲了註冊中心和配置中心相互間不影響。gitlab部署在某一臺機器上，全部config共用，因爲gitlab的緣由，致使config的分佈式存在單點故障的隱患。每一個config分別用獨立的gitlab，又給運維帶來極大的不便。後期採用apollo，用數據庫存儲配置，利用數據庫的分佈式優點替代gitlab，來解決單點故障的問題。

1.四、註冊中心壓測

根據壓測調研，8核4G的Eureka Server在處理1000個服務實例時，沒有任何壓力，在默認狀況下，能夠處理7000個實例，超出的會超時報錯，在修改tomcat的配置以後，最多能夠承載8000實例，此時CPU基本滿載。

升級注意事項：

一、Eureka Server之間相互註冊，Eureka Client須要在每一個Server上都註冊一邊

二、Eureka Server開啓自我保護

三、Eureka Client的實例數不超過1000個

參考：

[1] https://www.jianshu.com/p/ae4f0c8b8135

[2] https://www.cnblogs.com/xishuai/p/spring-cloud-eureka-safe.html

[3] http://springcloud.cn/view/31