作者簡(jiǎn)介

?

Alex，攜程資深軟件工程師，關(guān)注微服務(wù)架構(gòu)及分布式緩存技術(shù)。

一、前言

攜程的微服務(wù)框架產(chǎn)品從2013年發(fā)展至今，已經(jīng)歷了7年多的打造。其中所使用的服務(wù)注冊(cè)中心也從最開(kāi)始人工數(shù)據(jù)維護(hù)架構(gòu)演進(jìn)到了現(xiàn)在全自動(dòng)、百萬(wàn)容量級(jí)的架構(gòu)。本文將逐一回顧攜程服務(wù)注冊(cè)中心所經(jīng)歷的三輪迭代過(guò)程，并重點(diǎn)介紹最新的第三版架構(gòu)的設(shè)計(jì)與實(shí)現(xiàn)。

?

二、服務(wù)注冊(cè)中心是什么？

圖2-1 微服務(wù)架構(gòu)

微服務(wù)架構(gòu)中所要解決的最核心的技術(shù)問(wèn)題有兩點(diǎn)，一個(gè)是服務(wù)發(fā)現(xiàn)，另一個(gè)是負(fù)載均衡。而服務(wù)注冊(cè)中心就是用來(lái)解決服務(wù)發(fā)現(xiàn)問(wèn)題的。

如圖2-1 所示，在微服務(wù)架構(gòu)中，服務(wù)提供方(ServiceProvider)，需要手動(dòng)或自動(dòng)地將服務(wù)地址注冊(cè)到服務(wù)注冊(cè)中心（Registry）。注冊(cè)的信息包括但不限于ServiceID 和URL。服務(wù)消費(fèi)方（ServiceConsumer）在首次調(diào)用服務(wù)前，需要先從服務(wù)注冊(cè)中心查詢對(duì)應(yīng)服務(wù)的注冊(cè)信息，然后依據(jù)返回的服務(wù)地址信息來(lái)發(fā)起調(diào)用。

?

三、攜程服務(wù)注冊(cè)中心演變史

3.1 人工數(shù)據(jù)維護(hù)階段

在攜程微服務(wù)架構(gòu)推廣初期，為了快速搭建微服務(wù)體系，服務(wù)的調(diào)用過(guò)程繼續(xù)使用傳統(tǒng)的域名方式來(lái)進(jìn)行。在服務(wù)治理層面，服務(wù)提供方首先需要將服務(wù)的一個(gè)完整URL提交到注冊(cè)中心。服務(wù)消費(fèi)方在運(yùn)行時(shí)會(huì)定期從注冊(cè)中心同步最新的URL，并發(fā)起服務(wù)調(diào)用。而這個(gè)URL與應(yīng)用服務(wù)器的關(guān)聯(lián)關(guān)系則由運(yùn)維人員人工在負(fù)載均衡設(shè)備上配置。

?

這種模式下的服務(wù)注冊(cè)中心的優(yōu)點(diǎn)是結(jié)構(gòu)簡(jiǎn)單、容易實(shí)現(xiàn)且運(yùn)維工作量小，有利于微服務(wù)架構(gòu)快速推廣。而缺點(diǎn)則主要集中在以下幾個(gè)方面：

• 配置復(fù)雜：負(fù)載均衡和服務(wù)發(fā)現(xiàn)的數(shù)據(jù)依賴人工維護(hù)，影響開(kāi)發(fā)效率和體驗(yàn)。

• 單點(diǎn)問(wèn)題：服務(wù)調(diào)用強(qiáng)依賴于負(fù)載均衡設(shè)備，該設(shè)備的可用性會(huì)直接影響到微服務(wù)體系的可用性。
  

• 性能問(wèn)題：服務(wù)調(diào)用需要經(jīng)過(guò)一層負(fù)載均衡設(shè)備，存在額外的網(wǎng)絡(luò)開(kāi)銷，會(huì)直接影響到性能。
  

3.2 基于etcd的服務(wù)注冊(cè)中心

在攜程微服務(wù)體系擴(kuò)展到Java平臺(tái)時(shí)，我們希望能夠解決前面由于使用外部負(fù)載均衡設(shè)備所帶來(lái)的各種缺陷，所以計(jì)劃將負(fù)載均衡設(shè)備的功能集成到微服務(wù)的SDK中，同時(shí)由注冊(cè)中心下發(fā)的服務(wù)注冊(cè)信息從之前的固定使用域名的URL，改為服務(wù)集群各臺(tái)服務(wù)器IP所對(duì)應(yīng)的URL。

改進(jìn)后的工作流程是這樣的：服務(wù)提供方啟動(dòng)后，SDK會(huì)把包含本機(jī) IP 的服務(wù)實(shí)例地址上報(bào)給注冊(cè)中心；而服務(wù)消費(fèi)方啟動(dòng)后，SDK會(huì)定期從注冊(cè)中心獲取最新的服務(wù)地址列表，并使用內(nèi)置的負(fù)載均衡算法選出一個(gè)地址來(lái)發(fā)起請(qǐng)求。同時(shí)，為了保證服務(wù)注冊(cè)數(shù)據(jù)的有效性，其中設(shè)置有“存活時(shí)間”（TTL，Time to live）。所以需要服務(wù)注冊(cè)中心支持清理過(guò)期的注冊(cè)數(shù)據(jù)。在設(shè)計(jì)新的架構(gòu)時(shí)，綜合以上這些考慮，我們選擇了etcd來(lái)存儲(chǔ)服務(wù)注冊(cè)數(shù)據(jù)。

圖3-1 基于 etcd 的服務(wù)注冊(cè)中心架構(gòu)

基于 etcd 的服務(wù)注冊(cè)中心整體架構(gòu)，如圖 3-1所示，包含三個(gè)角色。

• Client

提供應(yīng)用接入服務(wù)注冊(cè)中心的基本 API。應(yīng)用通過(guò)嵌入到應(yīng)用程序內(nèi)的 SDK，實(shí)現(xiàn)服務(wù)的自注冊(cè)和自發(fā)現(xiàn)。

• Session

負(fù)責(zé)處理Client提交的服務(wù)注冊(cè)和發(fā)現(xiàn)請(qǐng)求。Client的請(qǐng)求經(jīng)Session協(xié)議轉(zhuǎn)換后，直接轉(zhuǎn)發(fā)給 etcd。etcd的響應(yīng)數(shù)據(jù)經(jīng)Session的服務(wù)治理邏輯處理后，再返回給Client。

• etcd

負(fù)責(zé)存儲(chǔ)服務(wù)注冊(cè)數(shù)據(jù)。集群內(nèi)各節(jié)點(diǎn)間使用Raft協(xié)議來(lái)進(jìn)行數(shù)據(jù)同步。在沒(méi)有網(wǎng)絡(luò)分區(qū)的情況下，節(jié)點(diǎn)上數(shù)據(jù)可以做到完全一致。

?

etcd 滿足CAP（Consistency：數(shù)據(jù)一致性、Availability：服務(wù)可用性、Partition-tolerance：分區(qū)容錯(cuò)性）中的 CP，即優(yōu)先考慮分布式緩存的數(shù)據(jù)一致性。從其設(shè)計(jì)的出發(fā)點(diǎn)來(lái)看，etcd 不適合對(duì)讀寫(xiě)性能要求特別高的場(chǎng)景，而是適合量小且需要高可靠和一致性數(shù)據(jù)存儲(chǔ)服務(wù)，比如配置數(shù)據(jù)、K8s中的集群元數(shù)據(jù)等等。

?

在經(jīng)過(guò)一段時(shí)間的線上部署和運(yùn)維后，我們發(fā)現(xiàn)etcd中存在潛在的可用性和性能問(wèn)題。

?

先說(shuō)下可用性問(wèn)題。假設(shè)etcd集群存在 A、B、C、D和E 五個(gè)節(jié)點(diǎn)，A 是當(dāng)前集群的 Leader 節(jié)點(diǎn)。如果此時(shí)發(fā)生網(wǎng)絡(luò)分區(qū)故障，其中A、B 在一個(gè)分區(qū)，而C、D和E在另一個(gè)分區(qū)。Leader A向所有的Follower發(fā)送心跳，但無(wú)法獲取到大多數(shù)節(jié)點(diǎn)響應(yīng)（計(jì)算公式為(N+2)/2，即在擁有五個(gè)節(jié)點(diǎn)的集群中需要至少獲得三個(gè)節(jié)點(diǎn)的響應(yīng)）。心跳超時(shí)后，集群進(jìn)入選舉階段。但受到網(wǎng)絡(luò)分區(qū)的影響，A和B都無(wú)法獲得大多數(shù)節(jié)點(diǎn)投票。所以由于缺少Leader，A和B 所在的分區(qū)會(huì)處于不可用的狀態(tài)，無(wú)法寫(xiě)入數(shù)據(jù)。

?

再說(shuō)下性能問(wèn)題。etcd所有的寫(xiě)操作都由 Leader 節(jié)點(diǎn)負(fù)責(zé)執(zhí)行。而自注冊(cè)服務(wù)實(shí)例的健康檢測(cè)，是依賴注冊(cè)中心數(shù)據(jù)中的過(guò)期機(jī)制實(shí)現(xiàn)的。所以各個(gè)服務(wù)實(shí)例需要不斷的發(fā)送心跳，來(lái)保持?jǐn)?shù)據(jù)的活躍和有效。但這樣就會(huì)產(chǎn)生大量的寫(xiě)操作，對(duì)Leader節(jié)點(diǎn)的性能和網(wǎng)絡(luò)帶寬都是一個(gè)極大的挑戰(zhàn)。

?

在服務(wù)發(fā)現(xiàn)的場(chǎng)景下，服務(wù)注冊(cè)中心的可用性比數(shù)據(jù)一致性更加重要。數(shù)據(jù)不一致可以通過(guò)客戶端容錯(cuò)（比如熔斷或踢出不可用服務(wù)器等），來(lái)把影響降到最低，甚至可以忽略不計(jì)。而可用性的下降將直接會(huì)導(dǎo)致服務(wù)的注冊(cè)和發(fā)現(xiàn)異常，甚至?xí)l(fā)大規(guī)模的生產(chǎn)故障。

?

綜合以上問(wèn)題，并考慮到 etcd 無(wú)法很好的接入攜程當(dāng)時(shí)的運(yùn)維和監(jiān)控體系，我們走上了自研服務(wù)注冊(cè)中心的道路。

?

3.3 攜程自研的服務(wù)注冊(cè)中心

在設(shè)計(jì)這套自研的服務(wù)注冊(cè)中心時(shí)，我們參考了當(dāng)時(shí)業(yè)界使用比較廣泛的由 Netflix 開(kāi)源的 Eureka。新版注冊(cè)中心同樣沒(méi)有使用外部存儲(chǔ)，而是將服務(wù)的注冊(cè)數(shù)據(jù)保存在內(nèi)存中。節(jié)點(diǎn)間采用對(duì)等的架構(gòu)設(shè)計(jì)。所有節(jié)點(diǎn)都可以接受客戶端的讀寫(xiě)請(qǐng)求。節(jié)點(diǎn)間會(huì)進(jìn)行數(shù)據(jù)同步，實(shí)現(xiàn)數(shù)據(jù)最終一致。

在基本的服務(wù)注冊(cè)和發(fā)現(xiàn)功能外，為了提升效率，我們還在其中增加了服務(wù)變更通知推送功能。這樣客戶端可以以最快的速度獲取到更新的服務(wù)注冊(cè)信息，目前已經(jīng)實(shí)現(xiàn)了服務(wù)實(shí)例的秒級(jí)上下線。

?

我們將這套全新的服務(wù)注冊(cè)中心的開(kāi)發(fā)代號(hào)起名為 Artemis。為了簡(jiǎn)單，后文中均以該開(kāi)發(fā)代號(hào)來(lái)進(jìn)行指代。

?

四、Artemis 架構(gòu)說(shuō)明

4.1 總體架構(gòu)

圖 4-1 Artemis 架構(gòu)

Artemis 的整體架構(gòu)與基于 etcd的服務(wù)注冊(cè)中心類似。如圖4-1 所示，一共包含四個(gè)角色：

• Client

提供應(yīng)用接入注冊(cè)中心基本API。應(yīng)用通過(guò)引用Artemis 對(duì)外提供SDK，以編程方式實(shí)現(xiàn)服務(wù)注冊(cè)和發(fā)現(xiàn)。

• Session

負(fù)責(zé)接受 Client 的服務(wù)注冊(cè)和發(fā)現(xiàn)請(qǐng)求。Session作為中間層將服務(wù)提供方的注冊(cè)請(qǐng)求復(fù)制分發(fā)給Data，并從Data上查詢服務(wù)注冊(cè)數(shù)據(jù)或推送數(shù)據(jù)變化給服務(wù)消費(fèi)方。Session節(jié)點(diǎn)自身是無(wú)狀態(tài)的，集群規(guī)?？呻S著Client的規(guī)模增長(zhǎng)而擴(kuò)容，支持Artemis 服務(wù)能力的水平擴(kuò)展。

• Data

負(fù)責(zé)存儲(chǔ)服務(wù)注冊(cè)數(shù)據(jù)，數(shù)據(jù)按ServiceId進(jìn)行一致性哈希分片存儲(chǔ)，通過(guò)多副本備份保證數(shù)據(jù)的高可用。Data集群規(guī)模可隨著注冊(cè)數(shù)據(jù)量增長(zhǎng)而持續(xù)擴(kuò)容，從而支持 Artemis 數(shù)據(jù)存儲(chǔ)容量的水平擴(kuò)展。

• MetaServer

負(fù)責(zé)從K8s同步Artemis集群服務(wù)器地址列表。在Artemis集群發(fā)生變化時(shí)，MetaServer會(huì)實(shí)時(shí)通知到Session。Session在程序啟動(dòng)或者收到Artemis 集群變化通知時(shí)，將主動(dòng)從MetaServer拉取最新的Artemis地址列表并緩存到本地。

4.2 如何支持海量數(shù)據(jù)

分布式系統(tǒng)在處理海量數(shù)據(jù)時(shí)，首先是考慮如何拆分?jǐn)?shù)據(jù)，其次是在數(shù)據(jù)拆后的如何保障系統(tǒng)的可用性。

?

Artemis使用一致性哈希環(huán)來(lái)拆分?jǐn)?shù)據(jù)。一致性哈希環(huán)的基本使用方式是通過(guò)一個(gè)哈希函數(shù)來(lái)計(jì)算數(shù)據(jù)或節(jié)點(diǎn)的哈希值，令該哈希函數(shù)的數(shù)據(jù)值域?yàn)橐粋€(gè)環(huán)，即哈希函數(shù)輸出的最大值是最小值的前序，節(jié)點(diǎn)依據(jù)其哈希函數(shù)計(jì)算結(jié)果分布在環(huán)上，每個(gè)節(jié)點(diǎn)負(fù)責(zé)處理從自己開(kāi)始逆時(shí)針至下一個(gè)節(jié)點(diǎn)全部哈希值域上的數(shù)據(jù)。Artemis使用服務(wù)注冊(cè)數(shù)據(jù)的ServiceId來(lái)計(jì)算哈希值，這樣可以保證同一個(gè)服務(wù)的注冊(cè)數(shù)據(jù)可以被存儲(chǔ)在相同的節(jié)點(diǎn)上，減少網(wǎng)絡(luò)調(diào)用的操作量。

?

例：假設(shè)一致性哈希函數(shù)值域是[0, 8)，系統(tǒng)中有三個(gè)節(jié)點(diǎn) A、B、C，分別處于一致性哈希環(huán)的2、5、6位置。由此可知，節(jié)點(diǎn)A的負(fù)責(zé)范圍為 [7,8）和 [0,3)，節(jié)點(diǎn)B的負(fù)責(zé)范圍為[3, 6)，節(jié)點(diǎn)C的負(fù)責(zé)范圍為[6, 7)，如圖 4-2所示。

圖4-2一致性哈希環(huán)

使用一致性哈希環(huán)拆分?jǐn)?shù)據(jù)的優(yōu)點(diǎn)在于可以任意動(dòng)態(tài)擴(kuò)容或縮容節(jié)點(diǎn)。對(duì)集群進(jìn)行擴(kuò)容或縮容的操作，僅會(huì)影響與被操作節(jié)點(diǎn)相鄰的節(jié)點(diǎn)上的數(shù)據(jù)分布。

?

但最基本的一致性哈希環(huán)用法存在一個(gè)很明顯的缺陷，那就是環(huán)上的節(jié)點(diǎn)分布不均勻。由此所帶來(lái)另一個(gè)較為嚴(yán)重的問(wèn)題是，當(dāng)一個(gè)節(jié)點(diǎn)出現(xiàn)異常時(shí)，該節(jié)點(diǎn)的壓力會(huì)全部轉(zhuǎn)移到相鄰的一個(gè)節(jié)點(diǎn)；而當(dāng)一個(gè)新節(jié)點(diǎn)加入時(shí)，只能為一個(gè)相鄰節(jié)點(diǎn)分?jǐn)倝毫Α?/p>

?

一種常見(jiàn)的改進(jìn)算法是引入虛擬節(jié)點(diǎn)（virtual node）的概念。系統(tǒng)在初始化時(shí)，每個(gè)真實(shí)節(jié)點(diǎn)都會(huì)對(duì)應(yīng)的創(chuàng)建多個(gè)虛擬節(jié)點(diǎn)。虛擬節(jié)點(diǎn)的個(gè)數(shù)一般遠(yuǎn)大于集群中服務(wù)器的個(gè)數(shù)。依據(jù)虛擬節(jié)點(diǎn)的哈希值，系統(tǒng)將它們分布到環(huán)上。在操作數(shù)據(jù)時(shí)，首先需要通過(guò)數(shù)據(jù)的哈希值在環(huán)上找到對(duì)應(yīng)的虛擬節(jié)點(diǎn)，然后從元數(shù)據(jù)中查找到對(duì)應(yīng)的真實(shí)節(jié)點(diǎn)，再進(jìn)行數(shù)據(jù)讀寫(xiě)操作。使用虛擬節(jié)點(diǎn)有多個(gè)好處。首先，一旦系統(tǒng)中某個(gè)節(jié)點(diǎn)出現(xiàn)不可用，其對(duì)應(yīng)的所有虛擬節(jié)點(diǎn)也會(huì)同時(shí)變?yōu)椴豢捎?#xff0c;從而它的服務(wù)壓力會(huì)被均衡的分配到多個(gè)相鄰的真實(shí)節(jié)點(diǎn)上。同理，一旦系統(tǒng)中加入一個(gè)新節(jié)點(diǎn)，也將在環(huán)上引入多個(gè)虛擬節(jié)點(diǎn)，從而使得新節(jié)點(diǎn)可以均衡的分擔(dān)多個(gè)真實(shí)節(jié)點(diǎn)的壓力。從全局看，這種實(shí)現(xiàn)方式更加容易實(shí)現(xiàn)集群擴(kuò)容時(shí)的負(fù)載均衡。

?

Artemis使用一致性哈希環(huán)加虛擬節(jié)點(diǎn)的方法，實(shí)現(xiàn)了海量數(shù)據(jù)的分片存儲(chǔ)和集群擴(kuò)縮容時(shí)的負(fù)載均衡。而在數(shù)據(jù)拆分后的集群可用性方面，Artemis則是通過(guò)數(shù)據(jù)副本策略來(lái)保障的。每一條服務(wù)注冊(cè)數(shù)據(jù)同時(shí)被存儲(chǔ)在多個(gè)節(jié)點(diǎn)上，其中一個(gè)是主副本節(jié)點(diǎn)，其余的是從副本節(jié)點(diǎn)。假如我們需要在集群中選擇N個(gè)節(jié)點(diǎn)來(lái)存儲(chǔ)同一條數(shù)據(jù)，那么在根據(jù)哈希函數(shù)計(jì)算出數(shù)據(jù)中ServiceID的哈希值后，系統(tǒng)會(huì)從哈希值落到環(huán)上的位置開(kāi)始順時(shí)針依次選擇連續(xù)N個(gè)不同的真實(shí)節(jié)點(diǎn)來(lái)存儲(chǔ)這一份數(shù)據(jù)的各個(gè)副本。

圖4-3 一致性哈希環(huán)（6個(gè)虛擬節(jié)點(diǎn)，2個(gè)注冊(cè)數(shù)據(jù)副本）

?

4.3 服務(wù)實(shí)例秒級(jí)上下線

在設(shè)計(jì)服務(wù)注冊(cè)中心時(shí)，一個(gè)重要的考量指標(biāo)就是服務(wù)實(shí)例的上下線延遲。這個(gè)延遲是指從服務(wù)注冊(cè)中心確定服務(wù)實(shí)例發(fā)生了上下線變更起，到服務(wù)消費(fèi)方收到更新后的注冊(cè)數(shù)據(jù)的時(shí)間間隔。延遲越高，則服務(wù)流量切換所需時(shí)間就越長(zhǎng)，涉及到流量切換的場(chǎng)景（故障轉(zhuǎn)移、服務(wù)發(fā)布）給用戶帶來(lái)的體驗(yàn)就越差。

?

為了降低服務(wù)實(shí)例的上下線延遲，Artemis基于WebSocket實(shí)現(xiàn)了服務(wù)實(shí)例的上下線通知功能。通知可以秒級(jí)送達(dá)到服務(wù)消費(fèi)方。這一功能的具體實(shí)現(xiàn)過(guò)程如下：

• 服務(wù)消費(fèi)方在初始化過(guò)程中，會(huì)先經(jīng)Session域名查詢Session的IP地址列表并緩存到本地，然后再?gòu)牧斜碇羞x擇一臺(tái)Session服務(wù)器與之建立 WebSocket長(zhǎng)連接，并發(fā)送服務(wù)訂閱請(qǐng)求。

• Session在收到服務(wù)訂閱請(qǐng)求后，先會(huì)將服務(wù)訂閱信息和 WebSocket 連接的映射關(guān)系存儲(chǔ)到本地。后續(xù)當(dāng)Session收到Data推送的服務(wù)變更消息時(shí)，它會(huì)先從上述映射關(guān)系中查詢?cè)摲?wù)對(duì)應(yīng)的變更訂閱方（即對(duì)應(yīng)的WebSocket 連接列表），然后將消息通過(guò)這些連接推送出去。
  

• 在收到服務(wù)變更消息后，服務(wù)消費(fèi)方會(huì)根據(jù)消息的內(nèi)容更新本地緩存中的服務(wù)地址列表。
  

?

4.3.1 服務(wù)實(shí)例上線過(guò)程

圖4-4 服務(wù)實(shí)例上線過(guò)程

如圖 4-4所示，這是一次服務(wù)實(shí)例正常上線過(guò)程，其中包含了服務(wù)注冊(cè)數(shù)據(jù)在 Artemis內(nèi)部的流轉(zhuǎn)過(guò)程。

• 服務(wù)提供方發(fā)送注冊(cè)數(shù)據(jù)給Session。

• Session收到服務(wù)實(shí)例的注冊(cè)數(shù)據(jù)，依據(jù)ServiceID在環(huán)上查找到相應(yīng)的Data節(jié)點(diǎn)列表，再將數(shù)據(jù)寫(xiě)到對(duì)應(yīng)的數(shù)個(gè)Data節(jié)點(diǎn)上。

• Data在收到數(shù)據(jù)后，先將數(shù)據(jù)寫(xiě)入本地緩存，然后推送服務(wù)實(shí)例上線消息給所有的Session節(jié)點(diǎn)。

• Session在收到服務(wù)實(shí)例上線消息后，將消息推送給對(duì)應(yīng)的服務(wù)消費(fèi)方。

• 服務(wù)消費(fèi)方在收到服務(wù)實(shí)例上線消息后，將消息中所包含的服務(wù)地址加入到本地緩存中的服務(wù)地址列表，后續(xù)客戶端 SDK中的負(fù)載均衡模塊將分配部分流量給新上線的服務(wù)實(shí)例。

?

4.3.2 服務(wù)實(shí)例下線過(guò)程

圖4-5服務(wù)實(shí)例正常下線過(guò)程

服務(wù)實(shí)例下線分為正常下線和異常下線兩種情況。正常下線并不會(huì)在服務(wù)消費(fèi)方引起調(diào)用異常，而異常下線則可能會(huì)導(dǎo)致服務(wù)消費(fèi)方出現(xiàn)短時(shí)間的調(diào)用異常。

?

服務(wù)實(shí)例正常下線，一般是通過(guò)監(jiān)聽(tīng)?wèi)?yīng)用程序關(guān)閉事件（如 JVM的 Shutdown Hook），主動(dòng)觸發(fā)服務(wù)實(shí)例注銷操作，將服務(wù)實(shí)例從 Artemis 中刪除。服務(wù)下線大致過(guò)程與服務(wù)上線過(guò)程類似，這里就不再贅述了。

?

圖4-6 服務(wù)異常下線過(guò)程

?

服務(wù)實(shí)例異常下線，是指服務(wù)因意外情況（如宕機(jī)、網(wǎng)絡(luò)中斷或斷電等）而不可用，但沒(méi)有將注冊(cè)數(shù)據(jù)從Artemis中刪除。這些異常的注冊(cè)數(shù)據(jù)，依賴Artemis的健康檢測(cè)機(jī)制進(jìn)行處理。類似于Eureka和etcd等系統(tǒng)中的數(shù)據(jù)過(guò)期機(jī)制，Artemis中的服務(wù)實(shí)例注冊(cè)數(shù)據(jù)以Lease（租約）的形式存在，需要服務(wù)提供方不斷發(fā)送心跳來(lái)續(xù)約。同時(shí) Artemis內(nèi)部會(huì)運(yùn)行一個(gè)異步線程來(lái)自動(dòng)踢出到期的 Lease。異常下線的服務(wù)實(shí)例由于不會(huì)再繼續(xù)上報(bào)心跳，它的注冊(cè)數(shù)據(jù)在一段時(shí)間后（TTL）將自動(dòng)被Artemis清理掉。

?

Artemis也支持用戶在客戶端自定義健康檢測(cè)邏輯，當(dāng)應(yīng)用程序不健康時(shí)，應(yīng)用程序可以主動(dòng)更新服務(wù)提供方的狀態(tài)或停止上報(bào)心跳。那么服務(wù)提供方狀態(tài)又是如何被服務(wù)消費(fèi)方感知到的呢？當(dāng)服務(wù)提供方注冊(cè)數(shù)據(jù)修改后，服務(wù)注冊(cè)數(shù)據(jù)會(huì)生成一個(gè)新的版本號(hào)（單調(diào)遞增），并在下一次上報(bào)心跳時(shí)，發(fā)送給Artemis。Artemis在收到服務(wù)提供方的心跳后，會(huì)先檢查心跳中服務(wù)注冊(cè)數(shù)據(jù)的版本號(hào)。如果該版本號(hào)大于本地Lease中的服務(wù)注冊(cè)數(shù)據(jù)版本號(hào)，Artemis就會(huì)更新Lease中的服務(wù)注冊(cè)數(shù)據(jù)，并生成一條服務(wù)變化消息，逐級(jí)經(jīng)Data、Session 推送給服務(wù)消費(fèi)方。

?

五、小結(jié)

本文介紹了攜程的微服務(wù)注冊(cè)中心架構(gòu)演進(jìn)迭代過(guò)程，并重點(diǎn)介紹了當(dāng)前版本服務(wù)注冊(cè)中心（Artemis）的架構(gòu)，以及海量數(shù)據(jù)存儲(chǔ)和服務(wù)秒級(jí)上下線機(jī)制的實(shí)現(xiàn)。在攜程微服務(wù)架構(gòu)演進(jìn)的過(guò)程中，服務(wù)發(fā)現(xiàn)的主要方式從手工維護(hù)，逐步過(guò)渡到自注冊(cè)和自發(fā)現(xiàn)，解決了注冊(cè)地址的維護(hù)復(fù)雜性問(wèn)題。負(fù)載均衡的主要實(shí)現(xiàn)方式也從外部設(shè)備的負(fù)載均衡，逐步過(guò)渡到在應(yīng)用程序內(nèi)嵌代理（SDK）的軟件負(fù)載均衡，解決了單點(diǎn)問(wèn)題和性能問(wèn)題，但同時(shí)也帶來(lái)了多語(yǔ)言、多版本SDK維護(hù)的復(fù)雜性問(wèn)題。

?

現(xiàn)在，攜程正在構(gòu)建全新的 ServiceMesh 平臺(tái)，計(jì)劃以K8s替換Artemis來(lái)作為服務(wù)的注冊(cè)中心，并通過(guò) sidecar模式將服務(wù)發(fā)現(xiàn)、負(fù)載均衡以及一些切面功能（例如熔斷、限流、監(jiān)控等）從SDK中剝離出來(lái)，使得這些功能可以獨(dú)立于用戶應(yīng)用外進(jìn)行更新升級(jí)。ServiceMesh 與云原生技術(shù)的推廣，將極大的提升服務(wù)的治理效率，為攜程的微服務(wù)開(kāi)發(fā)者和使用者帶來(lái)更上一層樓的使用體驗(yàn)。

?

參考文檔

1、https://github.com/netflix/eureka

2、https://github.com/sofastack/sofa-registry

團(tuán)隊(duì)招聘信息

我們是平臺(tái)研發(fā)中心，一個(gè)為攜程快速發(fā)展提供各類基礎(chǔ)產(chǎn)品和服務(wù)的平臺(tái)，我們以技術(shù)驅(qū)動(dòng)提升客戶體驗(yàn)，提升跨團(tuán)隊(duì)協(xié)作效率。

?

我們擁有優(yōu)秀而強(qiáng)大的團(tuán)隊(duì)，引導(dǎo)你學(xué)習(xí)業(yè)內(nèi)領(lǐng)先的開(kāi)發(fā)技術(shù)，與技術(shù)高手交流對(duì)話，學(xué)習(xí)切磋。在億級(jí)用戶嚴(yán)苛的品質(zhì)要求中，激發(fā)你腦中不斷涌現(xiàn)的創(chuàng)新思維，帶領(lǐng)你體驗(yàn)飛速成長(zhǎng)的驚喜快樂(lè)，并在各種機(jī)遇與挑戰(zhàn)中發(fā)展自我，成就自身。

?

目前我們前端、后臺(tái)、算法、測(cè)試等技術(shù)崗位均有職位。簡(jiǎn)歷投遞：tech@trip.com，郵件標(biāo)題：【姓名】-【攜程平臺(tái)研發(fā)中心】-【投遞職位】

【推薦閱讀】

• 日訪問(wèn)過(guò)億，辦公I(xiàn)M及開(kāi)放式平臺(tái)在攜程的實(shí)踐

• 多業(yè)務(wù)線億級(jí)體量，攜程是怎么做賬務(wù)中臺(tái)的

• 分布式緩存與DB秒級(jí)一致設(shè)計(jì)實(shí)踐

• 攜程多語(yǔ)言平臺(tái)-Shark系統(tǒng)的高可用演進(jìn)之路

?“攜程技術(shù)”公眾號(hào)

? 分享，交流，成長(zhǎng)

總結(jié)

以上是生活随笔為你收集整理的干货 | 秒级上下线，携程服务注册中心架构演进的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問(wèn)題。

如果覺(jué)得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。