1、前言

2、為什么需要注冊(cè)中心？

3、如何實(shí)現(xiàn)一個(gè)注冊(cè)中心？

4、如何解決負(fù)載均衡的問(wèn)題？

5、注冊(cè)中心如何選型？

1、Zookeeper

2、Eureka

3、Nacos

4、Consul

5、Kubernetes

6、總結(jié)

1、高可用

2、關(guān)于CP還是AP的選擇

3、技術(shù)體系

4、產(chǎn)品的活躍度

1、前言

微服務(wù)的注冊(cè)中心目前主流的有以下五種：

Zookeeper

Eureka

Consul

Nacos

Kubernetes

那么實(shí)際開(kāi)發(fā)中到底如何選擇呢？這是一個(gè)值得深入研究的事情，別著急，今天陳某就帶大家深入了解一下這五種注冊(cè)中心以及如何選型的問(wèn)題。

基于 Spring Boot + MyBatis Plus + Vue & Element 實(shí)現(xiàn)的后臺(tái)管理系統(tǒng) + 用戶(hù)小程序，支持 RBAC 動(dòng)態(tài)權(quán)限、多租戶(hù)、數(shù)據(jù)權(quán)限、工作流、三方登錄、支付、短信、商城等功能

項(xiàng)目地址：https://github.com/YunaiV/ruoyi-vue-pro

視頻教程：https://doc.iocoder.cn/video/

2、為什么需要注冊(cè)中心？

隨著單體應(yīng)用拆分，首當(dāng)面臨的第一份挑戰(zhàn)就是服務(wù)實(shí)例的數(shù)量較多，并且服務(wù)自身對(duì)外暴露的訪問(wèn)地址也具有動(dòng)態(tài)性?？赡芤?yàn)榉?wù)擴(kuò)容、服務(wù)的失敗和更新等因素，導(dǎo)致服務(wù)實(shí)例的運(yùn)行時(shí)狀態(tài)經(jīng)常變化，如下圖:

商品詳情需要調(diào)用營(yíng)銷(xiāo) 、訂單 、庫(kù)存 三個(gè)服務(wù)，存在問(wèn)題有：

營(yíng)銷(xiāo)、訂單、庫(kù)存這三個(gè)服務(wù)的地址都可能動(dòng)態(tài)的發(fā)生改變，單存只使用配置的形式需要頻繁的變更，如果是寫(xiě)到配置文件里面還需要重啟系統(tǒng) ，這對(duì)生產(chǎn)來(lái)說(shuō)太不友好了;

服務(wù)是集群部署的形式調(diào)用方負(fù)載均衡如何去實(shí)現(xiàn)；

解決第一個(gè)問(wèn)題辦法就是用我們用偉人說(shuō)過(guò)一句話(huà)，沒(méi)有什么是加一個(gè)中間層解決不了的 ，這個(gè)中間層就是我們的注冊(cè)中心。

解決第二問(wèn)題就是關(guān)于負(fù)載均衡的實(shí)現(xiàn)，這個(gè)需要結(jié)合我們中間層老大哥來(lái)實(shí)現(xiàn)。

基于 Spring Cloud Alibaba + Gateway + Nacos + RocketMQ + Vue & Element 實(shí)現(xiàn)的后臺(tái)管理系統(tǒng) + 用戶(hù)小程序，支持 RBAC 動(dòng)態(tài)權(quán)限、多租戶(hù)、數(shù)據(jù)權(quán)限、工作流、三方登錄、支付、短信、商城等功能

項(xiàng)目地址：https://github.com/YunaiV/yudao-cloud

視頻教程：https://doc.iocoder.cn/video/

3、如何實(shí)現(xiàn)一個(gè)注冊(cè)中心？

對(duì)于如何實(shí)現(xiàn)注冊(cè)中心這個(gè)問(wèn)題，首先將服務(wù)之間是如何交互的模型抽象出來(lái)，我們結(jié)合實(shí)際的案例來(lái)說(shuō)明這個(gè)問(wèn)題，以商品服務(wù)為例：

當(dāng)我們搜索商品的時(shí)候商品服務(wù)就是提供者；

當(dāng)我們查詢(xún)商品詳情的時(shí)候即服務(wù)的提供者又是服務(wù)的消費(fèi)者，消費(fèi)是訂單、庫(kù)存等服務(wù)；由此我們需要引入的三個(gè)角色就是:中間層(注冊(cè)中心)、生產(chǎn)者、消費(fèi)者，如下圖:

整體的執(zhí)行流程如下:

在服務(wù)啟動(dòng)時(shí)，服務(wù)提供者通過(guò)內(nèi)部的注冊(cè)中心客戶(hù)端應(yīng)用自動(dòng)將自身服務(wù)注冊(cè)到注冊(cè)中心，包含主機(jī)地址、服務(wù)名稱(chēng)等等信息；

在服務(wù)啟動(dòng)或者發(fā)生變更的時(shí)候，服務(wù)消費(fèi)者的注冊(cè)中心客戶(hù)端程序則可以從注冊(cè)中心中獲取那些已經(jīng)注冊(cè)的服務(wù)實(shí)例信息或者移除已下線的服務(wù)；

上圖還多一個(gè)設(shè)計(jì)緩存本地路由，緩存本地路由是為了提高服務(wù)路由的效率 和容錯(cuò)性 ，服務(wù)消費(fèi)者可以配備緩存機(jī)制以加速服務(wù)路由。更重要的是，當(dāng)服務(wù)注冊(cè)中心不可用時(shí)，服務(wù)消費(fèi)者可以利用本地緩存路由實(shí)現(xiàn)對(duì)現(xiàn)有服務(wù)的可靠調(diào)用。

在整個(gè)執(zhí)行的過(guò)程中，其中有點(diǎn)有一點(diǎn)是比較難的，就是服務(wù)消費(fèi)者如何及時(shí)知道服務(wù)的生產(chǎn)者如何及時(shí)變更的，這個(gè)問(wèn)題也是經(jīng)典的生產(chǎn)者消費(fèi)者的問(wèn)題，解決的方式有兩種:

發(fā)布-訂閱模式 ：服務(wù)消費(fèi)者能夠?qū)崟r(shí)監(jiān)控服務(wù)更新?tīng)顟B(tài)，通常采用監(jiān)聽(tīng)器以及回調(diào)機(jī)制，經(jīng)典的案例就是Zookeeper ；

主動(dòng)拉取策略 ：服務(wù)的消費(fèi)者定期調(diào)用注冊(cè)中心提供的服務(wù)獲取接口獲取最新的服務(wù)列表并更新本地緩存,經(jīng)典案例就是Eureka ；

對(duì)于如何選擇這兩種方式，其實(shí)還有一個(gè)數(shù)據(jù)一致性 問(wèn)題可以聊聊，比如選擇定時(shí)器肯定就拋棄了一致性，最求的是最終一致，這里就不深入展開(kāi)了，另外你可能還會(huì)說(shuō)服務(wù)的移除等等這些功能都沒(méi)介紹，在我看來(lái)那只是一個(gè)附加功能，注冊(cè)中心重點(diǎn)還是在于服務(wù)注冊(cè)和發(fā)現(xiàn)，其他都是錦上添花罷了。

4、如何解決負(fù)載均衡的問(wèn)題？

負(fù)載均衡的實(shí)現(xiàn)有兩種方式:

服務(wù)端的負(fù)載均衡；

客戶(hù)端的負(fù)載均衡; 對(duì)于實(shí)現(xiàn)的方案來(lái)說(shuō)本質(zhì)上是差不多的，只是說(shuō)承接的載體不一樣，一個(gè)是服務(wù)端，一個(gè)客戶(hù)端，如下圖:

服務(wù)端的負(fù)載均衡，給服務(wù)提供者更強(qiáng)的流量控制權(quán)，但是無(wú)法滿(mǎn)足不同的消費(fèi)者希望使用不同負(fù)載均衡策略的需求。

客戶(hù)端的負(fù)載均衡則提供了這種靈活性，并對(duì)用戶(hù)擴(kuò)展提供更加友好的支持。但是客戶(hù)端負(fù)載均衡策略如果配置不當(dāng)，可能會(huì)導(dǎo)致服務(wù)提供者出現(xiàn)熱點(diǎn)，或者壓根就拿不到任何服務(wù)提供者。

服務(wù)端負(fù)載均衡典型的代表就是Nginx ，客戶(hù)端負(fù)載均衡典型代表是Ribbon ，每種方式都有經(jīng)典的代表，我們都是可以深入學(xué)習(xí)的。

常見(jiàn)的負(fù)載均衡器的算法的實(shí)現(xiàn)，常見(jiàn)的算法有以下六種 :

1、輪詢(xún)法

將請(qǐng)求按順序輪流地分配到后端服務(wù)器上，它均衡地對(duì)待后端的每一臺(tái)服務(wù)器，而不關(guān)心服務(wù)器實(shí)際的連接數(shù)和當(dāng)前的系統(tǒng)負(fù)載。

2、隨機(jī)法

通過(guò)系統(tǒng)的隨機(jī)算法，根據(jù)后端服務(wù)器的列表大小值來(lái)隨機(jī)選取其中的一臺(tái)服務(wù)器進(jìn)行訪問(wèn)。由概率統(tǒng)計(jì)理論可以得知，隨著客戶(hù)端調(diào)用服務(wù)端的次數(shù)增多；其實(shí)際效果越來(lái)越接近于平均分配調(diào)用量到后端的每一臺(tái)服務(wù)器，也就是輪詢(xún)的結(jié)果。

3、哈希算法

哈希的思想是根據(jù)獲取客戶(hù)端的IP地址，通過(guò)哈希函數(shù)計(jì)算得到的一個(gè)數(shù)值，用該數(shù)值對(duì)服務(wù)器列表的大小進(jìn)行取模運(yùn)算，得到的結(jié)果便是客服端要訪問(wèn)服務(wù)器的序號(hào)。采用源地址哈希法進(jìn)行負(fù)載均衡，同一IP地址的客戶(hù)端，當(dāng)后端服務(wù)器列表不變時(shí)，它每次都會(huì)映射到同一臺(tái)后端服務(wù)器進(jìn)行訪問(wèn)。

4、加權(quán)輪詢(xún)法

不同的后端服務(wù)器可能機(jī)器的配置和當(dāng)前系統(tǒng)的負(fù)載并不相同，因此它們的抗壓能力也不相同。給配置高、負(fù)載低的機(jī)器配置更高的權(quán)重，讓其處理更多的請(qǐng)；而配置低、負(fù)載高的機(jī)器，給其分配較低的權(quán)重，降低其系統(tǒng)負(fù)載，加權(quán)輪詢(xún)能很好地處理這一問(wèn)題，并將請(qǐng)求順序且按照權(quán)重分配到后端。

5.加權(quán)隨機(jī)法

與加權(quán)輪詢(xún)法一樣，加權(quán)隨機(jī)法也根據(jù)后端機(jī)器的配置，系統(tǒng)的負(fù)載分配不同的權(quán)重。不同的是，它是按照權(quán)重隨機(jī)請(qǐng)求后端服務(wù)器，而非順序。

6.最小連接數(shù)法

最小連接數(shù)算法比較靈活和智能，由于后端服務(wù)器的配置不盡相同，對(duì)于請(qǐng)求的處理有快有慢，它是根據(jù)后端服務(wù)器當(dāng)前的連接情況，動(dòng)態(tài)地選取其中當(dāng)前 積壓連接數(shù)最少的一臺(tái)服務(wù)器來(lái)處理當(dāng)前的請(qǐng)求，盡可能地提高后端服務(wù)的利用效率，將負(fù)責(zé)合理地分流到每一臺(tái)服務(wù)器。

5、注冊(cè)中心如何選型？

現(xiàn)在注冊(cè)中心的選擇也是五花八門(mén)，現(xiàn)階段比較流行有以下幾種:

在介紹這個(gè)之前大家有些需要了解的知識(shí)有CAP 、Paxos 、Raft算法 這里我就不進(jìn)行過(guò)多介紹了。開(kāi)始介紹以上5種實(shí)現(xiàn)注冊(cè)中心的方式。

1、Zookeeper

這個(gè)說(shuō)起來(lái)有點(diǎn)意思的是官方并沒(méi)有說(shuō)他是一個(gè)注冊(cè)中心，但是國(guó)內(nèi)Dubbo場(chǎng)景下很多都是使用Zookeeper來(lái)完成了注冊(cè)中心的功能。

當(dāng)然這有很多歷史原因，這里我們就不追溯了，我還是來(lái)聊聊作為注冊(cè)中心使用的情況下，Zookeeper有哪些表現(xiàn)吧。

Zookeeper基礎(chǔ)概念

1、三種角色

Leader 角色 ：一個(gè)Zookeeper集群同一時(shí)間只會(huì)有一個(gè)實(shí)際工作的Leader，它會(huì)發(fā)起并維護(hù)與各Follwer及Observer間的心跳。所有的寫(xiě)操作必須要通過(guò)Leader完成再由Leader將寫(xiě)操作廣播給其它服務(wù)器。

Follower角色 ：一個(gè)Zookeeper集群可能同時(shí)存在多個(gè)Follower，它會(huì)響應(yīng)Leader的心跳。Follower可直接處理并返回客戶(hù)端的讀請(qǐng)求，同時(shí)會(huì)將寫(xiě)請(qǐng)求轉(zhuǎn)發(fā)給Leader處理，并且負(fù)責(zé)在Leader處理寫(xiě)請(qǐng)求時(shí)對(duì)請(qǐng)求進(jìn)行投票。

Observer角色 ：與Follower類(lèi)似，但是無(wú)投票權(quán)。

2、四種節(jié)點(diǎn)

PERSISTENT-持久節(jié)點(diǎn) ：除非手動(dòng)刪除，否則節(jié)點(diǎn)一直存在于Zookeeper上

EPHEMERAL-臨時(shí)節(jié)點(diǎn) ：臨時(shí)節(jié)點(diǎn)的生命周期與客戶(hù)端會(huì)話(huà)綁定，一旦客戶(hù)端會(huì)話(huà)失效，那么這個(gè)客戶(hù)端創(chuàng)建的所有臨時(shí)節(jié)點(diǎn)都會(huì)被移除。

PERSISTENT_SEQUENTIAL-持久順序節(jié)點(diǎn) ：基本特性同持久節(jié)點(diǎn)，只是增加了順序?qū)傩?，?jié)點(diǎn)名后邊會(huì)追加一個(gè)由父節(jié)點(diǎn)維護(hù)的自增整型數(shù)字。

EPHEMERAL_SEQUENTIAL-臨時(shí)順序節(jié)點(diǎn) ：基本特性同臨時(shí)節(jié)點(diǎn)，增加了順序?qū)傩裕?jié)點(diǎn)名后邊會(huì)追加一個(gè)由父節(jié)點(diǎn)維護(hù)的自增整型數(shù)字。

3、一種機(jī)制

Zookeeper的Watch機(jī)制 ，是一個(gè)輕量級(jí)的設(shè)計(jì)。因?yàn)樗捎昧艘环N推拉結(jié)合的模式。一旦服務(wù)端感知主題變了，那么只會(huì)發(fā)送一個(gè)事件類(lèi)型和節(jié)點(diǎn)信息給關(guān)注的客戶(hù)端，而不會(huì)包括具體的變更內(nèi)容，所以事件本身是輕量級(jí)的，這就是推的部分。然后，收到變更通知的客戶(hù)端需要自己去拉變更的數(shù)據(jù)，這就是拉的部分。

Zookeeper如何實(shí)現(xiàn)注冊(cè)中心?

簡(jiǎn)單來(lái)講，Zookeeper可以充當(dāng)一個(gè)服務(wù)注冊(cè)表（Service Registry），讓多個(gè)服務(wù)提供者形成一個(gè)集群，讓服務(wù)消費(fèi)者通過(guò)服務(wù)注冊(cè)表獲取具體的服務(wù)訪問(wèn)地址（ip+端口）去訪問(wèn)具體的服務(wù)提供者。如下圖所示：

每當(dāng)一個(gè)服務(wù)提供者部署后都要將自己的服務(wù)注冊(cè)到zookeeper的某一路徑上: /{service}/{version}/{ip:port} 。

比如我們的HelloWorldService 部署到兩臺(tái)機(jī)器，那么Zookeeper上就會(huì)創(chuàng)建兩條目錄：

/HelloWorldService/1.0.0/100.19.20.01:16888

HelloWorldService/1.0.0/100.19.20.02:16888。

這么描述有點(diǎn)不好理解，下圖更直觀，

在Zookeeper中，進(jìn)行服務(wù)注冊(cè)，實(shí)際上就是在Zookeeper中創(chuàng)建了一個(gè)Znode節(jié)點(diǎn)，該節(jié)點(diǎn)存儲(chǔ)了該服務(wù)的IP、端口、調(diào)用方式(協(xié)議、序列化方式)等。

該節(jié)點(diǎn)承擔(dān)著最重要的職責(zé)，它由服務(wù)提供者(發(fā)布服務(wù)時(shí))創(chuàng)建，以供服務(wù)消費(fèi)者獲取節(jié)點(diǎn)中的信息，從而定位到服務(wù)提供者真正IP，發(fā)起調(diào)用。通過(guò)IP設(shè)置為臨時(shí)節(jié)點(diǎn)，那么該節(jié)點(diǎn)數(shù)據(jù)不會(huì)一直存儲(chǔ)在 ZooKeeper 服務(wù)器上。

當(dāng)創(chuàng)建該臨時(shí)節(jié)點(diǎn)的客戶(hù)端會(huì)話(huà)因超時(shí)或發(fā)生異常而關(guān)閉時(shí)，該節(jié)點(diǎn)也相應(yīng)在 ZooKeeper 服務(wù)器上被刪除，剔除或者上線的時(shí)候會(huì)觸發(fā)Zookeeper的Watch機(jī)制，會(huì)發(fā)送消息給消費(fèi)者，因此就做到消費(fèi)者信息的及時(shí)更新。

Zookeeper從設(shè)計(jì)上來(lái)說(shuō)的話(huà)整體遵循的CP的原則，在任何時(shí)候?qū)?Zookeeper 的訪問(wèn)請(qǐng)求能得到一致的數(shù)據(jù)結(jié)果，同時(shí)系統(tǒng)對(duì)網(wǎng)絡(luò)分區(qū)具備容錯(cuò)性，在使用 Zookeeper 獲取服務(wù)列表時(shí)，如果此時(shí)的 Zookeeper 集群中的 Leader 宕機(jī)了，該集群就要進(jìn)行 Leader 的選舉，又或者 Zookeeper 集群中半數(shù)以上服務(wù)器節(jié)點(diǎn)不可用（例如有三個(gè)節(jié)點(diǎn)，如果節(jié)點(diǎn)一檢測(cè)到節(jié)點(diǎn)三掛了 ，節(jié)點(diǎn)二也檢測(cè)到節(jié)點(diǎn)三掛了，那這個(gè)節(jié)點(diǎn)才算是真的掛了)，那么將無(wú)法處理該請(qǐng)求。

所以說(shuō)，Zookeeper 不能保證服務(wù)可用性。

2、Eureka

Netflix我感覺(jué)應(yīng)該是在醞釀更好的東西的，下面我們重點(diǎn)還是來(lái)介紹Ereka 1.x相關(guān)的設(shè)計(jì)。

Eureka由兩個(gè)組件組成：Eureka服務(wù)端 和Eureka客戶(hù)端 。Eureka服務(wù)器用作服務(wù)注冊(cè)服務(wù)器。Eureka客戶(hù)端是一個(gè)java客戶(hù)端，用來(lái)簡(jiǎn)化與服務(wù)器的交互、作為輪詢(xún)負(fù)載均衡器，并提供服務(wù)的故障切換支持。

Eureka的基本架構(gòu)，由3個(gè)角色組成：

1、Eureka Server： 提供服務(wù)注冊(cè)和發(fā)現(xiàn)功能；

2、Service Provider 服務(wù)提供方，將自身服務(wù)注冊(cè)到Eureka，從而使服務(wù)消費(fèi)方能夠找到；

3、Service Consumer 服務(wù)消費(fèi)方，從Eureka獲取注冊(cè)服務(wù)列表，從而能夠消費(fèi)服務(wù)

Eureka 在設(shè)計(jì)時(shí)就緊遵AP 原則，Eureka Server 可以運(yùn)行多個(gè)實(shí)例來(lái)構(gòu)建集群，解決單點(diǎn)問(wèn)題，實(shí)例之間通過(guò)彼此互相注冊(cè)來(lái)提高可用性，是一種去中心化的架構(gòu)，無(wú) master/slave 之分，每一個(gè)實(shí)例 都是對(duì)等的，每個(gè)節(jié)點(diǎn)都可被視為其他節(jié)點(diǎn)的副本。

在集群環(huán)境中如果某臺(tái) Eureka Server 宕機(jī)，Eureka Client 的請(qǐng)求會(huì)自動(dòng)切換到新的 Eureka Server 節(jié)點(diǎn)上，當(dāng)宕機(jī)的服務(wù)器重新恢復(fù)后，Eureka 會(huì)再次將其納入到服務(wù)器集群管理之中。

當(dāng)節(jié)點(diǎn)開(kāi)始接受客戶(hù)端請(qǐng)求時(shí)，所有的操作都會(huì)在節(jié)點(diǎn)間進(jìn)行復(fù)制操作，將請(qǐng)求復(fù)制到該 Eureka Server 當(dāng)前所知的其它所有節(jié)點(diǎn)中。

當(dāng)一個(gè)新的 Eureka Server 節(jié)點(diǎn)啟動(dòng)后，會(huì)首先嘗試從鄰近節(jié)點(diǎn)獲取所有注冊(cè)列表信息，并完成初始化。Eureka Server 通過(guò) getEurekaServiceUrls() 方法獲取所有的節(jié)點(diǎn)，并且會(huì)通過(guò)心跳契約的方式定期更新。

默認(rèn)情況下，如果 Eureka Server 在一定時(shí)間內(nèi)沒(méi)有接收到某個(gè)服務(wù)實(shí)例的心跳（默認(rèn)周期為30秒），Eureka Server 將會(huì)注銷(xiāo)該實(shí)例（默認(rèn)為90秒， eureka.instance.lease-expiration-duration-in-seconds 進(jìn)行自定義配置）。

當(dāng) Eureka Server 節(jié)點(diǎn)在短時(shí)間內(nèi)丟失過(guò)多的心跳時(shí)，那么這個(gè)節(jié)點(diǎn)就會(huì)進(jìn)入自我保護(hù)模式，這個(gè)測(cè)試環(huán)境的時(shí)候需要注意一下。

Eureka的集群中，只要有一臺(tái)Eureka還在，就能保證注冊(cè)服務(wù)可用，只不過(guò)查到的信息可能不是最新的（不保證強(qiáng)一致性）。

除此之外，Eureka還有一種自我保護(hù)機(jī)制，如果在15分鐘 內(nèi)超過(guò)85% 的節(jié)點(diǎn)都沒(méi)有正常的心跳，那么Eureka就認(rèn)為客戶(hù)端與注冊(cè)中心出現(xiàn)了網(wǎng)絡(luò)故障，此時(shí)會(huì)出現(xiàn)以下幾種情況：

Eureka不再?gòu)淖?cè)表中移除因?yàn)殚L(zhǎng)時(shí)間沒(méi)有收到心跳而過(guò)期的服務(wù)；

Eureka仍然能夠接受新服務(wù)注冊(cè)和查詢(xún)請(qǐng)求，但是不會(huì)被同步到其它節(jié)點(diǎn)上（即保證當(dāng)前節(jié)點(diǎn)依然可用）

當(dāng)網(wǎng)絡(luò)穩(wěn)定時(shí)，當(dāng)前實(shí)例新注冊(cè)的信息會(huì)被同步到其它節(jié)點(diǎn)中。

3、Nacos

Nacos 無(wú)縫支持一些主流的開(kāi)源生態(tài),如下圖:

Nacos 致力于幫助您發(fā)現(xiàn)、配置和管理微服務(wù)。Nacos 提供了一組簡(jiǎn)單易用的特性集，幫助您快速實(shí)現(xiàn)動(dòng)態(tài)服務(wù)發(fā)現(xiàn)、服務(wù)配置、服務(wù)元數(shù)據(jù)及流量管理。

Nacos 幫助您更敏捷和容易地構(gòu)建、交付和管理微服務(wù)平臺(tái)。Nacos 是構(gòu)建以“服務(wù)”為中心的現(xiàn)代應(yīng)用架構(gòu) (例如微服務(wù)范式、云原生范式) 的服務(wù)基礎(chǔ)設(shè)施。

Nacos除了服務(wù)的注冊(cè)發(fā)現(xiàn)之外，還支持動(dòng)態(tài)配置服務(wù) 。動(dòng)態(tài)配置服務(wù)可以讓您以中心化、外部化和動(dòng)態(tài)化的方式管理所有環(huán)境的應(yīng)用配置和服務(wù)配置。動(dòng)態(tài)配置消除了配置變更時(shí)重新部署應(yīng)用和服務(wù)的需要，讓配置管理變得更加高效和敏捷。配置中心化管理讓實(shí)現(xiàn)無(wú)狀態(tài)服務(wù)變得更簡(jiǎn)單，讓服務(wù)按需彈性擴(kuò)展變得更容易。

Nacos特點(diǎn)

服務(wù)發(fā)現(xiàn)和服務(wù)健康監(jiān)測(cè)

Nacos 支持基于 DNS 和基于 RPC 的服務(wù)發(fā)現(xiàn)。服務(wù)提供者使用 原生SDK、OpenAPI、或一個(gè)獨(dú)立的Agent TODO注冊(cè) Service 后，服務(wù)消費(fèi)者可以使用DNS TODO 或HTTP&API查找和發(fā)現(xiàn)服務(wù)。

Nacos 提供對(duì)服務(wù)的實(shí)時(shí)的健康檢查，阻止向不健康的主機(jī)或服務(wù)實(shí)例發(fā)送請(qǐng)求。Nacos 支持傳輸層 (PING 或 TCP)和應(yīng)用層 (如 HTTP、MySQL、用戶(hù)自定義）的健康檢查。對(duì)于復(fù)雜的云環(huán)境和網(wǎng)絡(luò)拓?fù)洵h(huán)境中（如 VPC、邊緣網(wǎng)絡(luò)等）服務(wù)的健康檢查，Nacos 提供了 agent 上報(bào)模式和服務(wù)端主動(dòng)檢測(cè)2種健康檢查模式。Nacos 還提供了統(tǒng)一的健康檢查儀表盤(pán)，幫助您根據(jù)健康狀態(tài)管理服務(wù)的可用性及流量。

動(dòng)態(tài)配置服務(wù)

動(dòng)態(tài)配置服務(wù)可以讓您以中心化、外部化和動(dòng)態(tài)化的方式管理所有環(huán)境的應(yīng)用配置和服務(wù)配置。

動(dòng)態(tài)配置消除了配置變更時(shí)重新部署應(yīng)用和服務(wù)的需要，讓配置管理變得更加高效和敏捷。

配置中心化管理讓實(shí)現(xiàn)無(wú)狀態(tài)服務(wù)變得更簡(jiǎn)單，讓服務(wù)按需彈性擴(kuò)展變得更容易。

Nacos 提供了一個(gè)簡(jiǎn)潔易用的UI (控制臺(tái)樣例 Demo) 幫助您管理所有的服務(wù)和應(yīng)用的配置。Nacos 還提供包括配置版本跟蹤、金絲雀發(fā)布、一鍵回滾配置以及客戶(hù)端配置更新?tīng)顟B(tài)跟蹤在內(nèi)的一系列開(kāi)箱即用的配置管理特性，幫助您更安全地在生產(chǎn)環(huán)境中管理配置變更和降低配置變更帶來(lái)的風(fēng)險(xiǎn)。

動(dòng)態(tài) DNS 服務(wù)

動(dòng)態(tài) DNS 服務(wù)支持權(quán)重路由，讓您更容易地實(shí)現(xiàn)中間層負(fù)載均衡、更靈活的路由策略、流量控制以及數(shù)據(jù)中心內(nèi)網(wǎng)的簡(jiǎn)單DNS解析服務(wù)。動(dòng)態(tài)DNS服務(wù)還能讓您更容易地實(shí)現(xiàn)以 DNS 協(xié)議為基礎(chǔ)的服務(wù)發(fā)現(xiàn)，以幫助您消除耦合到廠商私有服務(wù)發(fā)現(xiàn) API 上的風(fēng)險(xiǎn)。

Nacos 提供了一些簡(jiǎn)單的 DNS APIs TODO 幫助您管理服務(wù)的關(guān)聯(lián)域名和可用的 IP:PORT 列表.

服務(wù)及其元數(shù)據(jù)管理

Nacos 能讓您從微服務(wù)平臺(tái)建設(shè)的視角管理數(shù)據(jù)中心的所有服務(wù)及元數(shù)據(jù)，包括管理服務(wù)的描述、生命周期、服務(wù)的靜態(tài)依賴(lài)分析、服務(wù)的健康狀態(tài)、服務(wù)的流量管理、路由及安全策略、服務(wù)的 SLA 以及最首要的 metrics 統(tǒng)計(jì)數(shù)據(jù)。

Nacos支持插件管理

****

關(guān)于Nacos數(shù)據(jù)的存儲(chǔ)來(lái)說(shuō)，支持臨時(shí)也支持持久化。

關(guān)于設(shè)計(jì)來(lái)說(shuō)支持CP也支持AP，對(duì)他來(lái)說(shuō)只是一個(gè)命令的切換，隨你玩，還支持各種注冊(cè)中心遷移到Nacos，反正一句話(huà)，只要你想要的他就有。

4、Consul

Consul是HashiCorp公司推出的開(kāi)源工具，Consul由Go語(yǔ)言開(kāi)發(fā)，部署起來(lái)非常容易，只需要極少的可執(zhí)行程序和配置文件，具有綠色、輕量級(jí)的特點(diǎn)。Consul是分布式的、高可用的、 可橫向擴(kuò)展的用于實(shí)現(xiàn)分布式系統(tǒng)的服務(wù)發(fā)現(xiàn)與配置。

Consul的特點(diǎn)

服務(wù)發(fā)現(xiàn)（Service Discovery）

Consul提供了通過(guò)DNS或者HTTP接口的方式來(lái)注冊(cè)服務(wù)和發(fā)現(xiàn)服務(wù)。一些外部的服務(wù)通過(guò)Consul很容易的找到它所依賴(lài)的服務(wù)。

健康檢查（Health Checking）

Consul的Client可以提供任意數(shù)量的健康檢查，既可以與給定的服務(wù)相關(guān)聯(lián)(“webserver是否返回200 OK”)，也可以與本地節(jié)點(diǎn)相關(guān)聯(lián)(“內(nèi)存利用率是否低于90%”)。操作員可以使用這些信息來(lái)監(jiān)視集群的健康狀況，服務(wù)發(fā)現(xiàn)組件可以使用這些信息將流量從不健康的主機(jī)路由出去。

Key/Value存儲(chǔ)

應(yīng)用程序可以根據(jù)自己的需要使用Consul提供的Key/Value存儲(chǔ)。Consul提供了簡(jiǎn)單易用的HTTP接口，結(jié)合其他工具可以實(shí)現(xiàn)動(dòng)態(tài)配置、功能標(biāo)記、領(lǐng)袖選舉等等功能。

安全服務(wù)通信

Consul可以為服務(wù)生成和分發(fā)TLS證書(shū)，以建立相互的TLS連接。意圖可用于定義允許哪些服務(wù)通信。服務(wù)分割可以很容易地進(jìn)行管理，其目的是可以實(shí)時(shí)更改的，而不是使用復(fù)雜的網(wǎng)絡(luò)拓?fù)浜挽o態(tài)防火墻規(guī)則。

多數(shù)據(jù)中心

Consul支持開(kāi)箱即用的多數(shù)據(jù)中心. 這意味著用戶(hù)不需要擔(dān)心需要建立額外的抽象層讓業(yè)務(wù)擴(kuò)展到多個(gè)區(qū)域。

Consul支持多數(shù)據(jù)中心，在上圖中有兩個(gè)DataCenter，他們通過(guò)Internet互聯(lián)，同時(shí)請(qǐng)注意為了提高通信效率，只有Server節(jié)點(diǎn)才加入跨數(shù)據(jù)中心的通信。

在單個(gè)數(shù)據(jù)中心中，Consul分為Client和Server兩種節(jié)點(diǎn)（所有的節(jié)點(diǎn)也被稱(chēng)為Agent），Server節(jié)點(diǎn)保存數(shù)據(jù)，Client負(fù)責(zé)健康檢查及轉(zhuǎn)發(fā)數(shù)據(jù)請(qǐng)求到Server；Server節(jié)點(diǎn)有一個(gè)Leader和多個(gè)Follower，Leader節(jié)點(diǎn)會(huì)將數(shù)據(jù)同步到Follower，Server的數(shù)量推薦是3個(gè)或者5個(gè)，在Leader掛掉的時(shí)候會(huì)啟動(dòng)選舉機(jī)制產(chǎn)生一個(gè)新的Leader。

集群內(nèi)的Consul節(jié)點(diǎn)通過(guò)gossip協(xié)議（流言協(xié)議）維護(hù)成員關(guān)系，也就是說(shuō)某個(gè)節(jié)點(diǎn)了解集群內(nèi)現(xiàn)在還有哪些節(jié)點(diǎn)，這些節(jié)點(diǎn)是Client還是Server。單個(gè)數(shù)據(jù)中心的流言協(xié)議同時(shí)使用TCP和UDP通信，并且都使用8301端口?？鐢?shù)據(jù)中心的流言協(xié)議也同時(shí)使用TCP和UDP通信，端口使用8302。

集群內(nèi)數(shù)據(jù)的讀寫(xiě)請(qǐng)求既可以直接發(fā)到Server，也可以通過(guò)Client使用RPC轉(zhuǎn)發(fā)到Server，請(qǐng)求最終會(huì)到達(dá)Leader節(jié)點(diǎn)，在允許數(shù)據(jù)延時(shí)的情況下，讀請(qǐng)求也可以在普通的Server節(jié)點(diǎn)完成，集群內(nèi)數(shù)據(jù)的讀寫(xiě)和復(fù)制都是通過(guò)TCP的8300端口完成。

Consul其實(shí)也可以在應(yīng)用內(nèi)進(jìn)行注冊(cè)，后續(xù)采用Spring Cloud全家桶這套做負(fù)載

我們這里聊聊關(guān)于Consul的應(yīng)用外的注冊(cè)：

上圖主要多出來(lái)兩個(gè)組件，分別是Registrator和Consul Template，接下來(lái)我們介紹下這兩個(gè)組件如何結(jié)合可以實(shí)現(xiàn)在應(yīng)用發(fā)進(jìn)行服務(wù)發(fā)現(xiàn)和注冊(cè)。

Registrator ：一個(gè)開(kāi)源的第三方服務(wù)管理器項(xiàng)目，它通過(guò)監(jiān)聽(tīng)服務(wù)部署的 Docker 實(shí)例是否存活，來(lái)負(fù)責(zé)服務(wù)提供者的注冊(cè)和銷(xiāo)毀。

Consul Template ：定時(shí)從注冊(cè)中心服務(wù)端獲取最新的服務(wù)提供者節(jié)點(diǎn)列表并刷新 LB 配置（比如 Nginx 的 upstream），這樣服務(wù)消費(fèi)者就通過(guò)訪問(wèn) Nginx 就可以獲取最新的服務(wù)提供者信息,達(dá)到動(dòng)態(tài)調(diào)節(jié)負(fù)載均衡的目的。

整體架構(gòu)圖可能是這樣:

我們用Registrator來(lái)監(jiān)控每個(gè)Server的狀態(tài)。當(dāng)有新的Server啟動(dòng)的時(shí)候，Registrator會(huì)把它注冊(cè)到Consul這個(gè)注冊(cè)中心上。

由于Consul Template已經(jīng)訂閱了該注冊(cè)中心上的服務(wù)消息，此時(shí)Consul注冊(cè)中心會(huì)將新的Server信息推送給Consul Template，Consul Template則會(huì)去修改nginx.conf的配置文件，然后讓Nginx重新載入配置以達(dá)到自動(dòng)修改負(fù)載均衡的目的。

5、Kubernetes

Kubernetes是一個(gè)輕便的和可擴(kuò)展的開(kāi)源平臺(tái)，用于管理容器化應(yīng)用和服務(wù)。通過(guò)Kubernetes能夠進(jìn)行應(yīng)用的自動(dòng)化部署和擴(kuò)縮容。

在Kubernetes中，會(huì)將組成應(yīng)用的容器組合成一個(gè)邏輯單元以更易管理和發(fā)現(xiàn)。Kubernetes積累了作為Google生產(chǎn)環(huán)境運(yùn)行工作負(fù)載15年的經(jīng)驗(yàn)，并吸收了來(lái)自于社區(qū)的最佳想法和實(shí)踐。

Kubernetes經(jīng)過(guò)這幾年的快速發(fā)展，形成了一個(gè)大的生態(tài)環(huán)境，Google在2014年將Kubernetes作為開(kāi)源項(xiàng)目。Kubernetes的關(guān)鍵特性包括：

自動(dòng)化裝箱 ：在不犧牲可用性的條件下，基于容器對(duì)資源的要求和約束自動(dòng)部署容器。同時(shí)，為了提高利用率和節(jié)省更多資源，將關(guān)鍵和最佳工作量結(jié)合在一起。

自愈能力 ：當(dāng)容器失敗時(shí)，會(huì)對(duì)容器進(jìn)行重啟；當(dāng)所部署的Node節(jié)點(diǎn)有問(wèn)題時(shí)，會(huì)對(duì)容器進(jìn)行重新部署和重新調(diào)度；當(dāng)容器未通過(guò)監(jiān)控檢查時(shí)，會(huì)關(guān)閉此容器；直到容器正常運(yùn)行時(shí)，才會(huì)對(duì)外提供服務(wù)。

水平擴(kuò)容 ：通過(guò)簡(jiǎn)單的命令、用戶(hù)界面或基于CPU的使用情況，能夠?qū)?yīng)用進(jìn)行擴(kuò)容和縮容。

服務(wù)發(fā)現(xiàn)和負(fù)載均衡：開(kāi)發(fā)者不需要使用額外的服務(wù)發(fā)現(xiàn)機(jī)制，就能夠基于Kubernetes進(jìn)行服務(wù)發(fā)現(xiàn)和負(fù)載均衡。

自動(dòng)發(fā)布和回滾 ：Kubernetes能夠程序化的發(fā)布應(yīng)用和相關(guān)的配置。如果發(fā)布有問(wèn)題，Kubernetes將能夠回歸發(fā)生的變更。

保密和配置管理 ：在不需要重新構(gòu)建鏡像的情況下，可以部署和更新保密和應(yīng)用配置。

存儲(chǔ)編排 ：自動(dòng)掛接存儲(chǔ)系統(tǒng)，這些存儲(chǔ)系統(tǒng)可以來(lái)自于本地、公共云提供商（例如：GCP和AWS）、網(wǎng)絡(luò)存儲(chǔ)(例如：NFS、iSCSI、Gluster、Ceph、Cinder和Floker等)。

Kubernetes屬于主從分布式架構(gòu)，主要由Master Node和Worker Node組成，以及包括客戶(hù)端命令行工具Kubectl和其它附加項(xiàng)。

Master Node ：作為控制節(jié)點(diǎn)，對(duì)集群進(jìn)行調(diào)度管理，Master主要由三部分構(gòu)成:

Api Server 相當(dāng)于 K8S 的網(wǎng)關(guān)，所有的指令請(qǐng)求都必須經(jīng)過(guò) Api Server;

Kubernetes調(diào)度器 ，使用調(diào)度算法，把請(qǐng)求資源調(diào)度到某個(gè) Node 節(jié)點(diǎn);

Controller控制器 ，維護(hù) K8S 資源對(duì)象（CRUD：添加、刪除、更新、修改）;

ETCD存儲(chǔ)資源對(duì)象 （可以服務(wù)注冊(cè)、發(fā)現(xiàn)等等）;

Worker Node ：作為真正的工作節(jié)點(diǎn)，運(yùn)行業(yè)務(wù)應(yīng)用的容器；Worker Node主要包含五部分:

Docker是運(yùn)行容器的基礎(chǔ)環(huán)境，容器引擎;

Kuberlet 執(zhí)行在 Node 節(jié)點(diǎn)上的資源操作，Scheduler 把請(qǐng)求交給Api ，然后 Api Sever 再把信息指令數(shù)據(jù)存儲(chǔ)在 ETCD 里，于是 Kuberlet 會(huì)掃描 ETCD 并獲取指令請(qǐng)求，然后去執(zhí)行;

Kube-proxy是代理服務(wù)，起到負(fù)載均衡作用；

Fluentd采集日志;

Pod：Kubernetes 管理的基本單元（最小單元)，Pod 內(nèi)部是容器。Kubernetes 不直接管理容器，而是管理 Pod;

6、總結(jié)

1、高可用

這幾款開(kāi)源產(chǎn)品都已經(jīng)考慮如何搭建高可用集群，這個(gè)地方有些差別而已；

2、關(guān)于CP還是AP的選擇

對(duì)于服務(wù)發(fā)現(xiàn)來(lái)說(shuō)，針對(duì)同一個(gè)服務(wù)，即使注冊(cè)中心的不同節(jié)點(diǎn)保存的服務(wù)提供者信息不盡相同，也并不會(huì)造成災(zāi)難性的后果。

但是對(duì)于服務(wù)消費(fèi)者來(lái)說(shuō)，如果因?yàn)樽?cè)中心的異常導(dǎo)致消費(fèi)不能正常進(jìn)行，對(duì)于系統(tǒng)來(lái)說(shuō)是災(zāi)難性，因此我覺(jué)得對(duì)于注冊(cè)中心選型應(yīng)該關(guān)注可用性，而非一致性，所以我選擇AP 。

3、技術(shù)體系

對(duì)于語(yǔ)言來(lái)說(shuō)我們都是Java技術(shù)棧，從這點(diǎn)來(lái)說(shuō)我們更傾向于Eureka、Nacos，但是Eureka已經(jīng)停止維護(hù)了，因此我會(huì)選擇Nacos。

如果公司內(nèi)部有專(zhuān)門(mén)的中間件或者運(yùn)維團(tuán)隊(duì)的可以Consul、Kubernetes，畢竟Kubernetes才是未來(lái)，我們追求的就是框架內(nèi)解決這些問(wèn)題，不要涉及到應(yīng)用內(nèi)的業(yè)務(wù)開(kāi)發(fā)，我們其實(shí)后者是有的，只是可能不能達(dá)到能自主研發(fā)程度，這樣只能要求自己走的遠(yuǎn)一些。

應(yīng)用內(nèi)的解決方案一般適用于服務(wù)提供者和服務(wù)消費(fèi)者同屬于一個(gè)技術(shù)體系；應(yīng)用外的解決方案一般適合服務(wù)提供者和服務(wù)消費(fèi)者采用了不同技術(shù)體系的業(yè)務(wù)場(chǎng)景。

關(guān)于Eureka、Nacos如何選擇，這個(gè)選擇就比較容易做了，那個(gè)讓我做的事少，我就選擇那個(gè)，顯然Nacos幫我們做了更多的事。