天貓精靈Sound Pro體驗(yàn)：智能音箱沒有音質(zhì)？來聽聽我的
這幾年除了手機(jī)作為智能生活終端最主要的核心之外，第二個(gè)可以成為中心點(diǎn)的產(chǎn)品是什么？——是智能音箱。 手機(jī)在執(zhí)行命令的時(shí)候有兩種操作方式，手和智能語音助手，而智能音箱只
Siegfried，攜程軟件技術(shù)專家，負(fù)責(zé)攜程注冊中心的研發(fā)。
目前，攜程大部分業(yè)務(wù)已經(jīng)完成了微服務(wù)改造，基本架構(gòu)如圖。每一個(gè)微服務(wù)的實(shí)例都需要和注冊中心進(jìn)行通訊：服務(wù)端實(shí)例向注冊中心注冊自己的服務(wù)地址，客戶端實(shí)例通過向注冊中心查詢得知服務(wù)端地址，從而完成遠(yuǎn)程調(diào)用。同時(shí)，客戶端會(huì)訂閱自己關(guān)心的服務(wù)端地址，當(dāng)服務(wù)端發(fā)生變更時(shí)，客戶端會(huì)收到變更消息，觸發(fā)自己重新查詢服務(wù)端地址。
疫情剛過去那會(huì)，公司業(yè)務(wù)回暖跡象明顯，微服務(wù)實(shí)例總數(shù)在1個(gè)月左右的時(shí)間里上漲30%，個(gè)別服務(wù)的單服務(wù)實(shí)例數(shù)在業(yè)務(wù)高峰時(shí)可達(dá)萬級別。按照這個(gè)勢頭，預(yù)計(jì)全公司實(shí)例總數(shù)可能會(huì)在短時(shí)間內(nèi)翻倍。
實(shí)例數(shù)變大會(huì)引起連接數(shù)變大，請求量變高，網(wǎng)絡(luò)報(bào)文變大等一系列現(xiàn)象，對注冊中心的性能產(chǎn)生挑戰(zhàn)。
如果注冊中心遇到性能瓶頸或是運(yùn)行不穩(wěn)定，從業(yè)務(wù)視角看，這會(huì)導(dǎo)致新增的實(shí)例無法及時(shí)接入流量，以至被調(diào)方緊急擴(kuò)容見效慢；或者導(dǎo)致下線的實(shí)例不能被及時(shí)拉出，以至調(diào)用方業(yè)務(wù)訪問到已下線的實(shí)例產(chǎn)生報(bào)錯(cuò)。
如今，業(yè)務(wù)回暖已經(jīng)持續(xù)接近2年，攜程注冊中心穩(wěn)定運(yùn)行，強(qiáng)勁地支撐業(yè)務(wù)復(fù)蘇與擴(kuò)張，特別是支撐了業(yè)務(wù)日常或緊急情況下短時(shí)間內(nèi)大量擴(kuò)縮容的場景。今天就來簡單介紹一下攜程注冊中心的整體架構(gòu)和設(shè)計(jì)取舍。
攜程注冊中心采用兩層結(jié)構(gòu)，分為和數(shù)據(jù)層(Data)和會(huì)話層(Session)。Data負(fù)責(zé)存放被調(diào)方的元信息與實(shí)例狀態(tài)、計(jì)算RPC調(diào)用相關(guān)的路由策略。Session與SDK直接通訊，負(fù)責(zé)扛連接數(shù)，聚合轉(zhuǎn)發(fā)SDK發(fā)起的心跳/查詢請求。
注冊 – 定時(shí)心跳
微服務(wù)架構(gòu)下，服務(wù)端的一個(gè)實(shí)例（ 被調(diào)方）想要被客戶端（調(diào)用方）感知，它需要將自己注冊到注冊中心里。服務(wù)端實(shí)例會(huì)發(fā)起5秒1次的心跳請求，由Session轉(zhuǎn)發(fā)到對應(yīng)分片的Data。如果數(shù)據(jù)層能夠持續(xù)不斷的收到一個(gè)實(shí)例的心跳請求，那么數(shù)據(jù)層就會(huì)判斷這個(gè)實(shí)例是健康的。
與此同時(shí)，數(shù)據(jù)層會(huì)對這一份數(shù)據(jù)設(shè)置TTL，一旦超過TTL沒有收到后續(xù)的心跳請求，那么這份數(shù)據(jù)也就會(huì)被判定為過期。也就是說，注冊中心認(rèn)為對應(yīng)的這個(gè)實(shí)例不應(yīng)再被調(diào)方繼續(xù)訪問了。
發(fā)現(xiàn) - 事件推送/保底輪詢
當(dāng)收到新實(shí)例的第一個(gè)心跳時(shí)，數(shù)據(jù)層會(huì)產(chǎn)生一個(gè)NEW事件，相對應(yīng)地，當(dāng)實(shí)例信息過期時(shí)，數(shù)據(jù)層會(huì)產(chǎn)生一個(gè)DELETE事件。NEW/DELETE事件會(huì)通過SDK發(fā)起的訂閱連接通知到調(diào)用方。
由于網(wǎng)絡(luò)等一些不可控的因素，事件推送是有可能丟失，因而SDK也會(huì)定時(shí)地發(fā)起全量查詢請求，以彌補(bǔ)可能丟失的事件。
多分片方案
如圖所示，Data被分成了多分片，不同分片的數(shù)據(jù)互不重復(fù)，從而解決了單臺Data的垂直瓶頸問題（比如內(nèi)存大小、心跳QPS等）。
Session會(huì)對服務(wù)ID進(jìn)行哈希，根據(jù)哈希結(jié)果將心跳請求、訂閱請求、查詢請求分發(fā)到對應(yīng)的Data分片中。調(diào)用方SDK對多個(gè)被調(diào)方進(jìn)行信息查詢時(shí)，可能會(huì)涉及到多個(gè)Data分片，那么Session會(huì)發(fā)起多個(gè)請求，并最終負(fù)責(zé)將所有必要信息聚合起來一并返回給客戶端。
單點(diǎn)故障
與很多其他系統(tǒng)類似，注冊中心也會(huì)遇到故障/維護(hù)等場景從而遭遇單點(diǎn)故障。我們把具體情況分為Data單點(diǎn)故障和Session單點(diǎn)故障，在兩種情況下，我們都需要保證系統(tǒng)整體的可用性。
單點(diǎn)故障 – Data
如圖所示，SDK發(fā)起的心跳請求會(huì)被復(fù)制到多臺Data上，以保證同一分片中每一臺Data的數(shù)據(jù)完整性。也就是說，同一個(gè)分片的每臺Data都會(huì)擁有該分片對應(yīng)的所有服務(wù)的數(shù)據(jù)。當(dāng)任一Data出現(xiàn)故障，或是參與到日常運(yùn)維被踢出集群的情況下，其他任一Data能夠很好的接替它的工作。
這樣的多寫機(jī)制相比于之前版本注冊中心采用的Data間復(fù)制機(jī)制更加簡單。在Data層發(fā)生故障時(shí)，當(dāng)前方案對于集群的物理影響會(huì)更小，可以做到無需物理切換，因而也更加可靠。
在當(dāng)前多寫機(jī)制下，Data層的數(shù)據(jù)是最終一致的。心跳請求被分成多個(gè)副本后是陸續(xù)到達(dá)各個(gè)Data實(shí)例的，在實(shí)例發(fā)生上線或者下線時(shí)，每臺data變更產(chǎn)生的時(shí)間點(diǎn)通常會(huì)略有不同。
為了盡可能避免上述情況對調(diào)用方產(chǎn)生影響，每臺Session會(huì)在每個(gè)Data分片中選擇一臺Data進(jìn)行粘滯。同時(shí)，SDK對Session也會(huì)盡可能地粘滯。
單點(diǎn)故障 – Session
參考上文提到Data分片方案，任一Session都可以獲取到所有Data分片的數(shù)據(jù)，所有Session節(jié)點(diǎn)都具備相同的能力。
因此，任一Session故障時(shí)，SDK只需要切換到其他Session即可。
集群自發(fā)現(xiàn)
攜程注冊中心是基于Redis做集群自發(fā)現(xiàn)的。如下圖所示，Redis維護(hù)了所有注冊中心實(shí)例的信息。當(dāng)一個(gè)注冊中心實(shí)例被創(chuàng)建時(shí)，新實(shí)例首先會(huì)向Redis索要所有其他實(shí)例的信息，同時(shí)開始持續(xù)對Redis發(fā)起心跳請求，于是Redis維護(hù)的實(shí)例信息中也會(huì)新增新實(shí)例。新實(shí)例還會(huì)根據(jù)從Redis拿到的數(shù)據(jù)向其他注冊中心實(shí)例發(fā)起內(nèi)部的心跳請求。一旦其他實(shí)例從Redis獲得了新實(shí)例的信息，再加上收到的心跳，就會(huì)認(rèn)可新實(shí)例加入集群。
如下圖所示，當(dāng)時(shí)注冊中心實(shí)例需要維護(hù)或故障時(shí)，實(shí)例停止運(yùn)行后不再發(fā)起內(nèi)部心跳。其他實(shí)例在該節(jié)點(diǎn)的內(nèi)部心跳過期后，標(biāo)記該節(jié)點(diǎn)為unhealthy，并在任何功能中都不會(huì)再使用該節(jié)點(diǎn)。這里有一個(gè)細(xì)節(jié)，節(jié)點(diǎn)下線不會(huì)參考Redis側(cè)的數(shù)據(jù)，Redis故障無法響應(yīng)查詢請求時(shí)，所有注冊中心實(shí)例都以兩兩心跳為準(zhǔn)。
我們可以了解到，注冊中心實(shí)例的上線是強(qiáng)依賴Redis的，但是運(yùn)行時(shí)并不依賴Redis。在Redis故障和運(yùn)維時(shí)，注冊中心的基本功能不受影響，只是無法進(jìn)行擴(kuò)容。
新增代理還是Smart SDK？
注冊中心設(shè)計(jì)之初只有Data一層，由于要引入分片機(jī)制，才有了Session。那么是不是也可以把分片的邏輯做到SDK，而不引入Session這一層呢？
這也是一種方式，業(yè)界也一直有著代理和Smart SDK之爭。我們基于注冊中心所對應(yīng)的業(yè)務(wù)場景，認(rèn)為新增一層代理是更加合適的。
最重要的一點(diǎn)，注冊中心的相關(guān)功能運(yùn)行不在BU業(yè)務(wù)邏輯主鏈路上，其響應(yīng)時(shí)間并非直接影響業(yè)務(wù)的響應(yīng)時(shí)間。因此我們對注冊中心的請求響應(yīng)時(shí)間并沒有極致的要求，代理層引入的幾百微秒的延遲可以被接受。
其次注冊中心的請求是一定程度容忍失敗的，SDK請求數(shù)據(jù)失敗后可以繼續(xù)使用內(nèi)存中的老數(shù)據(jù)，不會(huì)對業(yè)務(wù)線產(chǎn)生致命影響。因此代理層引入的失敗率也可以被接受。
另一側(cè)，代理的加入帶來了諸多好處。最直接地，落地分片邏輯不需要所有的SDK升級，分片邏輯迭代時(shí)，對業(yè)務(wù)也是無感。
其次，代理層也隔離了連接數(shù)這一瓶頸，當(dāng)SDK層的實(shí)例不斷變多，連接數(shù)不斷增加時(shí)，只需要擴(kuò)容代理層就能解決連接數(shù)的問題。這也是我們將它取名為Session的原因。
同時(shí)，我們也希望作為物理層的SDK邏輯更加輕量，比較重的邏輯放在邏輯層，這樣穩(wěn)定性更強(qiáng)更不容易出錯(cuò)。比如后續(xù)會(huì)提到的“Data按業(yè)務(wù)隔離分組”就是在Session層實(shí)現(xiàn)的。
普通哈希還是一致性哈希？
攜程注冊中心的數(shù)據(jù)分片是采用普通哈希的，并沒有采用一致性哈希。
我們知道，一致性哈希相比普通哈希的最大賣點(diǎn)是當(dāng)節(jié)點(diǎn)數(shù)量變化時(shí)，不需要遷移所有數(shù)據(jù)。
結(jié)合注冊中心的場景，我們用服務(wù)ID做哈希，而服務(wù)數(shù)量（也包括實(shí)例數(shù)量）是相對穩(wěn)定的，因此哈希節(jié)點(diǎn)的擴(kuò)容周期會(huì)比較長，基本用不到一致性哈希的優(yōu)勢特性。哪怕一段時(shí)間內(nèi)業(yè)務(wù)迅速擴(kuò)張，只要提前做好預(yù)估，留好余量一次性擴(kuò)容就好了。
我們選擇普通的固定的哈希，并讓每一個(gè)分片都具備多個(gè)備份節(jié)點(diǎn)，這樣就基本可以認(rèn)為每個(gè)分片都不會(huì)徹底掛掉，不用去實(shí)現(xiàn)數(shù)據(jù)遷移的邏輯，整個(gè)機(jī)制更簡單了。
要知道，數(shù)據(jù)遷移需要對注冊請求、查詢請求和訂閱請求進(jìn)行同步切換，要處理好各種狀態(tài)，避免在數(shù)據(jù)遷移過程中錯(cuò)查到空數(shù)據(jù)或者丟失變更事件，非常復(fù)雜危險(xiǎn)。
自發(fā)現(xiàn)是否強(qiáng)依賴Redis？
前面也提到，注冊中心自發(fā)現(xiàn)的運(yùn)行時(shí)是不依賴Redis的。有的同學(xué)可能會(huì)想到，如果運(yùn)行時(shí)強(qiáng)依賴Redis，就可以去掉兩兩注冊了。
兩兩注冊確實(shí)是一個(gè)不好的設(shè)計(jì)，隨著集群的節(jié)點(diǎn)數(shù)越來越大，其產(chǎn)生的性能開銷肯定也會(huì)更大，影響整個(gè)注冊中心集群的拓展能力。
但在目前規(guī)模下，內(nèi)部心跳占用的系統(tǒng)資源并不可觀。哪怕規(guī)模再拓展，通過降低心跳的頻率，進(jìn)一步降低資源開銷。
最大的好處是，Redis集群故障或者維護(hù)時(shí)，并不會(huì)對注冊中心的功能產(chǎn)生影響。
基于Redis還是用Java寫？
目前注冊中心的Data是用Java實(shí)現(xiàn)的。有的同學(xué)可能會(huì)想，Data層主要就是維護(hù)微服務(wù)實(shí)例的存活狀態(tài)，能不能直接用Redis實(shí)現(xiàn)呢？如果用Redis，不就可以直接復(fù)用Redis體系的擴(kuò)容/切換能力了嗎？
比如基于Redis 6.0的Client Cache功能，通過Invalidate機(jī)制通知SDK重新更新服務(wù)信息。
不過在攜程注冊中心設(shè)計(jì)之初，Redis版本還比較老，沒有這些新feature，感覺基于pub/sub機(jī)制做注冊中心還挺麻煩的。現(xiàn)在注冊中心已經(jīng)穩(wěn)定運(yùn)行了好久，加了很多功能，比如路由策略一部分的計(jì)算過程就是在Data層完成的，暫時(shí)沒有必要推倒重建。
總的來說，用Java寫更可控，后續(xù)自定義程度更高。
突發(fā)流量
在遇到節(jié)假日，或是公司促銷活動(dòng)，亦或是友商故障的情況下，公司集群會(huì)因?yàn)闃I(yè)務(wù)量急劇上升而迅速自動(dòng)擴(kuò)容，因而注冊中心會(huì)受到強(qiáng)勁的流量沖擊。
期間因?yàn)橄到y(tǒng)資源被榨干，注冊/發(fā)現(xiàn)請求可能會(huì)偶發(fā)失敗，事件推送延遲和丟失率會(huì)上升。嚴(yán)重時(shí)，部分調(diào)用方業(yè)務(wù)會(huì)無法及時(shí)感知到被調(diào)方的變動(dòng)，從而導(dǎo)致請求失敗，或流量無法被分?jǐn)偟叫聰U(kuò)容的被調(diào)方實(shí)例。
我們發(fā)現(xiàn)，這些場景產(chǎn)生的流量有著很高的重復(fù)度，比如某個(gè)被調(diào)方實(shí)例擴(kuò)容，調(diào)用方的眾多實(shí)例需要知道的信息是完全一樣的，又比如調(diào)用方實(shí)例擴(kuò)容，這些新擴(kuò)的實(shí)例部署著相同的代碼，它們依賴的被調(diào)方信息也是完全一樣的。
因此我們針對性的做了不少聚合與去重，大大降低了突發(fā)流量情況下的資源開銷。
流量不均衡
關(guān)于Data粘滯，這里有一個(gè)細(xì)節(jié)。那么多Data機(jī)器，Session選誰呢？目前Session是用類似隨機(jī)的方式選擇Data的。那就會(huì)有一個(gè)場景，我們對Data層進(jìn)行版本更替，逐個(gè)實(shí)例重新發(fā)布，當(dāng)一個(gè)實(shí)例被重置時(shí)，Session就會(huì)因?yàn)閬G失粘滯對象而重新隨機(jī)選擇。
我們會(huì)發(fā)現(xiàn)，最后一個(gè)Data實(shí)例完成發(fā)布時(shí)，它不會(huì)被任何Session選中。而第一個(gè)發(fā)布的Data實(shí)例，它傾向于被更多的Session選中。
通常來說，越早發(fā)布的Data實(shí)例，就會(huì)被越多的Session選中。也正因?yàn)槿绱耍绨l(fā)布的Data會(huì)承擔(dān)更多的流量，而最后發(fā)布的Data一般不承擔(dān)流量。這顯然是不合理的。
解決這個(gè)問題的方法也很簡單，我們引入擁有全局視角的第三者，整體調(diào)控Session的粘滯，保證Data盡可能地被相同數(shù)量的Session選中。
全局風(fēng)險(xiǎn)
前面也提到，Data層被分成了多分片，Session會(huì)對服務(wù)ID進(jìn)行哈希，將心跳請求、訂閱請求、查詢請求分發(fā)到對應(yīng)的Data層分片中。
當(dāng)程序出現(xiàn)預(yù)期外的問題（程序bug，OOM等等）導(dǎo)致某個(gè)Data無法正常的履行功能職責(zé)時(shí)，那些被分配到這個(gè)Data實(shí)的服務(wù)就會(huì)受到影響。
如果調(diào)配方式是對服務(wù)ID做哈希，那么所有業(yè)務(wù)線的任意服務(wù)都可能參與其中，從業(yè)務(wù)視角去看，就是整個(gè)公司都受到了影響。
對服務(wù)ID做哈希是有它的優(yōu)勢的，它無需引入過多的外部依賴，只需要一小段代碼就能工作。但我們還是認(rèn)為避免全局故障更加重要。
因此我們最近對Data引入了業(yè)務(wù)語義，將Data分為多個(gè)組，以各個(gè)業(yè)務(wù)線命名。且我們可以按服務(wù)粒度對數(shù)據(jù)進(jìn)行分配。默認(rèn)情況下，我們會(huì)將服務(wù)分配到自己BU的分組上。
這樣，我們就具備了以下能力：
1）不同業(yè)務(wù)線的數(shù)據(jù)可以被很好的隔離，任一業(yè)務(wù)線的Data數(shù)據(jù)出現(xiàn)問題，不會(huì)影響到其他業(yè)務(wù)線。
2）注冊中心將獲得故障切換的能力，當(dāng)個(gè)別服務(wù)的數(shù)據(jù)出現(xiàn)問題時(shí)，我們可以將它單獨(dú)切走。
3）我們可以將一些不重要的應(yīng)用單獨(dú)隔離到一個(gè)灰度分組，新代碼可以先發(fā)布到灰度分組上，盡可能避免新代碼引入的問題直接影響核心業(yè)務(wù)分組。
4）注冊中心將獲得應(yīng)用粒度的部署能力。在集群分配上，具備更強(qiáng)的靈活度，針對業(yè)務(wù)規(guī)模的大小合理分配系統(tǒng)資源。
從圖中可以看到，我們在引入分組邏輯的同時(shí)也兼容老的分片邏輯，這樣做是為了在分組邏輯上線過程初期，服務(wù)信息在Data層的分布可以盡可能保持不變，可以讓少數(shù)的服務(wù)先灰度切換到新增的分組上進(jìn)行驗(yàn)證。
當(dāng)然，從去復(fù)雜度的角度考慮，最終分片邏輯還是要下線，垂直擴(kuò)容的能力也可以由分組實(shí)現(xiàn)。
因?yàn)樽灾行囊肓朔纸M機(jī)制，并對各個(gè)業(yè)務(wù)線數(shù)據(jù)進(jìn)行了隔離，注冊中心的集群規(guī)模也在因此膨脹，分組數(shù)量較多，運(yùn)維成本也隨之上升。
后續(xù)我們計(jì)劃進(jìn)一步優(yōu)化優(yōu)化單機(jī)性能，精簡優(yōu)化一些不必要的機(jī)制，降低機(jī)器數(shù)量。
同時(shí)，我們也希望注冊中心能夠支持彈性，能夠在業(yè)務(wù)高峰時(shí)自動(dòng)擴(kuò)容，在業(yè)務(wù)低峰時(shí)自動(dòng)縮容。
本文鏈接：http://www.tebozhan.com/showinfo-26-99174-0.html攜程注冊中心整體架構(gòu)與設(shè)計(jì)取舍
聲明：本網(wǎng)頁內(nèi)容旨在傳播知識，若有侵權(quán)等問題請及時(shí)與本網(wǎng)聯(lián)系，我們將在第一時(shí)間刪除處理。郵件：2376512515@qq.com
Copyright ? 2016-2023 天津谷騏科技有限公司 版權(quán)所有 sitemap.xml
違法及侵權(quán)請聯(lián)系：2376512515@qq.com 津ICP備18001702號
津公網(wǎng)安備 12010102000574號