微服務高可用方案
一、微服務的高可用
在注冊中心、配置中心高可用方案之前，了解一下注冊中心的工作原理，下面分為兩個部分來解釋，一是注冊中心和各個微服務的注冊表的獲取與同步，二是注冊中心如何去維護注冊表。
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.2、注冊中心維護微服務的注冊表
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.3、分布式注冊中心
了解了注冊中心的工作原理，下面開始研究分布式服務，多注冊中心、多服務實例的情況。
當微服務僅向一台注冊中心注冊時，當這個注冊中心發生故障時，新服務無法繼續注冊上去，舊服務的注冊信息，緩存在其他注冊中心和客戶端中，依舊可以使用，當重啟之后，無法向注冊中心注冊，也是無法使用的。
因此構建高可用的注冊中心時，需要交叉注冊，每個注冊中心既當服務端，又當客戶端，向其他注冊中心注冊自己，同時微服務需要向每個注冊中心進行注冊，由注冊中心自己過濾互備，防止單個注冊中心故障而導致只往它上面注冊微服務重啟后不可用。示意圖如下所示。
目前注冊中心與配置中心集中在一起，可拆可不拆，對整體影響不大，拆分是為了注冊中心和配置中心相互間不影響。gitlab部署在某一台機器上，所有config共用，由於gitlab的原因，導致config的分布式存在單點故障的隱患。每個config分別用獨立的gitlab，又給運維帶來極大的不便。后期采用apollo，用數據庫存儲配置，利用數據庫的分布式優勢替代gitlab，來解決單點故障的問題。
1.4、注冊中心壓測
根據壓測調研，8核4G的Eureka Server在處理1000個服務實例時，沒有任何壓力，在默認情況下，可以處理7000個實例，超出的會超時報錯，在修改tomcat的配置之后，最多可以承載8000實例，此時CPU基本滿載。
升級注意事項：
1、Eureka Server之間相互注冊，Eureka Client需要在每個Server上都注冊一邊
2、Eureka Server開啟自我保護
3、Eureka Client的實例數不超過1000個
參考：
[1] https://www.jianshu.com/p/ae4f0c8b8135
[2] https://www.cnblogs.com/xishuai/p/spring-cloud-eureka-safe.html