eureka去中心化

① 86 SpringCloud解決分布式事務

1，分布式事務產生的背景；
分情況而定。
1，在單體項目中，多個不同的業務邏輯都是在同一個數據源中心實現事務管理，是不存在分布式事務的問題。因為在同一個數據源的情況下都是採用事務管理器，相當於每個事務管理器對應一個數據源。
2，在單體項目中，有多個不同的數據源，每個數據源中都有自己獨立的事務管理器，互不影響，那麼這時候也會存在多數據源事務管理：解決方案jta+Atomikos
3，在分布式/微服務架構中。每個服務都有自己的本地的事務。每個服務本地事務互不影響，那麼這時候也會存在分布式事務的問題。
分布式事務產生的背景：訂單服務調用派單服務介面成功之後，可能會引發錯誤。
2pc3pc思想，實際上都是解決我們在分布式系統中，每個節點保證數據一致性問題。
事務的定義。
對我們業務邏輯可以實現提交或者是回滾，保證數據一致性的情況。所以，要麼提交，要麼回滾。
原子性a 要麼提交 要麼回滾。
一致性 c
持久性d 事務一旦提交或者回滾後，不會再對該結果有任何的影響。
Base 與 cap理論。
1，cap定律
這個定理的內容是指的是在一個分布式系統中,Consistency（一致性），Availability（可用性），Partition tolerance(分區容錯性)，二者不可兼容。
1，一致性（C）
在分布式系統中的所有數據備份，是在同一時刻是否同樣的值，（等同於所有節點訪問同一份最新的數據副本）
2，可用性 A
在集群中一部分節點故障後，集群整體是否還能響應客戶端的讀寫請求（對數據更新具有高可用性）

3，分區容錯性（p） 形成腦裂問題：
以實際效果而言，分區相當於對通信的時限要求，系統如果不能再時限內達成數據一致性，就意味著發生了分區的情況，必須就當前操作在C和A之間做出選擇。

4，總結下
以上可以知道分區容錯性（P）主要代表網路波動產生的錯誤，這是不可以避免的，且這三個模式不可以兼得，所以目前就2種模式: cp和Ap模式。
其中cp表示遵循一致性的原則，但不能保證高可用性，其中zookeeper作為注冊中心就是採用cp模式，因為zookeeper有過半節點不可以的話整個zookeeper將不可用。
AP表示遵循於可用性原則，例如Eureka作為注冊中心用的是AP模式，因為其為去中心化，採用你中有我我中有你的相互注冊方式，只要集群中有一個節點可以使用，整個eureka服務就是可用的，但可能會出現短暫的數據不一致問題。

Ap保證可用性：但是不能保證每個副本數據數據一致性，
cp保證數據一致性；如果有過半的zk節點宕機的情況下，不能保證可用性，但是必須保證每個副本節點之間數據一致性，比如zk。

Base理論：
Base是 Basically Available(基本可用)，Softstate(軟狀態)和Eventually consistent(最終一致性)三個短語的縮寫。Base理論是對CAP定理逐步演化而來的，base理論核心思想是：即使無法做到強一致性，但每個應用都可以根據自身業務特點，採用適當的方式達到最終一致性。
1基本可用性；
基本可用是指分布式系統在出現不可預知故障的時候，允許損失部分可用性，注意：這絕不等於系統不可用。
比如： 響應時間的損失，正常情況下，在一個電子商務網站上進行購物的時候，消費者幾乎能順利完成每一筆訂單，但是在一些介入大促銷購物高峰的時候，由於消費者的購物行為激增，為了保護購物系統的穩定性，部分消費者可能被引導在一個降級頁面。
2，軟狀態。
軟狀態指允許系統中的數據存在中間狀態，並認為該中間狀態的存在不會影響系統的整體可用性，既允許系統在不同節點的數據副本之間進行數據同步的過程存在延時。

3，最終一致性
最終一致性強調的是所有的數據副本，在經過一段時間的同步之後，最終都能夠達到一個一致的狀態，因此，最終一致性的本質需要系統保證數據能夠達成一致，而不需要時時保證系統數據的強一致性。

2pc 與3pC
通過2pc和3pc 思想可以實現保證每個節點的數據一致性問題。

目前主流分布式解決框架
1，單體項目多數據源，可以jta+Atomilos；
2，基於Rabbitmq的形式解決 最終一致性思想；
3，基於Rocketmq解決分布式事務 ，採用事務消息。
4，lcn採用lcn模式，假關閉連接
5，Alibaba的seata 背景強大，已經成為了主流。
以上適合於微服務架構中，不適合於和外部介面保證分布式事務問題。
6，跨語言的方式實現解決分布式事務問題。類似於支付寶回調方式。
2階段提交協議基本概念。

2階段提交協議基本概念：

倆階段提交協議可以理解為2pc，也就是分為參與者和協調者，協調者會通過2次階段實現數據最終一致性的
2pc和3pc 的區別就是解決參與者超時問題和多加了一層詢問。保證了數據傳輸的可靠性。
簡單的回顧下lcn解決分布式事務。

http://www.txlcn.org/zh-cn/ LCN並不生產事務，LCN只是本地事務的協調工

現在官網已經不維護呢，可以參考：GitEE

https://gitee.com/wangliang1991/tx-lcn?_from=gitee_search

默認密碼為：codingapi

lcn基本實現的原理：
1，發起方與參與方都與我們的lcn保持長連接；
2，發起方調用介面前，先向lcn管理器中申請一個全局的事務分組id;
3,發起方調用介面的時候在請求頭里傳遞事務分組id.
4,參與方獲取到請求頭中有事務分組的id的，則當前業務邏輯執行完實現假關閉，不會提交或者回滾當前事務，
5，發起方調用完介面後，如果出現異常的情況下，在通知事務協調者回滾事務，這時候事務協調則告訴給參與者回滾當前的事務。

lcn 解決分布式事務的原理：
角色劃分
1，全局事務協調者（組長）；
2，發起方---調用介面者；
3，參與方---被別人調用介面
訂單（發起方）調用派單（參與方）
1.發起方和參與方都會與我們的全局事務協調者保持長連接；

整合和源碼解讀

spring-boot 2.1.6.RELEASE+spring-cloud Greenwich.RELEASE +seata 1.4
pom如下：

file.conf

registry.conf:

yml配置：

添加 DataSourceConfiguration

其他模塊參照此模塊配置，
seata的registry.conf 和file.conf配置和項目配置一致。
添加全局事務：

https://gitee.com/lttwj/wj1/tree/master/seata/springcloud-seata

1,如何學會分析框架的源碼？思想有哪些？
A： spring入口角度分析 springbean 生命周期ioc容器底層原理。
B. 報錯日誌法
2，seata 底層如何解決分布式事務的？
3，seata 如何生成全局xid
4,Seata如何生成前置和後置鏡像。
5，seata 如何傳遞xid的
6， Seata 如何實現逆向回滾
7，如果協調者宕機了，參與事務是回滾還是提交
8，如果協調者宕機發起方沒有通知協調者到底是提交還是回滾？

② Nacos對比Zookeeper、Eureka之間的區別

這個定理的內容是指的是在一個分布式系統中、Consistency（一致性）、 Availability（可用性）、Partition tolerance（分區容錯性），三者不可得兼。

一致性(C)：在分布式系統中，如果伺服器集群，每個節點在同時刻訪問必須要保持數據的一致性。

可用性(A)：集群節點中，部分節點出現故障後任然可以使用 （高可用）

分區容錯性(P)：在分布式系統中網路會存在腦裂的問題，部分Server與整個集群失去節點聯系，無法組成一個群體。
只有在CP和AP選擇一個平衡點

CP情況下：雖然我們服務不通用，但是必須要保證數據的一致性。
AP情況下：可以短暫保證數據不一致性，但是最終可以一致性，不管怎麼樣，要能夠保證我們的服務可用

相同點：三者都可以實現分布式注冊中心框架

不同點：
Zookeeper採用CP保證數據的一致性的問題，原理採用(ZAP原子廣播協議)，當我們ZK領導者因為某種情況下部分節點出現了故障，會自動重新實現選舉新的領導角色，整個選舉的過程中為了保證數據一致性的問題，客戶端暫時無法使用我們的Zookeeper，那麼這以為著整個微服務無法實現通訊。
注意：可運行的節點必須滿足過半機制，整個zk採用使用。

Eureka採用AP設計思想實現分布式注冊中心，完全去中心化、每個節點都是相等，採用你中有我、我中有你相互注冊設計思想， 只要最後有一台Eureka節點存在整個微服務就可以實現通訊。
中心化：必須圍繞一個領導角色作為核心，選舉為領導和跟隨者角色
去中心化：每個角色都是均等

Nacos從1.0版本選擇Ap和CP混合形式實現注冊中心，默認情況下採用Ap，CP則採用Raft協議實現保持數據的一致性。
如果選擇為Ap模式，注冊服務的實例僅支持臨時模式，在網路分區的的情況允許注冊服務實例
選擇CP模式可以支持注冊服務的實例為持久模式，在網路分區的產生了抖動情況下不允許注冊服務實例。

必須要求讀取介面的地址保證強一致性的問題，可以採用cp模式， 一般情況下採用ap就可以了

Zookeeper基於ZAP協議實現保持每個節點的數據同步，中心化思想集群模式，分為領導和跟隨者的角色

在Raft協議中分為的角色

1.狀態：分為三種 跟隨者、競選者、領導

2.大多數： >n/2+1

3.任期：每次選舉一個新的領導角色 任期都會增加。

默認情況下選舉的過程：

核心的設計原理其實就是靠的 誰超時時間最短誰就有非常大的概率為領導角色。

疑問：是否可能會產生兩個同時的競選者呢，同時實現拉票呢？

注意當我們的集群節點總數，如果是奇數情況下 就算遇到了該問題也不用擔心。

當我們的節點是為偶數的情況下，可能會存在該問題，如果兩個競選者獲取的票數相等的情況下，開始重置競選的超時時間，一直到誰的票數最多誰就為領導。

本文參考螞蟻課堂： http://www.mayikt.com/#

③ 26 eureka問題匯總

一 Eureka 伺服器端服務剔除
1，Eureka 服務保護機制是如何實現的
Eureka是在Java語言上，基於Restful API開發的服務注冊與發現組件，由Netflix開源。Eureka遵循AP原則。目前Eureka僅開源到1.X版本，2.X版本已經宣布閉源。

Eureka採用的是Server/Client的模式進行設計：
Server扮演了服務注冊中心的角色，為Client提供服務注冊和發現的功能，維護著注冊到自身的Client的相關信息，同時提供介面給Client獲取到注冊表中其他服務的信息。
Client將有關自己的服務的信息通過一定的方式登記到Server上，並在正常范圍內維護自己信息的一致性，方便其他服務發現自己，同時可以通過Server獲取到自己的依賴的其他服務信息，從而完成服務調用。
Server不進行選舉，沒有Leader，是一種去中心化的架構，節點都是對等的，通過相互注冊提高可用性，通過數據拷貝的方式實現數據的最終一致性。

在集群環境中，如果某台Server節點宕機，Client的請求會自動切換到新的Server節點上，當宕機的伺服器重新恢復後，Eureka會再次將其納入到伺服器集群管理之中。

自我保護機制
默認情況下，如果Server在一定時間內沒有接收到某個服務實例的心跳（默認周期為30秒），Server將會注銷該實例（默認為90秒)。如果在15分鍾內超過85%的節點都沒有正常的心跳，那麼Eureka就認為客戶端與注冊中心出現了網路故障，啟動自我保護機制：

Eureka不再從注冊表中移除因為長時間沒有收到心跳而過期的服務；
Eureka仍然能夠接受新服務注冊和查詢請求，但是不會被同步到其它節點上（即保證當前節點依然可用）；
當網路穩定時，當前實例新注冊的信息會被同步到其它節點中；
自我保護機制是Eureka遵循AP原則、保證可用性的關鍵，只要有一台Server還在就能對外提供服務，但是不保證強一致性，Server內部數據可能不是最新的。
————————————————

2，為什麼有人說Eureka服務保護是累贅
因為Eureka的高可用性選擇，所以設計了一個自我保護機制，保護那些因為網路分區問題影響的微服務不會移除。但是也可能保護了真正出現了問題的微服務。這個時候，其他的微服務調用這個服務時，可能就會得到一個錯誤的結果，這種情況只能在調用端自行解決，比如通過Hystrix進行隔離熔斷。
3，Eureka 集群環境如何搭建

4，EurekaApp模式如何同步的數據
5，Eureka集群獲取宕機後的怎麼辦
ureka-Server 高可用集群 關於宕機後主動踢出該節點
6，開啟了服務保護機制，調用了宕機地址怎麼辦？

Ap模式： 核心 主要保證高可用：
沒有保證集群每個節點數據一致性問題
CP模式 核心： 主要保證每台節點數據一致性，有可能會發生導致集群環境不可用
Eureka ap模式

④ 服務治理選型、Eureka、Consul 的區別

CAP定理：指的是在一個分布式系統中，Consistency（一致性）、 Availability（可用性）、Partition tolerance（分區容錯性），三者不可同時獲得。

解釋CAP理論： 就是說在分布式存儲系統中,要滿足P，就是允許網路通信可能失敗，那麼在多個副本之間的同步就可能存在失敗，那麼某個副本就可能存在過期的數據，只能同時滿足兩點既AP或者CP,既：我們只能在一致性和可用性之間進行權衡((A)和（C）互斥)。

使用場景,注冊中心選擇：
Consul ：CP設計，保證了一致性，集群搭建的時候，某個節點失效，則會進行選舉行的leader，或者半數以上節點不可用，則無法提供服務，因此可用性沒法滿足

Eureka：AP原則，無主從節點，一個節點掛了，自動切換其他節點可以使用，去中心化

結論：分布式系統中P,肯定要滿足，所以只能在CA中二選一
沒有最好的選擇，最好的選擇是根據業務場景來進行架構設計
如果要求一致性，則選擇Consul，如金融行業
如果要去可用性，則Eureka，如電商系統

最大的區別是Eureka保證AP, Consul為CP。

服務注冊稍慢，根據raft協議當Leader掛掉時，重新選舉期間整個consul不可用,這里可以加入重試機制，在一定時間沒有收到 Leader 的數據已接收確認後進行一定次數的重試，並再次向新的 Leader 發送數據來確保業務的流暢性。

服務注冊更快，保證了每個節點都可用，但是不保證每個節點的數據一致。如此保證了可用性。

⑤ 90 SpringCloud 解決分布式事務--lcn解決分布式事務

1，分布式事務產生的背景。
分情況而定
1， 在單體的項目中，多個不同的業務邏輯都是在同一個數據源中實現事務管理，是不存在分布式事務的問題，因為同一個數據源的情況都是採用事務管理器，相當於每個事務管理器對應一個數據源。
[圖片上傳失敗...(image-810669-1618491127348)]
2，在單體的項目中，有多個不同的數據源，每個數據源都有自己獨立的事務管理器，互不影響，那麼這時候也會存在多數據源事務管理： 解決方案 jta+Atomikos
[圖片上傳失敗...(image-7df061-1618491220423)]
3，在分布式/微服務架構中，每個服務都有自己的本地事務，每個服務本地事務互不影響，那麼這時候也會存在分布式事務的問題。
事務的定義：
對我們的業務邏輯可以實現提交或者回滾，保證數據的一致性的情況。
所以要麼提交，要麼回滾
原子性a 要麼提交 要麼回滾
一致性c
隔離性i 多個事務在一起執行的時候，互不影響；
持久性d 事務一旦提交或者回滾後，不會在對該結果有任何影響

2，傳統分布式事務解決方案
3，2PC/3PC協議使用場景。
4，LCN為什麼不更新了？那些思想值得學習、
5，分布式事務解決方案有哪些？
6，強一致性/最終一致性區別。
7，LCn深度源碼解讀。

1 CAP定律和BASE理論

1.1 CAP定律#

這個定理的內容是指的是在一個分布式系統中、Consistency（一致性）、 Availability（可用性）、Partition tolerance（分區容錯性），三者不可得兼。

（一）一致性（C）

在分布式系統中的所有數據備份，在同一時刻是否同樣的值。（等同於所有節點訪問同一份最新的數據副本）

（二）可用性（A）

在集群中一部分節點故障後，集群整體是否還能響應客戶端的讀寫請求。（對數據更新具備高可用性）

（三）分區容錯性（P） 形成腦裂問題

以實際效果而言，分區相當於對通信的時限要求。系統如果不能在時限內達成數據一致性，就意味著發生了分區的情況，必須就當前操作在C和A之間做出選擇。

https://ke..com/item/%E5%AE%B9%E9%94%99%E7%8E%87/9967698?fr=aladdin

（四）總結一下

以上可以知道分區容錯性（P）主要代表網路波動產生的錯誤，這是不可避免的，且這個三個模式不可兼得，所以目前就只有兩種模式：CP和AP模式。

其中CP表示遵循一致性原則，但不能保證高可用性，其中zookeeper作為注冊中心就是採用CP模式，因為zookeeper有過半節點不可以的話整個zookeeper將不可用。

AP表示遵循於可用性原則，例如Eureka作為注冊中心用的是AP模式，因為其為去中心化，採用你中有我我中有你的相互注冊方式，只要集群中有一個節點可以使用，整個eureka服務就是可用的，但可能會出現短暫的數據不一致問題。

AP保證可用性：但是不能保證每個副本數據數據一致性；

CP保證數據一致性：如果有過半的zk節點宕機的情況下，不能保證可用性，但是必須保證每個副本節點之間數據一致性， 比如ZK；

BASE是Basically Available（基本可用）、Soft state（軟狀態）和 Eventually consistent（最終一致性）三個短語的縮寫。BASE理論是對CAP中一致性和可用性權衡的結果，其來源於對大規模互聯網系統分布式實踐的總結， 是基於CAP定理逐步演化而來的。BASE理論的核心思想是：即使無法做到強一致性，但每個應用都可以根據自身業務特點，採用適當的方式來使系統達到最終一致性。

（一）基本可用

基本可用是指分布式系統在出現不可預知故障的時候，允許損失部分可用性，注意，這絕不等價於系統不可用。

比如：響應時間上的損失。正常情況下，一個在線搜索引擎需要在0.5秒之內返回給用戶相應的查詢結果，但由於出現故障，查詢結果的響應時間增加了1~2秒。

系統功能上的損失：正常情況下，在一個電子商務網站上進行購物的時候，消費者幾乎能夠順利完成每一筆訂單，但是在一些節日大促購物高峰的時候，由於消費者的購物行為激增，為了保護購物系統的穩定性，部分消費者可能會被引導到一個降級頁面。

（二）軟狀態

軟狀態指允許系統中的數據存在中間狀態，並認為該中間狀態的存在不會影響系統的整體可用性， 即允許系統在不同節點的數據副本之間進行數據同步的過程存在延時 。

（三）最終一致性

最終一致性強調的是所有的數據副本，在經過一段時間的同步之後，最終都能夠達到一個一致的狀態。因此，最終一致性的本質是需要系統保證最終數據能夠達到一致，而不需要實時保證系統數據的強一致性。

目前主流分布式解決框架：
1，單體項目多數據源，可以jta+Atomikos
2,基於RabbitMQ的形式解決，最終一致性的思想。
3，基於RocketMQ解決分布式事務，採用事務消息。
4，LCn採用lcn模式，假關閉連接
5,Alibaba的Seata

6，跨語言的方式實現解決分布式事務問題，類似於支付寶回調。
倆階段提交協議基本概念：
2階段提交協議可以理解為2pc，也就是分為參與者和協調者，協調者會通過2次階段實現數據最終一致性。
2pc和3pc的區別就是解決參與者超時的問題和多加了一層詢問，保證數據的傳輸可靠性。

http://www.txlcn.org/zh-cn/ LCN並不生產事務，LCN只是本地事務的協調工

現在官網已經不維護呢，可以參考：GitEE

https://gitee.com/wangliang1991/tx-lcn?_from=gitee_search

默認密碼為：codingapi
lcn基本實現處理：
1，發起方與參與方都與我們的lcn管理器一直保持長連接；
2，發起方在調用介面前，先向lcn管理器中申請一個全局的事務分組id.
3,發起方調用介面的時候在請求頭中傳遞事務分組id
,4參與方獲取到請求頭中有事務分組的id的，則當前業務邏輯執行完實現假關閉，不會提交或者回滾事務『
5，發起方調用完介面後，如果出現異常的情況下，在通知給事務回滾事務，這時候事務協調則告訴參與方回滾當前的事務。
lcn解決分布式事務的原理：
角色劃分：
1，全局事務協調者（組長）；
2，發起方--調用介面者
3，參與方--被別人調用介面。
訂單（發起方）調用派單（參與方）
1.發起方和參與方都會與我們的全局事務協調者保持長連接；

SpringBoot整合lcn5.0

Maven依賴

相關配置

參與方獲取全局id
1.SpringTracingApplier
攔截器 獲取feign客戶端請求頭中的參數全局事務分組id，緩存到threadlocal中。

⑥ zookeeper和eureka的區別

zookeeper和eureka的區別：

CAP 原則又稱 CAP 定理，1998年，加州大學的計算機科學家 Eric Brewer 提出的，指的是在一個分布式系統中，Consistency（一致性）、Availability（可用性）、Partition tolerance（分區容錯性），三者不可兼得（我們常說的魚和熊掌不可兼得）。CAP 原則也是 NoSQL 資料庫的基石。

1、一致性（Consistency，C）：

在分布式系統中的所有數據備份，在同一時刻是否同樣的值。（等同於所有節點訪問同一份最新的數據副本）。

2、可用性（Availability，A）：

在一個分布式系統的集群中一部分節點故障後，該集群是否還能夠正常響應客戶端的讀寫請求。（對數據更新具備高可用性）。

3、分區容錯性（Partition tolerance，P）：

當一個新的 Eureka Server 節點啟動後，會首先嘗試從鄰近節點獲取所有注冊列表信息，並完成初始化。Eureka Server 通過 getEurekaServiceUrls方法獲取所有的節點，並且會通過心跳契約的方式定期更新。

默認情況下，如果 Eureka Server 在一定時間內沒有接收到某個服務實例的心跳，Eureka Server 將會注銷該實例。當 Eureka Server 節點在短時間內丟失過多的心跳時，那麼這個節點就會進入自我保護模式。

Apache Zookeeper -> CP

與 Eureka 有所不同，Apache Zookeeper 在設計時就緊遵CP原則，即任何時候對Zookeeper 的訪問請求能得到一致的數據結果，同時系統對網路分割具備容錯性，但是 Zookeeper 不能保證每次服務請求都是可達的。

從 Zookeeper 的實際應用情況來看，在使用 Zookeeper 獲取服務列表時，如果此時的 Zookeeper 集群中的 Leader 宕機了，該集群就要進行 Leader 的選舉，又或者 Zookeeper 集群中半數以上伺服器節點不可用，那麼將無法處理該請求。所以說，Zookeeper 不能保證服務可用性。

當然，在大多數分布式環境中，尤其是涉及到數據存儲的場景，數據一致性應該是首先被保證的，這也是 Zookeeper 設計緊遵CP原則的另一個原因。

但是對於服務發現來說，情況就不太一樣了，針對同一個服務，即使注冊中心的不同節點保存的服務提供者信息不盡相同，也並不會造成災難性的後果。

因為對於服務消費者來說，能消費才是最重要的，消費者雖然拿到可能不正確的服務實例信息後嘗試消費一下，也要勝過因為無法獲取實例信息而不去消費，導致系統異常要好

⑦ 閑聊注冊中心——ZK、Eureka、Sofa-Registry

最開始服務之間的調用藉助的是域名，域名其實是個好東西，使用起來很方便，但所有調用請求都得走域名解析和負載均衡，相對來說性能就差一點，而且這些夾在中間的零部件會演變成性能瓶頸和潛在的單點風險，後來大家一比較發現還不如直接端到端調用，那麼就需要一個東西把調用鏈的兩端連起來，這就是注冊中心。

注冊中心提供服務的注冊發現，用來連接調用鏈路的 Provider 和 Consumer 這兩個端點。一個注冊中心得管理好服務的擴縮容、故障轉移、流量分配這類的核心功能，自身同樣需要高可用，妥善解決跨地域部署情況下注冊中心節點之間的數據一致性，因此我更傾向於認為注冊中心是一個偏向體系化的產品，它的價值依賴於與之相匹配的服務規模和治理體系，它的思想雖然產生得很早，但是規模化地落地並不容易，偏小的服務規模本身對於注冊中心的依賴並不明顯，實現的手段也沒有定式；大型服務又會對注冊中心的定位、功能提出更苛刻的需求。

究竟是選擇強一致性還是高可用性，當下的主流技術選型傾向於後者，但這並不是說明 CP 組件沒有存在的意義，而是 AP 組件更契合互聯網對於注冊中心的定位。

互聯網系統高可用永遠是擺在首位的東西，因為系統不可用的時間通常跟財產損失直接掛鉤。服務列表在短時間少了一兩個節點、多了一兩個節點，這點流量傾斜對於大多數服務來說感知並不明顯，只需要注冊中心在某個短暫的時間窗口內重新達到一致性的狀態就可以，注冊中心不應該在運行時影響到處於正常調用的兩個端點之間的連通性。

CP 的代表就是 zookeeper ，至今 zookeeper 也是非常流行的用於注冊中心的組件，這在一定程度上要感謝 bbo 。 bbo 在 zookeeper 中是用一個樹形結構的兩個節點，分別維護服務的 Provider 和 Comsumer 的，列表注冊在這兩個節點下面，服務的健康檢查依賴 zookeeper 提供的臨時節點特性，實際上跟 session 的生命周期綁定在一起，但臨時節點的問題就是數據易失，一旦集群故障節點重啟丟失服務列表，可能造成服務大面積癱瘓，電商新貴 PDD 就曾經出現過這個問題。

CP 最關鍵的問題在於無法支持機房容災，例如 ABC 三個機房，機房 C 和其他兩個機房產生了網路隔離，部署在機房 C 的 zookeeper 節點是無法提供寫入的，這意味著機房 C 部署的 Provider 不能擴縮容、不能重啟，最好在故障期間一直保持原樣，否則 Provider 任何操作都會是高危的，會直接影響到部署在機房 C 的 Comsumer 。

順帶說一句，我認為 zookeeper 真挺好的，它本身的定位就是個分布式協調服務，並不是專門為注冊中心設計的，你不能拿評價注冊中心的眼光去評價它，你要的功能 zookeeper 基本上都有，藉助 Curator 拿來就可以用，提供了 election ，提供了 ZAB ， TPS 低了點（其實也可以了）但是也滿足大部分服務規模。

Eureka —— 奈飛的網紅組件， AP 注冊中心的代表。 Eureka 1.x 今天回頭看來是個很牽強的實現，因為它的架構從誕生之日起，就意味著將來數據規模增長之後大概率會出問題，集群整體可伸縮性很低，每擴容一台 Eureka 節點意味著整體點對點之間需要多一份數據流，而這種 Peer 點對點機制的數據流很容易打滿網卡，造成服務端壓力。根據公開的資料， Eureka 在實例規模五千左右時就會出現明顯的性能瓶頸，甚至是服務不可用的情況。

但是從另一個方面來說， Eureka 的架構清晰、運維部署都很方便，而且 Eureka 作為 SpringCloud 推薦的注冊中心實現，國內用戶數目也相當可觀，可見在服務規模恰當的情況下其性能並沒有問題，從攜程的分享資料也可以看出，其內部的注冊中心也是類似於 Eureka 的實現，可見沒有絕對完美的架構設計，適合自己、滿足業務需求才是最主要的。

Eureka 服務端多節點架構其實有點去中心化的意思，有意保持了每個節點的無狀態特性，但是代價就是每個節點都持有全量數據，新增的數據可以往任意一個節點寫入，然後由這個節點向其他節點廣播，最終達到一致性。

數據都沒有持久化，僅保存在內存中，帶來了更好的讀寫性能、更短的響應時間，但是無法處理數據瓶頸，大節點擴容造成的數據同步存在打滿網卡的風險，這點跟 redis 集群很像。客戶端 30s 定期上報心跳、客戶端緩存服務列表這些都沒什麼好談的， Eureka 有個很有意思的點是，它的集群節點實現了一個自我保護機制，用來預測到底是集群出問題還是客戶端出問題，實現很簡單但是思想挺實用的。

Eureka 2.0 的設計文檔上體現了讀寫分離集群的思想，本質上是為了提升集群性能和容量，但是非常遺憾，目前 2.0 的狀態是 Discontinued ，短時間應該不會有成熟的產品出現。

雖然沒有 Eureka 2.0 ，但是可以從螞蟻開源的 Sofa-Registry 中了解類似思想的實現，Sofa-Registry 脫胎於阿里的 ConfigServer ，從公開的資料顯示，國內阿里應該是最早做注冊中心讀寫分離實踐的。

這種架構帶來的直接好處就是可以支持海量數據，第一層的 session 集群可以無限水平擴展，彼此之間完全不需要通信， session 集群在內存中維護了注冊中心需要的一切拓撲關系，客戶端僅僅連接一部分 session 集群中的機器，如果某台 session 機器掛了客戶端會選擇另一台重連；背後的 data 集群則通過分片存儲所有的源數據，分片之間通過主從副本保證高可用，再將源數據推送到 session 集群保存下來，供客戶端讀取。

缺點也很明顯，這種架構人力投入、運維成本肯定高於 Eureka 。

這幾乎是注冊中心不可避免的問題，高可用、機房容災、網路延遲等都會催生出要求注冊中心節點能夠跨地域部署，這會引申出另一個問題就是如何做數據同步。

這種情況下已經不可能通過客戶端注冊或者是集群節點數據流復制來保證異地注冊中心集群之間的數據一致，而是會研發單獨的數據同步組件，通過跨地域專線實現地域間注冊中心的數據同步，如果專線斷開，此時各自地域的注冊中心依舊可以獨立服務於本地域內服務的調用，等到專線恢復，二者的數據繼續進行同步合並糾正，最終達到一致性。對這個知識點感興趣的可以了解下 Nacos-Sync 組件，是 Nacos 項目專門推出的開源數據同步服務。

文章略過了一些注冊中心通用的概念，例如數據模型的分層、服務列表本地緩存、健康檢查的方式、推拉權衡等，我認為敘述這些細節的意義並不大。

很多時候，理解某個組件我認為最重要的是理清它的架構演進過程，這是寶貴的經驗財富，你可以抓住並學習每次架構演進的方向和原因。

⑧ springcloud四個注冊中心的比較

springcloud是一個非常優秀的微服務框架，要管理眾多的服務，就需要對這些服務進行治理，也就是我們說的 服務治理 , 服務治理 的作用就是在傳統的rpc遠程調用框架中，管理每個服務與每個服務之間的依賴關系，可以實現服務調用、負載均衡、服務容錯、以及服務的注冊與發現。
​ 如果微服務之間存在調用依賴，就需要得到目標服務的服務地址，也就是微服務治理的 服務發現 。要完成服務發現，就需要將服務信息存儲到某個載體，載體本身即是微服務治理的 服務注冊中心 ，而存儲到載體的動作即是 服務注冊 。
​ springcloud支持的注冊中心有 Eureka 、 Zookeeper 、 Consul 、 Nacos

Spring Cloud Netflix 在設計 Eureka 時就緊遵AP原則,Eureka Server 也可以運行多個實例來構建集群，解決單點問題，但不同於 ZooKeeper 的選舉 leader 的過程，Eureka Server 採用的是Peer to Peer 對等通信。這是一種去中心化的架構，無 master/slave 之分，每一個 Peer 都是對等的。在這種架構風格中，節點通過彼此互相注冊來提高可用性，每個節點需要添加一個或多個有效的 serviceUrl 指向其他節點。每個節點都可被視為其他節點的副本。

在集群環境中如果某台 Eureka Server 宕機，Eureka Client 的請求會自動切換到新的 Eureka Server 節點上，當宕機的伺服器重新恢復後，Eureka 會再次將其納入到伺服器集群管理之中。當節點開始接受客戶端請求時，所有的操作都會在節點間進行復制（replicate To Peer）操作，將請求復制到該 Eureka Server 當前所知的其它所有節點中。

Eureka的集群中，只要有一台Eureka還在，就能保證注冊服務可用（保證可用性），只不過查到的信息可能不是最新的（不保證強一致性）。除此之外，Eureka還有一種自我保護機制，如果在15分鍾內超過85%的節點都沒有正常的心跳，那麼Eureka就認為客戶端與注冊中心出現了網路故障，此時會出現以下幾種情況:

因此，Eureka可以很好的應對因網路故障導致部分節點失去聯系的情況，而不會像zookeeper那樣使得整個注冊服務癱瘓

與 Eureka 有所不同，Apache Zookeeper 在設計時就緊遵CP原則，即任何時候對 Zookeeper 的訪問請求能得到一致的數據結果，同時系統對網路分割具備容錯性，但是 Zookeeper 不能保證每次服務請求都是可達的。從 Zookeeper 的實際應用情況來看，在使用 Zookeeper 獲取服務列表時，如果此時的 Zookeeper 集群中的 Leader 宕機了，該集群就要進行 Leader 的選舉，又或者 Zookeeper 集群中半數以上伺服器節點不可用（例如有三個節點，如果節點一檢測到節點三掛了 ，節點二也檢測到節點三掛了，那這個節點才算是真的掛了），那麼將無法處理該請求。所以說，Zookeeper 不能保證服務可用性。

Consul 是 HashiCorp 公司推出的開源工具，用於實現分布式系統的服務發現與配置。Consul 使用 Go 語言編寫，因此具有天然可移植性（支持Linux、windows和Mac OS X）。Consul 內置了服務注冊與發現框架、分布一致性協議實現、健康檢查、Key/Value 存儲、多數據中心方案，不再需要依賴其他工具（比如 ZooKeeper 等），使用起來也較為簡單。
Consul 遵循CAP原理中的CP原則，保證了強一致性和分區容錯性，且使用的是Raft演算法，比zookeeper使用的Paxos演算法更加簡單。雖然保證了強一致性，但是可用性就相應下降了，例如服務注冊的時間會稍長一些，因為 Consul 的 raft 協議要求必須過半數的節點都寫入成功才認為注冊成功 ；在leader掛掉了之後，重新選舉出leader之前會導致Consul 服務不可用。

Nacos是阿里開源的，Nacos 支持基於 DNS 和基於 RPC 的服務發現。Nacos除了服務的注冊發現之外，還支持動態配置服務。動態配置服務可以讓您以中心化、外部化和動態化的方式管理所有環境的應用配置和服務配置。動態配置消除了配置變更時重新部署應用和服務的需要，讓配置管理變得更加高效和敏捷。配置中心化管理讓實現無狀態服務變得更簡單，讓服務按需彈性擴展變得更容易。 一句話概括就是Nacos = 注冊中心 + 配置中心。

這四個組件雖然都實現了注冊中心的功能，但是他們的功能和實現方式都有不同的地方，也各有各的優點,單從注冊中心方面來比價四個注冊中心(如果不了解 CAP定理 可先閱讀下一章節):

CAP原則的精髓就是要麼AP，要麼CP，要麼AC，但是不存在CAP。如果在某個分布式系統中數據無副本， 那麼系統必然滿足強一致性條件， 因為只有獨一數據，不會出現數據不一致的情況，此時C和P兩要素具備，但是如果系統發生了網路分區狀況或者宕機，必然導致某些數據不可以訪問，此時可用性條件就不能被滿足，即在此情況下獲得了CP系統，但是CAP不可同時滿足。

因此在進行分布式架構設計時，必須做出取捨。當前一般是通過分布式緩存中各節點的最終一致性來提高系統的性能，通過使用多節點之間的數據非同步復制技術來實現集群化的數據一致性。通常使用類似 memcached 之類的 NOSQL 作為實現手段。雖然 memcached 也可以是分布式集群環境的，但是對於一份數據來說，它總是存儲在某一台 memcached 伺服器上。如果發生網路故障或是伺服器死機，則存儲在這台伺服器上的所有數據都將不可訪問。由於數據是存儲在內存中的，重啟伺服器，將導致數據全部丟失。當然也可以自己實現一套機制，用來在分布式 memcached 之間進行數據的同步和持久化，但是實現難度是非常大的

例如，根據CAP定理將NoSql數據分成了滿足CA原則、滿足CP原則和滿足AP原則的三大類:

⑨ 【知識總結】6.服務注冊發現框架比較(Consul/Zookeeper/etcd/Eureka)

服務發現就是服務提供者將自己提供的地址post或者update到服務中介，服務消費者從服務中介那裡get自己想要的服務的地址。

但是有兩個問題：
第一個問題：如果有一個服務提供者宕機，那麼中介的key/value中會有一個不能訪問的地址，該怎麼辦？

心跳機制： 服務提供者需要每隔5秒左右向服務中介匯報存活，服務中介將服務地址和匯報時間記錄在zset數據結構的value和score中。服務中介需要每隔10秒左右檢查zset數據結構，踢掉匯報時間嚴重落後的地址。這樣就可以保證服務列表中地址的有效性。

第二個問題是服務地址變動時如何通知消費者。有兩種解決方案。

第一種是輪詢，消費者每隔幾秒查詢服務列表是否有改變。如果服務地址很多，查詢會很慢。這時候可以引入服務版本號機制，給每個服務提供一個版本號，在服務變動時，遞增這個版本號。消費者只需要輪詢這個版本號的變動即可知道服務列表是否發生了變化。

第二種是採用pubsub。這種方式及時性要明顯好於輪詢。缺點是每個pubsub都會佔用消費者一個線程和一個額外的連接。為了減少對線程和連接的浪費，我們使用單個pubsub廣播全局版本號的變動。所謂全局版本號就是任意服務列表發生了變動，這個版本號都會遞增。接收到版本變動的消費者再去檢查各自的依賴服務列表的版本號是否發生了變動。這種全局版本號也可以用於第一種輪詢方案。

CAP理論
CAP理論是分布式架構中重要理論

關於P的理解，我覺得是在整個系統中某個部分，掛掉了，或者宕機了，並不影響整個系統的運作或者說使用，而可用性是，某個系統的某個節點掛了，但是並不影響系統的接受或者發出請求，CAP 不可能都取，只能取其中2個。原因是

（1）如果C是第一需求的話，那麼會影響A的性能，因為要數據同步，不然請求結果會有差異，但是數據同步會消耗時間，期間可用性就會降低。

（2）如果A是第一需求，那麼只要有一個服務在，就能正常接受請求，但是對與返回結果變不能保證，原因是，在分布式部署的時候，數據一致的過程不可能想切線路那麼快。

（3）再如果，同事滿足一致性和可用性，那麼分區容錯就很難保證了，也就是單點，也是分布式的基本核心，好了，明白這些理論，就可以在相應的場景選取服務注冊與發現了。

平時經常用到的服務發現的產品進行下特性的對比，首先看下結論：

補充：
（1）運維和開發如果是 Java 更熟，也更多 Java 的應用，那毫無疑問應該用 ZK；如果是搞 Go 的，那麼還是 etcd 吧，畢竟有時候遇到問題還是要看源碼的。
（2）在創建一百萬個或更多鍵時，etcd可以比Zookeeper或Consul穩定地提供更好的吞吐量和延遲。此外，它實現了這一目標，只有一半的內存，顯示出更高的效率。但是，還有一些改進的餘地，Zookeeper設法通過etcd提供更好的最小延遲，代價是不可預測的平均延遲。
（3）
一致性協議： etcd 使用 Raft 協議，Zookeeper 使用 ZAB（類PAXOS協議），前者容易理解，方便工程實現；
運維方面：etcd 方便運維，Zookeeper 難以運維；
數據存儲：etcd 多版本並發控制（MVCC）數據模型 ， 支持查詢先前版本的鍵值對
項目活躍度：etcd 社區與開發活躍，Zookeeper 感覺已經快死了；
API：etcd 提供 HTTP+JSON, gRPC 介面，跨平台跨語言，Zookeeper 需要使用其客戶端；
訪問安全方面：etcd 支持 HTTPS 訪問，Zookeeper 在這方面缺失；

與 Eureka 有所不同，Apache Zookeeper 在設計時就緊遵CP原則，即任何時候對 Zookeeper 的訪問請求能得到一致的數據結果，同時系統對網路分割具備容錯性，但是 Zookeeper 不能保證每次服務請求都是可達的。

從 Zookeeper 的實際應用情況來看，在使用 Zookeeper 獲取服務列表時，如果此時的 Zookeeper 集群中的 Leader 宕機了，該集群就要進行 Leader 的選舉，又或者 Zookeeper 集群中半數以上伺服器節點不可用（例如有三個節點，如果節點一檢測到節點三掛了 ，節點二也檢測到節點三掛了，那這個節點才算是真的掛了），那麼將無法處理該請求。所以說，Zookeeper 不能保證服務可用性。

當然，在大多數分布式環境中，尤其是涉及到數據存儲的場景，數據一致性應該是首先被保證的，這也是 Zookeeper 設計緊遵CP原則的另一個原因。

但是對於服務發現來說，情況就不太一樣了，針對同一個服務，即使注冊中心的不同節點保存的服務提供者信息不盡相同，也並不會造成災難性的後果。

因為對於服務消費者來說，能消費才是最重要的，消費者雖然拿到可能不正確的服務實例信息後嘗試消費一下，也要勝過因為無法獲取實例信息而不去消費，導致系統異常要好（淘寶的雙十一，京東的618就是緊遵AP的最好參照）。

當master節點因為網路故障與其他節點失去聯系時，剩餘節點會重新進行leader選舉。問題在於，選舉leader的時間太長，30~120s，而且選舉期間整個zk集群都是不可用的，這就導致在選舉期間注冊服務癱瘓。

在雲部署環境下， 因為網路問題使得zk集群失去master節點是大概率事件，雖然服務能最終恢復，但是漫長的選舉事件導致注冊長期不可用是不能容忍的。

Spring Cloud Netflix 在設計 Eureka 時就緊遵AP原則。Eureka是在Java語言上，基於Restful Api開發的服務注冊與發現組件，由Netflix開源。遺憾的是，目前Eureka僅開源到1.X版本，2.X版本已經宣布閉源。

Eureka Server 也可以運行多個實例來構建集群，解決單點問題，但不同於 ZooKeeper 的選舉 leader 的過程，Eureka Server 採用的是Peer to Peer 對等通信。這是一種去中心化的架構，無 master/slave 之分，每一個 Peer 都是對等的。在這種架構風格中，節點通過彼此互相注冊來提高可用性，每個節點需要添加一個或多個有效的 serviceUrl 指向其他節點。每個節點都可被視為其他節點的副本。

在集群環境中如果某台 Eureka Server 宕機，Eureka Client 的請求會自動切換到新的 Eureka Server 節點上，當宕機的伺服器重新恢復後，Eureka 會再次將其納入到伺服器集群管理之中。當節點開始接受客戶端請求時，所有的操作都會在節點間進行復制（replicate To Peer）操作，將請求復制到該 Eureka Server 當前所知的其它所有節點中。

當一個新的 Eureka Server 節點啟動後，會首先嘗試從鄰近節點獲取所有注冊列表信息，並完成初始化。Eureka Server 通過 getEurekaServiceUrls() 方法獲取所有的節點，並且會通過心跳契約的方式定期更新。

默認情況下，如果 Eureka Server 在一定時間內沒有接收到某個服務實例的心跳（默認周期為30秒），Eureka Server 將會注銷該實例（默認為90秒， eureka.instance.lease-expiration-ration-in-seconds 進行自定義配置）。

當 Eureka Server 節點在短時間內丟失過多的心跳時，那麼這個節點就會進入自我保護模式。

Eureka的集群中，只要有一台Eureka還在，就能保證注冊服務可用（保證可用性），只不過查到的信息可能不是最新的（不保證強一致性）。除此之外，Eureka還有一種自我保護機制，如果在15分鍾內超過85%的節點都沒有正常的心跳，那麼Eureka就認為客戶端與注冊中心出現了網路故障，此時會出現以下幾種情況：

Eureka不再從注冊表中移除因為長時間沒有收到心跳而過期的服務；
Eureka仍然能夠接受新服務注冊和查詢請求，但是不會被同步到其它節點上（即保證當前節點依然可用）；
當網路穩定時，當前實例新注冊的信息會被同步到其它節點中；
因此，Eureka可以很好的應對因網路故障導致部分節點失去聯系的情況，而不會像zookeeper那樣使得整個注冊服務癱瘓。

Consul 是 HashiCorp 公司推出的開源工具，用於實現分布式系統的服務發現與配置。Consul 使用 Go 語言編寫，因此具有天然可移植性（支持Linux、windows和Mac OS X）。
Consul採用主從模式的設計，使得集群的數量可以大規模擴展，集群間通過RPC的方式調用(HTTP和DNS)。

Consul 內置了服務注冊與發現框架、分布一致性協議實現、健康檢查、Key/Value 存儲、多數據中心方案，不再需要依賴其他工具（比如 ZooKeeper 等），使用起來也較為簡單。

Consul 遵循CAP原理中的CP原則，保證了強一致性和分區容錯性，且使用的是Raft演算法，比zookeeper使用的Paxos演算法更加簡單。雖然保證了強一致性，但是可用性就相應下降了，例如服務注冊的時間會稍長一些，因為 Consul 的 raft 協議要求必須過半數的節點都寫入成功才認為注冊成功 ；在leader掛掉了之後，重新選舉出leader之前會導致Consul 服務不可用。

默認依賴於SDK

Consul本質上屬於應用外的注冊方式，但可以通過SDK簡化注冊流程。而服務發現恰好相反，默認依賴於SDK，但可以通過Consul Template（下文會提到）去除SDK依賴。

Consul Template

Consul，默認服務調用者需要依賴Consul SDK來發現服務，這就無法保證對應用的零侵入性。

所幸通過 Consul Template ，可以定時從Consul集群獲取最新的服務提供者列表並刷新LB配置（比如nginx的upstream），這樣對於服務調用者而言，只需要配置一個統一的服務調用地址即可。

Consul強一致性(C)帶來的是：

Eureka保證高可用(A)和最終一致性：

其他方面，eureka就是個servlet程序，跑在servlet容器中; Consul則是go編寫而成。

etcd是一個採用http協議的分布式鍵值對存儲系統，因其易用，簡單。很多系統都採用或支持etcd作為服務發現的一部分，比如kubernetes。但正事因為其只是一個存儲系統，如果想要提供完整的服務發現功能，必須搭配一些第三方的工具。

比如配合etcd、Registrator、confd組合，就能搭建一個非常簡單而強大的服務發現框架。但這種搭建操作就稍微麻煩了點，尤其是相對consul來說。所以etcd大部分場景都是被用來做kv存儲，比如kubernetes。

etcd 比較多的應用場景是用於服務發現，服務發現 (Service Discovery) 要解決的是分布式系統中最常見的問題之一，即在同一個分布式集群中的進程或服務如何才能找到對方並建立連接。和 Zookeeper 類似，etcd 有很多使用場景，包括：
配置管理
服務注冊發現
選主
應用調度
分布式隊列
分布式鎖

按照官網給出的數據， 在 2CPU，1.8G 內存，SSD 磁碟這樣的配置下，單節點的寫性能可以達到 16K QPS, 而先寫後讀也能達到12K QPS。這個性能還是相當可觀。

etcd 提供了 etcdctl 命令行工具 和 HTTP API 兩種交互方法。etcdctl命令行工具用 go 語言編寫，也是對 HTTP API 的封裝，日常使用起來也更容易。所以這里我們主要使用 etcdctl 命令行工具演示。

（1）注冊中心ZooKeeper、Eureka、Consul 、Nacos對比
https://zhuanlan.hu.com/p/165217227?utm_source=wechat_session
（2）常用的服務發現對比（Consul、zookeeper、etcd、eureka）
https://blog.csdn.net/gaohe7091/article/details/101197107

⑩ 位元組三面：到底知不知道什麼是Eureka

什麼是服務注冊？

首先我們來了解下，服務注冊、服務發現和服務注冊中心的之間的關系。

舉個形象的例子，三者之間的關系就好像是供貨商，顧客和商店。

首先各地的供貨商會將各種商品提供給商店，然後顧客需要商品的時候會去商店購買。

注冊中心就好比是這個商店，供貨商的動作就是服務注冊，商品就是注冊的服務。

當部署的服務啟動後，會注冊到注冊中心，消費者需要什麼樣的服務，就自己去注冊中心拉取。

那麼到底什麼是服務注冊，為什麼要將服務注冊到注冊中心呢？

服務注冊指的是服務在啟動時將服務的信息注冊到注冊中心中，由注冊中心統一對所有的注冊的服務進行管理。

現在我們想想，假如你是消費者，你需要買一個商品，你可以去商店，也可以直接去供貨商。

但是如果今天你要買很多商品，而且我們並不知道每個商品對應的供應商的地址，那麼你就得挨家挨戶的去跑供貨商購買商品。

是不是就很麻煩了，倘若此時有一家商店，匯總了多家供貨商的商品，那你是不是只需要去這一家商店就能購買到你需要的所有的商品了呢？

這樣是不是就方便了。

在我們現實開發中，比如我們需要獲取用戶信息的時候，而此時，我們的用戶服務只部署了一個節點，那我們就可以使用IP+埠的形式訪問服務。

當此時我們的服務部署了10個節點後，我們可以通過域名訪問，通過nginx轉發到某一個節點上，訪問該節點的服務。

使用過nginx的小夥伴們都知道，每當我們需要新增一個節點的時候，我們就需要去修改nginx的配置文件，一旦服務部署的節點過多，頻繁修改配置文件就變成了一件極其麻煩的事情。

這個時候，我們的注冊中心，就應該粉墨登場了。

注冊中心一登場，我們就盡管部署服務節點，部署完成後，服務啟動，服務的信息就會被注冊到注冊中心，我們就不需要擔心是不是又要去修改配置文件了。

什麼是服務發現？

服務發現有兩種模式：一種是客戶端發現模式，一種是服務端發現模式。Eureka採用的是客戶端發現模式。

客戶端發現模式就好比我是一個土豪顧客，我去了商店，我把所有的商品都買回家，需要的時候在這些商品裡面尋找。

因為我是土豪，所以我當然不能忍受商店裡有新品上架，而我卻沒有，所以我每隔一段時間就會商店增量獲取最新的商品。

這就是Eureka中的Fetch Registry，抓取注冊信息。

Eureka Client 從 Eureka Server 獲取注冊表信息並在本地緩存。

這里我們注意一下，Eureka Client並不是直接去服務注冊表中獲取數據，而是從ReadOnly緩存中獲取數據。

並且會通過在上一個獲取周期和當前獲取周期之間獲取增量更新，這些信息會定期更新(每30秒更新一次)。

獲取的時候可能返回相同的實例。Eureka Client會自動處理重復信息。

因為我的土豪行為，我已經被商店老闆記錄在它的VVIP名單上了。可惜天有不測風雲，我破產了，我再也不能這么土豪了，沒辦法，我告訴了老闆我破產了，老闆聽了我的話，想都沒想，直接從他的VVIP名單上將我的名字給剔除了，社會就是這么現實。

這就是Eureka中的Cancel，取消。

每一個微服務節點關閉時，Eureka Client會向Eureka Server發送一個取消請求。

Eureka Server收到你的取消請求後，就會將你從服務注冊表中給剔除。

商店老闆是個傲嬌的人，她制定了一個規則，如果你是她VVIP名單上的人，你必須每隔一段時間就要去商店采購商品。

一旦你在一段時間內沒有來采購，她就覺得你已經沒有購買能力，不適合在她的VVIP名單上存在了。

她就會狠心的將你從她的VVIP名單上將我的名字給剔除了。

這就是Eureka中的Renew（更新 / 續借）

Eureka Client 內部具備一個內置的負載均衡器，它使用輪訓（round-robin）負載演算法。

在服務啟動後，每隔一定周期（默認30秒）向Eureka Server發送心跳。

如果Eureka Server在多個心跳周期內（默認90秒）沒有收到Eureka Client發送過來的心跳，Eureka Server將會在服務注冊表中將該節點剔除。

當然了，服務發現去注冊中心拉取的是服務的信息，然後需要從服務信息中獲取到服務部署的節點信息，然後通過域名地址訪問到該節點的服務。

就好像一家商店，因為空間太小，只是存放了一些商品的微縮模型，模型上寫著該商品所屬的供貨商地址，我們去商店拿到該模型後，看到供貨商的地址，然後我們就可以直接去供貨商那兒直接購買商品了。

什麼是注冊中心，注冊中心的作用？

注冊中心就是一個管理器，各個服務提供者將服務注冊到注冊中心，由注冊中心進行統一的存儲和管理。

注冊中心同時還有著判斷服務是否可用，對於不可用的服務進行剔除的功能。

至於如何判斷服務的可用性和如何剔除不可用的服務，後續會有詳細的講解。

什麼是 Eureka，有什麼作用？

Eureka採用CS架構，它分為兩大組件。

一個是Eureka Server,注冊中心服務端。

當各個微服務節點啟動後，Eureka Server 會存儲服務提供者注冊上來的服務信息，並且提供二層緩存機制來維護整個注冊中心。

另一個是Eureka Client，注冊中心客戶端。

Eureka Client是一個java客戶端，它用來簡化和Eureka Server交互。

Eureka Client 會拉取、更新和緩存 Eureka Server 中的信息。

因此當所有的 Eureka Server 節點都宕掉，服務消費者依然可以使用緩存中的信息找到服務提供者，但是當服務有更改的時候會出現信息不一致。

Eureka 架構詳解

如下圖所示，這是官網提供給我們的Eureka的架構圖Eureka 的架構，主要分為 Eureka Server 和 Eureka Client 兩部分，Eureka Client 又分為 Applicaton Service 和 Application Client，Applicaton Service 就是服務提供者，Application Client 就是服務消費者。

我們首先會在應用程序中依賴 Eureka Client，項目啟動後 Eureka Client 會向 Eureka Server 發送請求，進行注冊，並將自己的一些信息發送給 Eureka Server。

注冊成功後，每隔一定的時間，Eureka Client 會向 Eureka Server 發送心跳來續約服務，也就是匯報健康狀態。如果客戶端長時間沒有續約，那麼 Eureka Server 大約將在 90 秒內從伺服器注冊表中刪除客戶端的信息。

Eureka Client 還會定期從 Eureka Server 拉取注冊表信息，然後根據負載均衡演算法得到一個目標，並發起遠程調用，關於負載均衡在後面的課時會詳細介紹，也就是 Ribbon 組件。

應用停止時也會通知 Eureka Server 移除相關信息，信息成功移除後，對應的客戶端會更新服務的信息，這樣就不會調用已經下線的服務了，當然這個會有延遲，有可能會調用到已經失效的服務，所以在客戶端會開啟失敗重試功能來避免這個問題。

Eureka Server 會有多個節點組成一個集群，保證高可用。Eureka Server 沒有集成其他第三方存儲，而是存儲在內存中。

所以 Eureka Server 之間會將注冊信息復制到集群中的 Eureka Server 的所有節點。

這樣數據才是共享狀態，任何的 Eureka Client 都可以在任何一個 Eureka Server 節點查找注冊表信息。

Eureka 的工作流程

Eureka 的自我保護機制

什麼是自我保護機制

官方定義：自我保護模式正是一種針對網路異常波動時的安全保護措施，使用自我保護模式能使Eureka集群更加健壯穩定的運行。

為什麼要開啟自我保護機制？

如果Eureka Server在一定時間內（默認90s）（可優化）沒有收到某一個服務節點的心跳，Eureka Server將會移除該服務實例。

但是在某些時候，遇到網路分區故障，服務節點實際上是正常存活狀態，但是卻無法和Eureka Server正常通信，此時如果沒有引入自我保護機制，Eureka Server就會將該服務節點剔除。

自我保護模式的工作機制

如果15分鍾內超過85%的客戶端節點都沒有正常的心跳，那麼Eureka Server就會認為客戶端與注冊中心發生了網路故障，Eureka Server進入自我保護機制。

自我保護機制的缺點

如果在自我保護機制中，剛好某些服務節點非正常下線，但是Eureka Server並不會剔除該服務節點，服務消費者就會獲取到一個無效的服務實例。

解決方案

① ：關閉自我保護機制(不推薦)

② ：切換請求或斷路器，使用負載均衡的方式，設置當一個請求超過多少秒還未得到響應，速度切換請求到下一個注冊服務，例如使用Ribbon+Hystrix配置負載均衡和斷路器。

Eureka Server 進入自我保護機制後

1、Eureka Server不再從注冊表中剔除因為長時間沒有和注冊中心續約的服務節點

2、Eureka Server仍然能夠接受新服務的注冊和查詢請求，但是不會同步到其他Eureka Server節點上

3、網路正常後，當前Eureka Server節點會將新的服務節點信息同步到其他Eureka Server節點上

如何開啟自我保護

通過
eureka.server.enable-self-preservation=true/false來開啟或關閉自我保護機制。

其他關鍵配置：

清理失效服務節點的時間間隔：
eureka.server.evication-interval-timer-in-ms默認60s

續約間隔時間：
eureka.instance.lease-renewal-interval-in-seconds默認30s

續約到期時間：
eureka.instance.lease-expiration-ration-in-seconds默認90s

通過源碼窺探Eureka是如何開啟自我保護機制的

第一步，我們引入Eureka Server 依賴。

第二步，我們找到eureka-core jar包下的路徑為com.netflix.eureka下的registry包

第三步，進入AbstractInstanceRegistry 類，找到evict方法，這個是定期剔除任務的線程最終執行的方法

第四步，我們找到isLeaseExpirationEnabled()方法的實現

第五步，我們注意到
numberOfRenewsPerMinThreshold這個變數很關鍵，它的含義是每分鍾最小的續約次數

在服務注冊register和服務下線cancel兩個方法中會更新這個變數，更新該變數方法如下：

以上就是Eureka開啟自我保護的整個邏輯流程。

解除自我保護機制

1.當服務的網路分區故障解除之後，客戶端能夠和服務進行交互時，在續約的時候，更新每分鍾的續約數，當每分鍾的續約數大於85%時，則自動解除。

2.重啟服務

Eureka 的健康檢查

其實很多框架的健康狀態監控都是通過 actuator 來管理健康狀態的，並且擴展了 health 端點。

所以說我們只要在項目中集成Actuator，我們就能管理監控項目的健康狀態。

Eureka也是一樣，我們可以將某些不健康的服務節點的狀態告知Eureka Server，然後Eureka Server 會主動讓其下線。

這個就是Eureka的健康檢查。

如何實現Eureka-Actuator健康檢查？

首先我們要在pom中依賴
spring-boot-starter-actuator。

第二步，配置文件中添加
eureka.client.healthcheck.enabled=true 配置

原理分析：

首先在 中根據 eureka.client.healthcheck.enabled 的值來決定是否要裝配 EurekaHealthCheckHandler ，然後在 EurekaClientAutoConfiguration 中會注冊 HealthCheck ，但我們注冊完成後會有調用任務來進行狀態的更新，在 com.netflix.discovery.InstanceInfoReplicator.run() 中會進行狀態更新。

Eureka 的多級緩存機制

什麼是多級緩存機制

Eureka Server 為了避免同時讀取內存數據造成的並發沖突問題，採用了多級緩存機制提升服務請求的響應速度。

Eureka Server的緩存是通過一個只讀，一個讀寫緩存來實現的。

一級緩存：concurrentHashMap<key,value>readOnlyCacheMap本質是HashMap，無過期時間，保存數據信息對外輸出。

readOnlyCacheMap依賴於定時器的更新，通過與readWriteCacheMap的值做對比，以readWriteCacheMap為准。

responseCacheUpdateIntervalMs：readOnlyCacheMap緩存更新間隔，默認30s

二級緩存：LoaDing<key,value>readWriteCacheMap本質是Guava緩存，包含失效機制，保護數據信息對外輸出。

：readWriteCacheMap 緩存過期時間，默認180s。

當服務節點發生注冊，下線，過期，狀態變更等變化時

1.在內存中更新注冊表信息

2.同時過期掉readWriteCacheMap緩存，緩存清除只是會去清除readWriteCacheMap這個緩存， readOnlyCacheMap 只讀 緩存並沒有更新，也就說當客戶端的信息發生變化之後， 只讀緩存不是第一時間感知到的。只讀緩存的更新只能依賴那個30秒的定時任務來更新。

3.一段時間後（默認30s），後台線程發現readWriteCacheMap緩存為空，於是也將readOnlyCacheMap中的緩存清空

4.當有服務消費者拉取注冊表信息時，會調用ClassLoader的load方法，將內存中的注冊表信息載入到各級緩存中，並返回注冊表信息。

在Eureka Server 中會有兩個線程，一個是定時同步兩個緩存的數據，默認30s，一個是定時檢測心跳故障，默認90s。

服務拉取

1.服務消費者，默認每30s，拉取注冊表信息

2.從readOnlyCacheMap中獲取信息，如果獲取為空

3.從readWriteCacheMap中獲取，如果還是為空

4.調用ClassLoader的load方法，將內存中的注冊表信息載入到各級緩存中，並返回注冊表信息。

Eureka的區域配置

當用戶地理分布范圍很廣的時候，比如公司在上海、杭州、青島等都有分公司的時候，一般都會有多個機房。

那麼對於用戶而言，當然是希望調用本地分公司的機房中的微服務應用。

比如：上海用戶A，調用OAuth2服務，用戶A當然希望調用上海機房裡面的微服務應用。如果上海用戶A調用杭州機房的OAuth2服務，就增加的延時時間。

所以我們希望一個機房內的服務優先調用同一個機房內的服務，當同一個機房的服務不可用的時候，再去調用其它機房的服務，以達到減少延時的作用。

為此，eureka提供了region和zone兩個概念來進行分區，Eureka基於Amazon設計的，所以對於地域的區分也與Amazon一致，Amazon分為多個region，每個region包含多個zone，所以Eureka設計時也是可以設置region與zone，請求時可以優先選擇與請求服務在同一個zone的服務。

基本配置

此時無論我們調用多少次，調用的都是shanghai下面的zone1下面的服務。

一般來說我們都會結合Ribbon來實現微服務的負載均衡，而Ribbon內部會有一些專門的負載策略演算法，雖然剛剛我們說過會優先請求的是指定region下指定 Zone 區域的服務實例。

但有些時候比如當在Region=shanghai下沒有可用的zone，系統會默認載入 DEFAULT_ZONE，或者說或者同區域的服務負載過高...等等，也會自動切換成其他區域的服務。

Eureka的重試機制

由於 Spring Cloud Eureka 實現的服務治理機制強調了 CAP 原理中的 AP，即可用性與可靠性，犧牲了一定的一致性（在極端情況下它寧願接受故障實例也不要丟掉"健康"實例，如同如我們上面所說的自我保護機制）。

但不論是由於觸發了保護機制還是服務剔除的延遲，引起服務調用到這些不正常的服務，調用就會失敗，從而導致其它服務不能正常工作！

這顯然不是我們願意看到的，我們還是希望能夠增強對這類問題的容錯。所以，我們在實現服務調用的時候通常會加入一些重試機制。

從 Camden SR2 版本開始，Spring Cloud 就整合了 Spring Retry 來增強 RestTemplate 的重試能力，對於開發者來說只需通過簡單的配置，原來那些通過 RestTemplate 實現的服務訪問就會自動根據配置來實現重試策略。

開啟Eureka的重試機制很簡單，首先我們在pom中引入Spring Retry的依賴：

然後在配置文件中配置
spring.cloud.loadbalancer.retry.enabled參數來控制重試機制的開關，因為 Spring Retry默認是開啟的，所以說我們只要引入依賴即可，如果說我們想要關閉的話只需要將 spring.cloud.loadbalancer.retry.enabled設置為false即可。

其實在SpringCloud的架構組件中無論是Fegin，Ribbon，還是Zuul都提供了重試機制，這些暫且不論，後續再講到具體的組件時再進行具體的分析。

實戰 Eureka 注冊中心的部署

Eureka Server 項目搭建

1、創建一個 springcloud-eureka-server 的項目，然後在 pom 中增加
spring-cloud-starter-netflix-eureka-server 的依賴。

2.在pom.xml文件中新增
spring-cloud-starter-netflix-eureka-server依賴

3.在啟動類
上使用 @EnableEurekaServer 開啟 EurekaServer 的自動裝配功能。

4.添加配置文件application.properties

5.啟動項目，然後訪問 http://localhost:8761/ ,可以看到 Eureka 的管理頁面，表示 Eureka 啟動成功了。

1、創建一個 springcloud-eureka-client 的項目，然後在 pom 中增加
spring-cloud-starter-netflix-eureka-client 的依賴。

2.在啟動類
上使用 @EnableEurekaClient 開啟 EurekaServer 的自動裝配功能。

配置
eureka.client.serviceUrl.defaultZone 的地址，也就是剛剛啟動的 Eureka Server 的地址， http://localhost:8761/eureka/ 。

啟動客戶端，然後刷新剛剛打開的Eureka主頁，我們發現服務已經注冊成功。

Eureka 注冊中心添加密碼認證

上面我們看到我們搭建好Eureka Server 後訪問 http://localhost:8761/ ,沒有登陸就可以直接看到 Eureka 的管理頁面。

如果在實際使用中，注冊中心地址有公網 IP 的話，必然能直接訪問到，這樣是不安全的。所以我們需要對 Eureka 進行改造，通過集成 Spring-Security 來進行安全認證，加上許可權認證來保證安全性。

首先，在 pom.xml 中引入 Spring-Security 的依賴

然後在 application.properties 中加上認證的配置信息

最後增加Spring Security 配置類

這樣我們啟動Eureka Server成功後在訪問 http://localhost:8761/ ，此時瀏覽器會提示你輸入用戶名和密碼，輸入正確後才能繼續訪問 Eureka 提供的管理頁面。

總結

本章我們主要學習了Eureka相關知識，雖然Eureka已經停更了，但是很多公司還在使用它，而它也足夠穩定，它所提供的功能也足夠大多數公司使用。所以說現在面試中，Eureka相關題目還是經常出現的。反正學到了就是自己的。

祝願大家早日成為大牛，有一頭烏黑秀發的大牛。