微服務(wù)模式-注冊中心詳解

隨著微服務(wù)理論發(fā)展的成熟秦忿，越來越多互聯(lián)網(wǎng)公司采用微服務(wù)架構(gòu)來支持業(yè)務(wù)發(fā)展弟疆。然而不同公司又有各自的實現(xiàn)方式捶惜，本文主要是講解注冊中心原理和實際開發(fā)中的應(yīng)用。

一晋被、原理和功能

? ? ?注冊中心是隱藏在服務(wù)框架背后最基礎(chǔ)的服務(wù)兑徘，記錄各個服務(wù)的實例信息，決定業(yè)務(wù)服務(wù)是否正常調(diào)用

1.1 注冊中心原理

? ? ?注冊中心主要涉及到三大角色：注冊中心羡洛、服務(wù)提供者挂脑、服務(wù)消費者

三者關(guān)系流程描述如下：

? ? 1、各微服務(wù)啟動時翘县，將自己的實例信息(ip最域、端口、服務(wù)名等)注冊到注冊中心锈麸，注冊中心存儲這些數(shù)據(jù)

? ? 2、服務(wù)消費者從注冊中心獲取到服務(wù)提供者的實例信息牺蹄，通過ip + 端口方式遠程調(diào)用服務(wù)提供者的接口

? ?3忘伞、各個微服務(wù)通過心跳來上報注冊中心，注冊中心以某個時間段有沒有接收到上報信息沙兰，來決定是否下線某服務(wù)實例

? 4氓奈、微服務(wù)發(fā)生變動時如增加實例或 ip變動，重新注冊信息到注冊中心鼎天。這樣舀奶，服務(wù)消費者就無需改動，直接從注冊中心獲取最新信息即可

三者關(guān)系圖如下：

1.2 注冊中心功能

1斋射、服務(wù)注冊表

服務(wù)注冊表是注冊中心的核心育勺，它用來記錄各個微服務(wù)實例的信息，例如微服務(wù)的名稱罗岖、IP涧至、端口等。服務(wù)注冊表提供查詢API和管理API桑包，查詢API用于查詢可用的微服務(wù)實例南蓬，管理API用于服務(wù)的注冊與注銷。

2、服務(wù)注冊與發(fā)現(xiàn)

服務(wù)注冊是指微服務(wù)在啟動時赘方，將自己的信息注冊到注冊中心的過程烧颖。

服務(wù)發(fā)現(xiàn)是指查詢可用的微服務(wù)列表及網(wǎng)絡(luò)地址的機制。

3窄陡、服務(wù)檢查

注冊中心使用一定的機制定時檢測已注冊的服務(wù)倒信，如發(fā)現(xiàn)某實例長時間無法訪問，就會從服務(wù)注冊表移除該實例泳梆。

二鳖悠、主流選用組件

一個服務(wù)的提供者數(shù)量和分布是基于業(yè)務(wù)發(fā)展是動態(tài)變化的，注冊中心需要支持彈性擴容优妙，而這也體現(xiàn)了微服務(wù)的分布式屬性乘综。主流技術(shù)方向選用組件時，主要有?Eureka套硼、Consul卡辰、ZooKeeper和Nacos這幾種。這幾種開源組件都是基于分布式理論 CAP 的 CP 邪意、AP 來實現(xiàn)的九妈。

2.1 CAP理論

CAP理論是分布式架構(gòu)實現(xiàn)中重要的理論

一致性(Consistency) : 所有節(jié)點在同一時間具有相同的數(shù)據(jù)

可用性(Availability) : 保證每個請求不管成功或者失敗都有響應(yīng)

分區(qū)容錯(Partition tolerance) : 系統(tǒng)中任意信息的丟失或失敗不會影響系統(tǒng)的繼續(xù)運作

基于網(wǎng)絡(luò)的不穩(wěn)定性，分區(qū)容錯是不可避免的雾鬼，所以我們默認CAP中的P總是成立的萌朱。所以在此基礎(chǔ)上，開源組件實現(xiàn)時一般選擇一致性（C）或可用性（A）策菜。

2.2 Eurake --> AP

Eurake是Netflix公司提供開源的晶疼，由Java語言開發(fā)，基于Restful Api風格實現(xiàn)的服務(wù)注冊和服務(wù)發(fā)現(xiàn)又憨。不過 Netflix只開源到1.X版本翠霍，2.X版本已經(jīng)關(guān)閉，不開放了蠢莺。

Eureka 采用的是Server/Client的模式進行設(shè)計的寒匙。

Server是服務(wù)注冊中心的角色，為Client提供服務(wù)的注冊與發(fā)現(xiàn)功能躏将，維護著注冊到自身的Client的相關(guān)信息锄弱，同時提供接口給Client獲取到注冊表中的所有服務(wù)的信息。

Client將有關(guān)自己的服務(wù)的信息通過一定的方式登記在Server上耸携，并在正常范圍內(nèi)維護自己信息的一致性棵癣，方便其他服務(wù)發(fā)現(xiàn)自己，同時可以通過Server獲取到自己的依賴的其他服務(wù)信息夺衍，從而完成服務(wù)調(diào)用狈谊。

官網(wǎng)架構(gòu)圖:

Eurake架構(gòu)

Application Service：作為Eureka Client，扮演了服務(wù)的提供者，提供業(yè)務(wù)服務(wù)河劝，向Eureka Server注冊和更新自己的信息壁榕，同時能從Eureka Server的注冊表中獲取到其他服務(wù)的信息。

Eureka Server：扮演服務(wù)注冊中心的角色赎瞎，提供服務(wù)注冊和發(fā)現(xiàn)的功能牌里，每個Eureka Cient向Eureka Server注冊自己的信息，也可以通過Eureka Server獲取到其他服務(wù)的信息達到發(fā)現(xiàn)和調(diào)用其他服務(wù)的目的务甥。

Application Client：作為Eureka Client牡辽，扮演了服務(wù)消費者，通過Eureka Server獲取到注冊到上面的其他服務(wù)的信息敞临，從而根據(jù)信息找到所需的服務(wù)發(fā)起遠程調(diào)用态辛。

Replicate： Eureka Server中的注冊表信息的同步拷貝，保持不同的Eureka Server集群中的注冊表中的服務(wù)實例信息的一致性挺尿。提供了數(shù)據(jù)的最終一致性奏黑。

Make Remote Call：服務(wù)之間的遠程調(diào)用。

Renew：續(xù)約，通過發(fā)送心跳到Server維持和更新注冊表中的服務(wù)實例元數(shù)據(jù)的有效性窄俏。當在一定時長內(nèi)Server沒有收到Client的心跳信息蹂匹，將默認服務(wù)下線，將服務(wù)實例的信息從注冊表中刪除裆操。

Cancel：服務(wù)下線怒详，Client在關(guān)閉時主動向Server注銷服務(wù)實例元數(shù)據(jù)，這時Client的的服務(wù)實例數(shù)據(jù)將從Server的注冊表中刪除踪区。

Eurake 沒有使用強一致性哈希算法來實現(xiàn)不同集群之間的數(shù)據(jù)一致性，而是采用數(shù)據(jù)拷貝的方式爭取注冊中心數(shù)據(jù)的最終一致性吊骤。丟失了強一致性缎岗，提高了服務(wù)的可用性，提高了集群的健壯性白粉。

2.3 Consul --> CP

Consul是由HashiCorp基于Go語言開發(fā)的支持多數(shù)據(jù)中心分布式高可用的服務(wù)發(fā)布和注冊服務(wù)軟件传泊，采用Raft算法保證服務(wù)的一致性，且支持健康檢查鸭巴。

采用主從模式的設(shè)計眷细，可以大規(guī)模的部署集群數(shù)據(jù)量，集群通過RPC方式來調(diào)用鹃祖。

官網(wǎng)架構(gòu)圖:

Consul架構(gòu)

Client：作為一個代理(非微服務(wù)實例)溪椎，它將轉(zhuǎn)發(fā)所有的RPC請求到Server中。作為相對無狀態(tài)的服務(wù)，它不持有任何注冊信息校读。

Server：作為一個具備擴展功能的代理沼侣，它將響應(yīng)RPC查詢、參與Raft選舉歉秫、維護集群狀態(tài)和轉(zhuǎn)發(fā)查詢給Leader等

Leader-Server：一個數(shù)據(jù)中心的所有Server都作為Raft節(jié)點集合的一部分蛾洛。其中Leader將負責所有的查詢和事務(wù)(如服務(wù)注冊)，同時這些事務(wù)也會被復(fù)制到所有其他的節(jié)點

Data Center：數(shù)據(jù)中心作為一個私有的雁芙，低延遲和高帶寬的一個網(wǎng)絡(luò)環(huán)境轧膘。每個數(shù)據(jù)中心會存在Consul集群，一般建議Server是3-5臺(考慮到Raft算法在可用性和性能上取舍)兔甘，而Leader只能唯一谎碍，Client的數(shù)量沒有限制，可以輕松擴展裂明。

Raft算法

Raft算法將Server分為三種類型：Leader椿浓、Follower和Candidate。

Leader處理所有的查詢和事務(wù)闽晦，并向Follower同步事務(wù)扳碍。Follower會將所有的RPC查詢和事務(wù)轉(zhuǎn)發(fā)給Leader處理，它僅從Leader接受事務(wù)的同步仙蛉。數(shù)據(jù)的一致性以Leader中的數(shù)據(jù)為準實現(xiàn)笋敞。

在節(jié)點初始啟動時，節(jié)點的Raft狀態(tài)機將處于Follower狀態(tài)等待來來自Leader節(jié)點的心跳荠瘪。如果在一定時間周期內(nèi)沒有收到Leader節(jié)點的心跳夯巷，節(jié)點將發(fā)起選舉。

Follower節(jié)點選舉時會將自己的狀態(tài)切換為Candidate哀墓，然后向集群中其它Follower節(jié)點發(fā)送請求趁餐，詢問其是否選舉自己成為Leader。當收到來自集群中過半數(shù)節(jié)點的接受投票后篮绰，節(jié)點即成為Leader后雷，開始接收Client的事務(wù)處理和查詢并向其它的Follower節(jié)點同步事務(wù)。Leader節(jié)點會定時向Follower發(fā)送心跳來保持其地位吠各。

Gossip協(xié)議

Gossip協(xié)議是為了解決分布式環(huán)境下監(jiān)控和事件通知的瓶頸臀突。Gossip協(xié)議中的每個Agent會利用Gossip協(xié)議互相檢查在線狀態(tài)，分擔了服務(wù)器節(jié)點的心跳壓力贾漏，通過Gossip廣播的方式發(fā)送消息候学。

所有的Agent都運行著Gossip協(xié)議。服務(wù)器節(jié)點和普通Agent都會加入這個Gossip集群纵散，收發(fā)Gossip消息梳码。每隔一段時間隐圾，每個節(jié)點都會隨機選擇幾個節(jié)點發(fā)送Gossip消息，其他節(jié)點會再次隨機選擇其他幾個節(jié)點接力發(fā)送消息边翁。這樣一段時間過后翎承，整個集群都能收到這條消息。

基于Raft算法符匾，Consul提供強一致性的注冊中心服務(wù)叨咖，但是由于Leader節(jié)點承擔了所有的處理工作，勢必加大了注冊和發(fā)現(xiàn)的代價啊胶，降低了服務(wù)的可用性甸各。通過Gossip協(xié)議，Consul可以很好地監(jiān)控Consul集群的運行焰坪，同時可以方便通知各類事件趣倾，如Leader選擇發(fā)生、Server地址變更等某饰。

Consul雖然保證了強一致性儒恋，但是服務(wù)可用性就相應(yīng)下降了。

如服務(wù)注冊的時間稍長黔漂，因為 Consul 的 raft 協(xié)議要求必須過半數(shù)的節(jié)點都寫入成功才認為注冊成功诫尽；

如leader掛掉了之后，重新選舉出leader之前會導(dǎo)致Consul 服務(wù)不可用

2.4 Zookeeper --> CP

Zookeeper 是Google開源的在Java語言上實現(xiàn)的分布式協(xié)調(diào)服務(wù)炬守，是Hadoop和Hbase的重要組件牧嫉，提供了數(shù)據(jù)/發(fā)布訂閱、負載均衡减途、分布式同步等功能酣藻。Zookeeper 也是主從設(shè)計架構(gòu)，搭建高可擴展的服務(wù)集群鳍置。

官網(wǎng)架構(gòu)圖：

Zookeeper架構(gòu)

Leader-Server：Leader負責進行投票的發(fā)起和決議辽剧，更新系統(tǒng)中的數(shù)據(jù)狀態(tài)

Server：Server中存在兩種類型：Follower和Observer；其中Follower接受客戶端的請求并返回結(jié)果(事務(wù)請求將轉(zhuǎn)發(fā)給Leader處理)税产，并在選舉過程中參與投票抖仅；Observer與Follower功能一致，但是不參與投票過程砖第，它的存在是為了提高系統(tǒng)的讀取速度

Client：請求發(fā)起方，Server和Client之間可以通過長連接的方式進行交互环凿。如發(fā)起注冊或者請求集群信息等梧兼。

Zab協(xié)議

ZooKeeper Atomic Broadcast protocol是專門設(shè)計給Zookeeper用于實現(xiàn)分布式系統(tǒng)數(shù)據(jù)的一致性，是在Paxos算法基礎(chǔ)上發(fā)展而來智听。它使用了單一的Leader來接受和處理客戶端的所有事務(wù)請求羽杰，并將服務(wù)器數(shù)據(jù)的狀態(tài)變更以事務(wù)Proposal的形式廣播到所有的Server中渡紫。同時它保證Leader出現(xiàn)異常時，集群依舊能夠正常工作考赛。

Zab包含兩種基本模式：崩潰恢復(fù)和消息廣播惕澎。

崩潰恢復(fù)：Leader服務(wù)器出現(xiàn)宕機，或者因為網(wǎng)絡(luò)原因?qū)е翷eader服務(wù)器失去了與過半 Follower的聯(lián)系颜骤，那么就會進入崩潰恢復(fù)模式從而選舉新的Leader唧喉。Leader選舉算法不僅僅需要讓Leader自己知道其自身已經(jīng)被選舉為Leader，同時還需要讓集群中的所有其他服務(wù)器也能夠快速地感知到選舉產(chǎn)生的新的Leader忍抽。當選舉產(chǎn)生了新的Leader八孝，同時集群中有過半的服務(wù)器與該Leader完成了狀態(tài)同步之后，Zab協(xié)議就會退出崩潰恢復(fù)模式鸠项，進入消息廣播模式干跛。

消息廣播：Zab協(xié)議的消息廣播過程類似二階段提供過程，是一種原子廣播的協(xié)議祟绊。當接受到來自Client的事務(wù)請求(如服務(wù)注冊)(所有的事務(wù)請求都會轉(zhuǎn)發(fā)給Leader)楼入，Leader會為事務(wù)生成對應(yīng)的Proposal，并為其分配一個全局唯一的ZXID牧抽。Leader服務(wù)器與每個Follower之間都有一個單獨的隊列進行收發(fā)消息嘉熊，Leader將生成的Proposal發(fā)送到隊列中。Follower從隊列中取出Proposal進行事務(wù)消費阎姥，消費完畢后發(fā)送一個ACK給Leader记舆。當Leader接受到半數(shù)以上的Follower發(fā)送的ACK投票，它將發(fā)送Commit給所有Follower通知其對事務(wù)進行提交呼巴，Leader本身也會提交事務(wù)泽腮，并返回給處理成功給對應(yīng)的客戶端。Follower只有將隊列中Proposal都同步消費后才可用衣赶。

基于Zab協(xié)議诊赊，Zookeeper可以用于構(gòu)建具備數(shù)據(jù)強一致性的服務(wù)注冊與發(fā)現(xiàn)中心，而與此相對地犧牲了服務(wù)的可用性和提高了注冊需要的時間府瞄。