本文主要介紹微服務(wù)架構(gòu)流量分布(微服務(wù)流量著色)，下面一起看看微服務(wù)架構(gòu)流量分布(微服務(wù)流量著色)相關(guān)資訊。
簡(jiǎn)介:絕大多數(shù)的軟件生產(chǎn)安全事故都發(fā)生在生產(chǎn)線的發(fā)布階段，雖然遵循灰度、可觀察、可滾動(dòng)的生產(chǎn)安全斧的行業(yè)慣例，可以最大限度地避免生產(chǎn)代碼的問(wèn)題對(duì)用戶(hù)造成的影響。但仍然解決了并發(fā)流量情況下的短時(shí)流量損失問(wèn)題。因此，本文將重點(diǎn)研究如何解決釋放過(guò)程中的流量損失問(wèn)題，實(shí)現(xiàn)釋放過(guò)程中上下行效果的損失。?
作者|程普來(lái)源|阿里開(kāi)發(fā)者官方賬號(hào)
絕大多數(shù)的軟件生產(chǎn)安全事故都發(fā)生在應(yīng)用線的發(fā)布階段，雖然遵循灰度、可觀察、可滾動(dòng)的安全生產(chǎn)三軸的行業(yè)慣例，可以最大限度地避免發(fā)布過(guò)程中應(yīng)用代碼問(wèn)題對(duì)用戶(hù)造成的影響，但仍然解決了并發(fā)流量情況下的短時(shí)流量損失問(wèn)題。因此，本文將重點(diǎn)研究如何解決釋放過(guò)程中的流量損失問(wèn)題，實(shí)現(xiàn)釋放過(guò)程中上下行效果的損失。
據(jù)統(tǒng)計(jì)，裝卸過(guò)程中經(jīng)常發(fā)生事故，有時(shí)是因?yàn)榫幋a問(wèn)題。但是有時(shí)候我們會(huì)發(fā)現(xiàn)，雖然代碼本身沒(méi)有問(wèn)題，但是在線上線下發(fā)布的過(guò)程中還是會(huì)出現(xiàn)短時(shí)間的服務(wù)調(diào)試錯(cuò)誤，比如連接被拒絕，調(diào)試時(shí)沒(méi)有實(shí)例。相關(guān)問(wèn)題產(chǎn)生的原因，有相關(guān)發(fā)布經(jīng)驗(yàn)的同學(xué)可能或多或少都有所了解，而經(jīng)濟(jì)學(xué)家發(fā)現(xiàn)，這類(lèi)問(wèn)題在流量高峰時(shí)尤為明顯，在深夜流量較低的時(shí)候比較少見(jiàn)，所以很多人為了避免網(wǎng)絡(luò)發(fā)布事故，選擇在深夜發(fā)布。本節(jié)將介紹這些問(wèn)題背后的真正原因，以及業(yè)界相應(yīng)的設(shè)計(jì)案例。交通損失的常見(jiàn)原因包括但不限于以下幾種:
服務(wù)規(guī)律及時(shí)離線:服務(wù)消費(fèi)者在注冊(cè)時(shí)感知到服務(wù)列表存在延遲，導(dǎo)致服務(wù)消費(fèi)者在注銷(xiāo)特定實(shí)例后的一定時(shí)間內(nèi)仍然調(diào)整離線實(shí)例而導(dǎo)致的請(qǐng)求錯(cuò)誤。緩慢初始化:接收線路上的流量應(yīng)該剛剛開(kāi)始加載初始資源。由于流量太大，初始化過(guò)程緩慢，響應(yīng)流量請(qǐng)求超時(shí)，阻塞，資源耗盡，導(dǎo)致機(jī)器一開(kāi)始就停了。注冊(cè)太早:服務(wù)存在資源加載不同步的問(wèn)題。當(dāng)服務(wù)沒(méi)有完全初始化時(shí)，就在注冊(cè)中注冊(cè)，導(dǎo)致請(qǐng)求響應(yīng)慢，超時(shí)出錯(cuò)的現(xiàn)象。發(fā)布狀態(tài)和運(yùn)輸狀態(tài)不正確:kubernetes的滾動(dòng)發(fā)布功能被啟用為發(fā)布，因?yàn)榕ckubernetes 滾動(dòng)釋放是通過(guò)檢查是否應(yīng)該啟動(dòng)特定終端作為準(zhǔn)備就緒的標(biāo)志來(lái)觸發(fā)的。批量實(shí)例發(fā)布，但是在微服務(wù)應(yīng)用中，只有在應(yīng)該完成服務(wù)注冊(cè)的情況下才能提供服務(wù)調(diào)整。因此，在某些情況下，新應(yīng)用程序在注冊(cè)之前會(huì)處于離線狀態(tài)，從而導(dǎo)致服務(wù)可用。接下來(lái)，將分別介紹如何避免離線和在線過(guò)程中的流量損失。
無(wú)損離線由于微服務(wù)應(yīng)用本身的調(diào)用特性，在高并發(fā)下，服務(wù)提供者的應(yīng)用實(shí)例直接離線，會(huì)導(dǎo)致服務(wù)消費(fèi)者的應(yīng)用實(shí)例無(wú)法實(shí)時(shí)感知下游實(shí)例的實(shí)時(shí)狀態(tài)，所以會(huì)繼續(xù)將請(qǐng)求轉(zhuǎn)發(fā)給離線實(shí)例，造成請(qǐng)求錯(cuò)誤和流量損失。
?
圖1春云根據(jù)《消法》及時(shí)感知提供者線下服務(wù)。
例如，對(duì)于spring cloud，應(yīng)該如上面的圖1所示。當(dāng)兩個(gè)實(shí)例a 而a是離線的，因?yàn)閟pring云框架旨在平衡可用性和性能，消費(fèi)者會(huì)默認(rèn)注冊(cè)30s來(lái)拉最新的服務(wù)列表，所以實(shí)例a的離線無(wú)法實(shí)時(shí)感知。當(dāng)流量較大時(shí)，消費(fèi)者會(huì)繼續(xù)通過(guò)本地緩存調(diào)整離線實(shí)例a，造成流量損失。基于上述背景，業(yè)界提出了相應(yīng)的輸線下(也稱(chēng)優(yōu)雅線下)技術(shù)案例來(lái)應(yīng)對(duì)上述問(wèn)題。本節(jié)將介紹一些業(yè)界主流的線下技術(shù)。
針對(duì)這類(lèi)問(wèn)題，業(yè)內(nèi)普遍的解決方案是將應(yīng)用更新過(guò)程分為手動(dòng)接流量、停止應(yīng)用更新重啟三個(gè)步驟?？蛻?hù)端通過(guò)手動(dòng)操作來(lái)避免調(diào)用離線實(shí)例簡(jiǎn)單有效，但是有很多限制:不僅需要流量控制能力來(lái)實(shí)現(xiàn)實(shí)時(shí)流量揀選，還需要人工判斷來(lái)確保在途請(qǐng)求在停止應(yīng)用之前已經(jīng)處理完畢。這種需要人工干預(yù)的方法，運(yùn)維復(fù)雜度高，只適合小規(guī)模應(yīng)用。無(wú)法解決當(dāng)前云原生架構(gòu)中實(shí)例離線過(guò)程中的流量損失問(wèn)題，如自動(dòng)彈性伸縮、滾動(dòng)升級(jí)等。本節(jié)將介紹一些業(yè)界在云原生場(chǎng)景下應(yīng)用的無(wú)損離線技術(shù)方案。
1個(gè)活動(dòng)通知
一般注冊(cè)中心會(huì)提供一個(gè)主動(dòng)注銷(xiāo)接口，供微服務(wù)應(yīng)用在正常關(guān)閉時(shí)調(diào)用，以便離線實(shí)例及時(shí)在注冊(cè)中心更新?tīng)顟B(tài)。在一些基于事件感知注冊(cè)服務(wù)列表的微服務(wù)框架中的主動(dòng)注銷(xiāo)，如dubbo，可以使上游服務(wù)消費(fèi)者感知到提供者 以避免對(duì)脫機(jī)實(shí)例的后續(xù)調(diào)用。而對(duì)于spring cloud等微服務(wù)框架的服務(wù)消費(fèi)者，則是通過(guò)定時(shí)拉取服務(wù)清單來(lái)實(shí)現(xiàn)的。雖然線下實(shí)例已經(jīng)通過(guò)注冊(cè)中心的主動(dòng)注銷(xiāo)接口更新了自己在注冊(cè)中心的申請(qǐng)狀態(tài)信息，但是由于上游消費(fèi)者下次需要拉取注冊(cè)中心的申請(qǐng)列表，消費(fèi)者感知注冊(cè)中心實(shí)例的變化會(huì)有延遲。在高流量、高并發(fā)的場(chǎng)景下，當(dāng)實(shí)例離線時(shí)，仍然沒(méi)有實(shí)現(xiàn)流量無(wú)損的方法。由于現(xiàn)有的消費(fèi)者實(shí)例不可能通過(guò)注冊(cè)中心實(shí)時(shí)感知下游服務(wù)商的變化，業(yè)界提出用主動(dòng)通知來(lái)解決這類(lèi)問(wèn)題。主動(dòng)通知過(guò)程如下面的圖2所示:
?
圖2損失線案例
如圖2所示，服務(wù)提供商b的實(shí)例不能被上游消費(fèi)者a實(shí)時(shí)感知，以避免在離線時(shí)調(diào)用離線實(shí)例的問(wèn)題。在接收到離線命令之前，提供者b會(huì)在離線等待階段接收到的請(qǐng)求的返回值中添加特殊標(biāo)記，讓服務(wù)消費(fèi)者在接收到返回值并識(shí)別相關(guān)標(biāo)記后，主動(dòng)拉一次注冊(cè)中心的服務(wù)實(shí)例，從而實(shí)時(shí)感知實(shí)例b的最新?tīng)顟B(tài)，讓服務(wù)消費(fèi)者實(shí)時(shí)感知服務(wù)提供者的離線狀態(tài)。
2適應(yīng)性等待
在不同并發(fā)的場(chǎng)景下，主動(dòng)通知可以解決大部分離線流量受損的問(wèn)題。但是對(duì)于并發(fā)流量應(yīng)該離線的場(chǎng)景，如果主動(dòng)完成通知，可能還會(huì)有一些在途請(qǐng)求需要處理后才能離線，否則這些流量會(huì)得到正常響應(yīng)。為了解決這種在途請(qǐng)求的問(wèn)題，可以通過(guò)在處理所有在途請(qǐng)求之前給下行線一個(gè)自適應(yīng)等待機(jī)制來(lái)實(shí)現(xiàn)流量損失。
?
圖3自適應(yīng)等待機(jī)制
如上面的圖3所示，自適應(yīng)等待機(jī)制通過(guò)計(jì)算是否還有未處理的傳輸中的請(qǐng)求來(lái)確定注銷(xiāo)時(shí)間，以便在注銷(xiāo)之前處理完所有剩余的請(qǐng)求。
無(wú)損在線延遲加載是軟件框架設(shè)計(jì)過(guò)程中最常見(jiàn)的策略。例如，在spring cloud框架中，默認(rèn)情況下會(huì)初始化ribbon組件的pull服務(wù)列表，直到服務(wù)被調(diào)優(yōu)。例如，下面的圖4顯示了通過(guò)在spring cloud中調(diào)優(yōu)?resttemplate對(duì)遠(yuǎn)程服務(wù)進(jìn)行的第一次和第二次調(diào)優(yōu)的耗時(shí)比較:
?
圖4應(yīng)該開(kāi)始資源初始化，并且應(yīng)該匹配正常操作期間的耗時(shí)情況。
從圖4的結(jié)果可以看出，由于一些資源初始化，第二次調(diào)優(yōu)的耗時(shí)是正常情況下的幾倍。因此，在線發(fā)布新的應(yīng)用程序來(lái)直接處理流量是非常容易的，例如對(duì)卷請(qǐng)求的響應(yīng)速度慢、資源擁塞和應(yīng)用程序宕機(jī)。
業(yè)界針對(duì)上述虧損上線場(chǎng)景提出了以下一系列解決方案，包括延遲注冊(cè)、流量服務(wù)預(yù)熱、就緒檢查等。詳細(xì)完整的案例如下圖5所示:
?
圖5受損線路的整體情況
1延遲注冊(cè)
對(duì)于初始化過(guò)程中需要異步加載資源的復(fù)雜啟動(dòng)過(guò)程，由于注冊(cè)通常與初始化過(guò)程同步，所以在應(yīng)用程序完全初始化之前，已經(jīng)在注冊(cè)中注冊(cè)了應(yīng)用程序以供外部使用者調(diào)整。此時(shí)，由于資源加載不完全，直接調(diào)整可能會(huì)導(dǎo)致請(qǐng)求錯(cuò)誤。通過(guò)設(shè)置延遲注冊(cè)，您可以讓?xiě)?yīng)用程序等待，直到它完全初始化。注冊(cè)對(duì)外提供服務(wù)。比如開(kāi)源的微服務(wù)治理框架dubbo，最初就提供了延遲注冊(cè)功能[1]。
2小流量服務(wù)預(yù)熱
在線發(fā)布的場(chǎng)景中，很多時(shí)候新啟動(dòng)的冷系統(tǒng)直接處理卷請(qǐng)求，可能是由于系統(tǒng)內(nèi)部資源初始化不完全，超時(shí)、阻塞，甚至報(bào)錯(cuò)，導(dǎo)致剛發(fā)布就宕機(jī)等在線發(fā)布事故。為了避免這類(lèi)問(wèn)題，業(yè)界根據(jù)不同的框架類(lèi)型和對(duì)應(yīng)的特性設(shè)計(jì)了不同的對(duì)策，比如寫(xiě)腳本促進(jìn)jvm預(yù)熱，ababa group 的內(nèi)部hsf(高速框架)分批發(fā)布，延遲注冊(cè)，通過(guò)模擬腳本預(yù)熱模擬請(qǐng)求，預(yù)熱流量。本節(jié)將介紹最合適的氣流預(yù)熱方法。
與一般場(chǎng)景相比，新發(fā)布的微服務(wù)應(yīng)該與其他正常實(shí)例共享在線總qps。流量預(yù)熱方法通過(guò)根據(jù)每個(gè)服務(wù)提供者實(shí)例的啟動(dòng)時(shí)間計(jì)算服務(wù)消費(fèi)端的權(quán)重，結(jié)合負(fù)載均衡算法控制剛啟動(dòng)的入局流量隨啟動(dòng)時(shí)間逐漸增加到正常水平的過(guò)程，來(lái)幫助剛啟動(dòng)的入局預(yù)熱。詳細(xì)的qps隨時(shí)間的變化曲線如圖6所示:
圖6氣流預(yù)熱過(guò)程的qps曲線
開(kāi)源dubbo實(shí)現(xiàn)的流量服務(wù)預(yù)熱過(guò)程原理如下圖7所示:
?
圖7氣流預(yù)熱過(guò)程示意圖
服務(wù)注冊(cè)時(shí)，服務(wù)提供者通過(guò)元數(shù)據(jù)在注冊(cè)中注冊(cè)預(yù)熱時(shí)間和服務(wù)開(kāi)始時(shí)間，服務(wù)消費(fèi)者在注冊(cè)中訂閱相關(guān)服務(wù)實(shí)例列表，根據(jù)調(diào)整時(shí)的預(yù)熱時(shí)間和開(kāi)始時(shí)間計(jì)算每個(gè)實(shí)例的批量調(diào)整權(quán)重。在起動(dòng)時(shí)間和起動(dòng)時(shí)間之間的時(shí)間差相對(duì)較大的示例權(quán)重下，應(yīng)當(dāng)通過(guò)分配較少的流量給起動(dòng)時(shí)間來(lái)預(yù)熱入口流量。
開(kāi)源dubbo實(shí)現(xiàn)的流量服務(wù)預(yù)熱模型的計(jì)算如下式所示:
模型中，qps應(yīng)用對(duì)應(yīng)的f(x)隨調(diào)用時(shí)間x線性變化，其中x代表調(diào)用時(shí)間，starttime為應(yīng)用啟動(dòng)時(shí)間，warmuptime為用戶(hù)配置的應(yīng)用預(yù)熱時(shí)間，k為常數(shù)，一般代表每個(gè)實(shí)例的默認(rèn)權(quán)重。
?
圖8流量預(yù)熱權(quán)重的計(jì)算
通過(guò)流量預(yù)熱的方法，可以有效解決并發(fā)流量下，資源初始化慢導(dǎo)致的卷請(qǐng)求響應(yīng)慢和阻塞，以及資源耗盡導(dǎo)致啟動(dòng)時(shí)停機(jī)的事故。
3微服務(wù)就緒檢查
在介紹微服務(wù)就緒檢查之前，讓 下面簡(jiǎn)要介紹相關(guān)的kubernetes探頭技術(shù)作為技術(shù)背景，以便更好地理解以下內(nèi)容:
庫(kù)伯內(nèi)es探針技術(shù)
在云領(lǐng)域，為了保證pod在對(duì)外提供服務(wù)前應(yīng)全面啟動(dòng)或在pod出貨過(guò)程中發(fā)生意外后及時(shí)恢復(fù)，kubernetes提供了probe技術(shù)，動(dòng)態(tài)檢測(cè)出貨情況，為保證pod的破損線路和健康出貨提供了保障。
生存探測(cè)器
kubernetes中提供的生存檢測(cè)器，用于檢測(cè)何時(shí)重啟容器。例如，生存檢測(cè)器可以捕獲死鎖(程序正在運(yùn)行，但方法繼續(xù)執(zhí)行下一步)。在這種情況下重新啟動(dòng)容器有助于在出現(xiàn)問(wèn)題時(shí)使應(yīng)用程序更加可行。
就緒探針
kubernetes中提供的就緒檢測(cè)器可以知道容器何時(shí)就緒，并可以開(kāi)始接受請(qǐng)求的流量。當(dāng)一個(gè)容器中的所有容器都準(zhǔn)備好時(shí)，該容器可以被認(rèn)為是準(zhǔn)備好的。該信號(hào)的一種是控制哪個(gè)pod是服務(wù)的后端。當(dāng)pod未就緒時(shí)，它將從服務(wù)的負(fù)載平衡器中刪除。
啟動(dòng)探針
kubernetes中提供的啟動(dòng)檢測(cè)器可以知道應(yīng)用程序容器何時(shí)啟動(dòng)。如果配置了這種檢測(cè)器，可以控制它在成功啟動(dòng)后檢查容器的生存性和就緒性，以保證這些生存性和就緒性檢測(cè)器不會(huì)影響應(yīng)用的啟動(dòng)。這可用于檢測(cè)慢啟動(dòng)容器的生存能力，并防止它們?cè)趩?dòng)前被殺死。
探針使用總結(jié)
1.當(dāng)需要在容器啟動(dòng)后檢查活動(dòng)探針或就緒探針時(shí)，可以通過(guò)設(shè)置啟動(dòng)探針來(lái)實(shí)現(xiàn)。
2.當(dāng)容器在異?；虿唤】档臈l件下崩潰時(shí)，可能不需要生存探針，kubernetes可以根據(jù)pod 的重啟策略。
3.當(dāng)容器被終止并在檢測(cè)失敗時(shí)重新啟動(dòng)時(shí)，您可以指定survival探測(cè)器并將restartpolicy指定為always或onfailure。
4.當(dāng)您希望pod僅在探測(cè)成功時(shí)才開(kāi)始接收外部請(qǐng)求流量時(shí)，您可以使探測(cè)就緒。
有關(guān)使用kubernetes探針技術(shù)的更多示例，請(qǐng)參見(jiàn)[2]。
目前，kubernetes容器基于維度的部署已經(jīng)成為業(yè)界事實(shí)上的標(biāo)準(zhǔn)。相關(guān)技術(shù)在為微服務(wù)的維度化部署帶來(lái)極利的同時(shí)，在一些特殊的部署場(chǎng)景下，也存在一些需要解決的問(wèn)題。例如，為了使kubernetes的滾動(dòng)發(fā)布功能進(jìn)入發(fā)布，與kubernetes 滾動(dòng)發(fā)布是通過(guò)檢查特定終端是否應(yīng)該啟動(dòng)作為應(yīng)該就緒的標(biāo)志來(lái)觸發(fā)下一批的實(shí)例發(fā)布，但僅限于微服務(wù)應(yīng)用。只有完成服務(wù)注冊(cè)，才能對(duì)外提供服務(wù)。因此，在某些情況下，新應(yīng)用程序在注冊(cè)之前會(huì)被設(shè)置為離線，從而導(dǎo)致服務(wù)可用。
目前業(yè)內(nèi)也已經(jīng)有了針對(duì)發(fā)布狀態(tài)和情況應(yīng)對(duì)等問(wèn)題引發(fā)的線上事故的相關(guān)解決方案。例如，我們可以通過(guò)檢查相關(guān)服務(wù)的注冊(cè)來(lái)檢查微服務(wù)的準(zhǔn)備情況，通過(guò)字節(jié)碼技術(shù)植入服務(wù)注冊(cè)前后的邏輯，然后打開(kāi)一個(gè)終端來(lái)檢測(cè)服務(wù)的注冊(cè)是否應(yīng)該完成，這樣kubernetes的ready探針就可以檢測(cè)綁定戶(hù)的發(fā)布狀態(tài)和運(yùn)行狀態(tài)來(lái)實(shí)現(xiàn)微服務(wù)的準(zhǔn)備情況檢查，從而避免相關(guān)狀態(tài)不會(huì)造成應(yīng)該發(fā)布的在線流量損失的問(wèn)題。
參考數(shù)據(jù)
[1] dubbo延遲注冊(cè):延遲曝光|阿帕奇dubbo
[2]kubernetes探針技術(shù)舉例:配置生存、就緒和啟動(dòng)探測(cè)器| kubernetes
原始鏈接
本文為阿里云原創(chuàng)內(nèi)容，未經(jīng)允許不得轉(zhuǎn)載。
標(biāo)簽:
流程實(shí)例
了解更多微服務(wù)架構(gòu)流量分布(微服務(wù)流量著色)相關(guān)內(nèi)容請(qǐng)關(guān)注本站點(diǎn)。