国产精品chinese,色综合天天综合精品网国产在线,成午夜免费视频在线观看,清纯女学生被强行糟蹋小说

    <td id="ojr13"><tr id="ojr13"><label id="ojr13"></label></tr></td>
        • <source id="ojr13"></source>
            <td id="ojr13"><ins id="ojr13"><label id="ojr13"></label></ins></td>

            Article / 文章中心

            深入剖析全鏈路灰度技術(shù)內(nèi)幕(2)

            發(fā)布時(shí)間:2021-12-16 點(diǎn)擊數(shù):1240
            03

            全鏈路灰度的解決方案

            Cloud Native


            如何在實(shí)際業(yè)務(wù)場(chǎng)景中去快速落地全鏈路灰度呢?目前,主要有兩種解決思路,基于物理環(huán)境隔離和基于邏輯環(huán)境隔離。
            1
             物理環(huán)境隔離


            物理環(huán)境隔離,顧名思義,通過(guò)增加機(jī)器的方式來(lái)搭建真正意義上的流量隔離。

            物理環(huán)境隔離

            這種方案需要為要灰度的服務(wù)搭建一套網(wǎng)絡(luò)隔離、資源獨(dú)立的環(huán)境,在其中部署服務(wù)的灰度版本。由于與正式環(huán)境隔離,正式環(huán)境中的其他服務(wù)無(wú)法訪問(wèn)到需要灰度的服務(wù),所以需要在灰度環(huán)境中冗余部署這些線上服務(wù),以便整個(gè)調(diào)用鏈路正常進(jìn)行流量轉(zhuǎn)發(fā)。此外,注冊(cè)中心等一些其他依賴的中間件組件也需要冗余部署在灰度環(huán)境中,保證微服務(wù)之間的可見(jiàn)性問(wèn)題,確保獲取的節(jié)點(diǎn) IP 地址只屬于當(dāng)前的網(wǎng)絡(luò)環(huán)境。


            這個(gè)方案一般用于企業(yè)的測(cè)試、預(yù)發(fā)開(kāi)發(fā)環(huán)境的搭建,對(duì)于線上灰度發(fā)布引流的場(chǎng)景來(lái)說(shuō)其靈活性不夠。況且,微服務(wù)多版本的存在在微服務(wù)架構(gòu)中是家常便飯,需要為這些業(yè)務(wù)場(chǎng)景采用堆機(jī)器的方式來(lái)維護(hù)多套灰度環(huán)境。如果您的應(yīng)用數(shù)目過(guò)多的情況下,會(huì)造成運(yùn)維、機(jī)器成本過(guò)大,成本和代價(jià)遠(yuǎn)超收益;如果應(yīng)用數(shù)目很小,就兩三個(gè)應(yīng)用,這個(gè)方式還是很方便的,可以接受的。


            2
             邏輯環(huán)境隔離


            另一種方案是構(gòu)建邏輯上的環(huán)境隔離,我們只需部署服務(wù)的灰度版本,流量在調(diào)用鏈路上流轉(zhuǎn)時(shí),由流經(jīng)的網(wǎng)關(guān)、各個(gè)中間件以及各個(gè)微服務(wù)來(lái)識(shí)別灰度流量,并動(dòng)態(tài)轉(zhuǎn)發(fā)至對(duì)應(yīng)服務(wù)的灰度版本。如下圖:

            邏輯環(huán)境隔離


            上圖可以很好展示這種方案的效果,我們用不同的顏色來(lái)表示不同版本的灰度流量,可以看出無(wú)論是微服務(wù)網(wǎng)關(guān)還是微服務(wù)本身都需要識(shí)別流量,根據(jù)治理規(guī)則做出動(dòng)態(tài)決策。當(dāng)服務(wù)版本發(fā)生變化時(shí),這個(gè)調(diào)用鏈路的轉(zhuǎn)發(fā)也會(huì)實(shí)時(shí)改變。相比于利用機(jī)器搭建的灰度環(huán)境,這種方案不僅可以節(jié)省大量的機(jī)器成本和運(yùn)維人力,而且可以幫助開(kāi)發(fā)者實(shí)時(shí)快速的對(duì)線上流量進(jìn)行精細(xì)化的全鏈路控制。


            那么全鏈路灰度具體是如何實(shí)現(xiàn)呢?通過(guò)上面的討論,我們需要解決以下問(wèn)題:
            1. 鏈路上各個(gè)組件和服務(wù)能夠根據(jù)請(qǐng)求流量特征進(jìn)行動(dòng)態(tài)路由
            2. 需要對(duì)服務(wù)下的所有節(jié)點(diǎn)進(jìn)行分組,能夠區(qū)分版本
            1. 需要對(duì)流量進(jìn)行灰度標(biāo)識(shí)、版本標(biāo)識(shí)
            2. 需要識(shí)別出不同版本的灰度流量

            接下來(lái),會(huì)介紹解決上述問(wèn)題需要用到的技術(shù)。

            標(biāo)簽路由


            標(biāo)簽路由通過(guò)對(duì)服務(wù)下所有節(jié)點(diǎn)按照標(biāo)簽名和標(biāo)簽值不同進(jìn)行分組,使得訂閱該服務(wù)節(jié)點(diǎn)信息的服務(wù)消費(fèi)端可以按需訪問(wèn)該服務(wù)的某個(gè)分組,即所有節(jié)點(diǎn)的一個(gè)子集。服務(wù)消費(fèi)端可以使用服務(wù)提供者節(jié)點(diǎn)上的任何標(biāo)簽信息,根據(jù)所選標(biāo)簽的實(shí)際含義,消費(fèi)端可以將標(biāo)簽路由應(yīng)用到更多的業(yè)務(wù)場(chǎng)景中。

            標(biāo)簽路由



            節(jié)點(diǎn)打標(biāo)


            那么如何給服務(wù)節(jié)點(diǎn)添加不同的標(biāo)簽?zāi)??在如今火熱的云原生技術(shù)推動(dòng)下,大多數(shù)業(yè)務(wù)都在積極進(jìn)行容器化改造之旅。這里,我就以容器化的應(yīng)用為例,介紹在使用 Kubernetes Service 作為服務(wù)發(fā)現(xiàn)和使用比較流行的 Nacos 注冊(cè)中心這兩種場(chǎng)景下如何對(duì)服務(wù) Workload 進(jìn)行節(jié)點(diǎn)打標(biāo)。


            在使用 Kubernetes Service 作為服務(wù)發(fā)現(xiàn)的業(yè)務(wù)系統(tǒng)中,服務(wù)提供者通過(guò)向 ApiServer 提交 Service 資源完成服務(wù)暴露,服務(wù)消費(fèi)端監(jiān)聽(tīng)與該 Service 資源下關(guān)聯(lián)的 Endpoint 資源,從 Endpoint 資源中獲取關(guān)聯(lián)的業(yè)務(wù) Pod 資源,讀取上面的 Labels 數(shù)據(jù)并作為該節(jié)點(diǎn)的元數(shù)據(jù)信息。所以,我們只要在業(yè)務(wù)應(yīng)用描述資源 Deployment 中的 Pod 模板中為節(jié)點(diǎn)添加標(biāo)簽即可。

             Kubernetes Service


            在使用 Nacos 作為服務(wù)發(fā)現(xiàn)的業(yè)務(wù)系統(tǒng)中,一般是需要業(yè)務(wù)根據(jù)其使用的微服務(wù)框架來(lái)決定打標(biāo)方式。如果 Java 應(yīng)用使用的 Spring Cloud 微服務(wù)開(kāi)發(fā)框架,我們可以為業(yè)務(wù)容器添加對(duì)應(yīng)的環(huán)境變量來(lái)完成標(biāo)簽的添加操作。比如我們希望為節(jié)點(diǎn)添加版本灰度標(biāo),那么為業(yè)務(wù)容器添加`spring.cloud.nacos.discovery.metadata.version=gray`,這樣框架向Nacos注冊(cè)該節(jié)點(diǎn)時(shí)會(huì)為其添加一個(gè)標(biāo)簽`verison=gray`。

            Nacos

            流量染色


            請(qǐng)求鏈路上各個(gè)組件如何識(shí)別出不同的灰度流量?答案就是流量染色,為請(qǐng)求流量添加不同灰度標(biāo)識(shí)來(lái)方便區(qū)分。我們可以在請(qǐng)求的源頭上對(duì)流量進(jìn)行染色,前端在發(fā)起請(qǐng)求時(shí)根據(jù)用戶信息或者平臺(tái)信息的不同對(duì)流量進(jìn)行打標(biāo)。如果前端無(wú)法做到,我們也可以在微服務(wù)網(wǎng)關(guān)上對(duì)匹配特定路由規(guī)則的請(qǐng)求動(dòng)態(tài)添加流量標(biāo)識(shí)。此外,流量在鏈路中流經(jīng)灰度節(jié)點(diǎn)時(shí),如果請(qǐng)求信息中不含有灰度標(biāo)識(shí),需要自動(dòng)為其染色,接下來(lái)流量就可以在后續(xù)的流轉(zhuǎn)過(guò)程中優(yōu)先訪問(wèn)服務(wù)的灰度版本。

            分布式鏈路追蹤


            還有一個(gè)很重要的問(wèn)題是如何保證灰度標(biāo)識(shí)能夠在鏈路中一直傳遞下去呢?如果在請(qǐng)求源頭染色,那么請(qǐng)求經(jīng)過(guò)網(wǎng)關(guān)時(shí),網(wǎng)關(guān)作為代理會(huì)將請(qǐng)求原封不動(dòng)的轉(zhuǎn)發(fā)給入口服務(wù),除非開(kāi)發(fā)者在網(wǎng)關(guān)的路由策略中實(shí)施請(qǐng)求內(nèi)容修改策略。接著,請(qǐng)求流量會(huì)從入口服務(wù)開(kāi)始調(diào)用下一個(gè)微服務(wù),會(huì)根據(jù)業(yè)務(wù)代碼邏輯形成新的調(diào)用請(qǐng)求,那么我們?nèi)绾螌⒒叶葮?biāo)識(shí)添加到這個(gè)新的調(diào)用請(qǐng)求,從而可以在鏈路中傳遞下去呢?
            從單體架構(gòu)演進(jìn)到分布式微服務(wù)架構(gòu),服務(wù)之間調(diào)用從同一個(gè)線程中方法調(diào)用變?yōu)閺谋镜剡M(jìn)程的服務(wù)調(diào)用遠(yuǎn)端進(jìn)程中服務(wù),并且遠(yuǎn)端服務(wù)可能以多副本形式部署,以至于一條請(qǐng)求流經(jīng)的節(jié)點(diǎn)是不可預(yù)知的、不確定的,而且其中每一跳的調(diào)用都有可能因?yàn)榫W(wǎng)絡(luò)故障或服務(wù)故障而出錯(cuò)。分布式鏈路追蹤技術(shù)對(duì)大型分布式系統(tǒng)中請(qǐng)求調(diào)用鏈路進(jìn)行詳細(xì)記錄,核心思想就是通過(guò)一個(gè)全局唯一的 traceid 和每一條的 spanid 來(lái)記錄請(qǐng)求鏈路所經(jīng)過(guò)的節(jié)點(diǎn)以及請(qǐng)求耗時(shí),其中 traceid 是需要整個(gè)鏈路傳遞的。


            借助于分布式鏈路追蹤思想,我們也可以傳遞一些自定義信息,比如灰度標(biāo)識(shí)。業(yè)界常見(jiàn)的分布式鏈路追蹤產(chǎn)品都支持鏈路傳遞用戶自定義的數(shù)據(jù),其數(shù)據(jù)處理流程如下圖所示:

            數(shù)據(jù)處理流程

            邏輯環(huán)境隔離——基于 SDK


            上面我們?cè)敿?xì)介紹了實(shí)現(xiàn)全鏈路灰度所需要的幾種技術(shù),如果想為現(xiàn)有的業(yè)務(wù)接入全鏈路灰度能力,不可避免的需要為業(yè)務(wù)使用的開(kāi)發(fā)框架 SDK 進(jìn)行改造。首先,需要支持動(dòng)態(tài)路由功能,對(duì)于 Spring Cloud、Dubbo 開(kāi)發(fā)框架,可以對(duì)出口流量實(shí)現(xiàn)自定義 Filter,在該 Filter 中完成流量識(shí)別以及標(biāo)簽路由。同時(shí)需要借助分布式鏈路追蹤技術(shù)完成流量標(biāo)識(shí)鏈路傳遞以及流量自動(dòng)染色。此外,需要引入一個(gè)中心化的流量治理平臺(tái),方便各個(gè)業(yè)務(wù)線的開(kāi)發(fā)者定義自己的全鏈路灰度規(guī)則?;?SDK 實(shí)現(xiàn)方式的圖例如下:

            邏輯環(huán)境隔離sdk


            邏輯環(huán)境隔離——基于 Java Agent


            基于 SDK 方式的弊端在于需要業(yè)務(wù)進(jìn)行 SDK 版本升級(jí),甚至?xí)婕暗綐I(yè)務(wù)代碼的變動(dòng)。企業(yè)內(nèi)部各個(gè)微服務(wù)雖然使用同一種開(kāi)發(fā)框架,但很難保證框架版本是一致的,所以不得不為每一個(gè)版本維護(hù)一份全鏈路灰度的代碼。業(yè)務(wù)代碼與 SDK 代碼緊耦合,SDK 版本迭代會(huì)觸發(fā)業(yè)務(wù)不必要的發(fā)版變更,對(duì)業(yè)務(wù)的侵入性比較強(qiáng)。


            另一種比較流行的方式是基于字節(jié)碼增強(qiáng)技術(shù)在編譯時(shí)對(duì)開(kāi)發(fā)框架進(jìn)行功能拓展,這種方案業(yè)務(wù)無(wú)感知,以無(wú)侵入方式為業(yè)務(wù)引入全鏈路灰度能力。基于 Java Agent 的實(shí)現(xiàn)方式的圖例如下:

            Java Agent


            但仍然無(wú)法避免是開(kāi)發(fā)者需要為業(yè)務(wù)使用版本不一致的開(kāi)發(fā)框架維護(hù)對(duì)應(yīng)的 Java Agent 的版本。如果您比較傾向于這種無(wú)侵入的方案但又不想自己來(lái)維護(hù),您可以選擇阿里云 MSE 服務(wù)治理產(chǎn)品,該產(chǎn)品就是一款基于 Java Agent 實(shí)現(xiàn)的無(wú)侵入式企業(yè)生產(chǎn)級(jí)服務(wù)治理產(chǎn)品,您不需要修改任何一行業(yè)務(wù)代碼,即可擁有不限于全鏈路灰度的治理能力,并且支持近 5 年內(nèi)所有的 Spring Boot、Spring Cloud 和 Dubbo。


            邏輯環(huán)境隔離——基于 Service Mesh


            在業(yè)務(wù)系統(tǒng)的微服務(wù)架構(gòu)中,如果存在大量使用不同的技術(shù)棧、語(yǔ)言棧的微服務(wù),Java Agent 的方式就無(wú)能為力了。我們可能需要為每一個(gè)語(yǔ)言的 SDK 編寫(xiě)和維護(hù)全鏈路灰度代碼,不僅需要不同語(yǔ)言棧的開(kāi)發(fā)者,而且涉及到語(yǔ)言無(wú)關(guān)的 bug 修復(fù)時(shí)需要全語(yǔ)言版本的 SDK 共同升級(jí),這種代價(jià)不見(jiàn)得比基于物理環(huán)境隔離方案小。


            那有沒(méi)有一種與語(yǔ)言無(wú)關(guān)的方案呢?有,下一代微服務(wù)架構(gòu)服務(wù)網(wǎng)格,Service Mesh。它將分布式服務(wù)的通信層抽象為單獨(dú)的一層,在這一層中實(shí)現(xiàn)負(fù)載均衡、服務(wù)發(fā)現(xiàn)、認(rèn)證授權(quán)、監(jiān)控追蹤、流量控制等分布式系統(tǒng)所需要的功能。顯然,我們所需的全鏈路灰度能力也可以在這個(gè)流量治理基礎(chǔ)設(shè)施層來(lái)實(shí)現(xiàn)。幸運(yùn)的是,服務(wù)網(wǎng)格明星產(chǎn)品Istio以聲明式 API 資源對(duì)流量治理進(jìn)行了統(tǒng)一抽象,借助于 VirtualService 和 DestinationRule 治理規(guī)則可以很容易實(shí)現(xiàn)全鏈路灰度的效果,并且Istio集成了各種主流的分布式鏈路追蹤框架。基于 Service Mesh 的實(shí)現(xiàn)方式的圖例如下:

            Service Mesh



            在實(shí)際生產(chǎn)環(huán)境中,服務(wù)多版本并行開(kāi)發(fā)是很常見(jiàn)的事情,而且版本迭代速度非???。版本每次變更都需要修改 VirtualSerivice 資源中路由匹配規(guī)則,另外 VirtualSerivice 資源中并沒(méi)有提供容災(zāi)能力。比如存在一條路由規(guī)則訪問(wèn)服務(wù)提供方的某個(gè)灰度版本,如果目標(biāo)服務(wù)不存在該灰度版本或者不可用,按照目前 Istio 的實(shí)現(xiàn)是仍然將流量轉(zhuǎn)發(fā)至該版本,缺乏容災(zāi)機(jī)制。還有一種業(yè)務(wù)場(chǎng)景,如果我們希望對(duì)處于一定 UID 范圍的用戶流量轉(zhuǎn)發(fā)指定灰度環(huán)境,是無(wú)法通過(guò) Istio 現(xiàn)有的流量治理規(guī)則實(shí)現(xiàn)的。此時(shí),您可以選擇阿里云服務(wù)網(wǎng)格產(chǎn)品 ASM,是一個(gè)統(tǒng)一管理微服務(wù)應(yīng)用流量、兼容 Istio 的托管式平臺(tái)。ASM 針對(duì)上述兩個(gè)場(chǎng)景都有應(yīng)對(duì)方案,輕松解決您在多語(yǔ)言場(chǎng)景下的全鏈路灰度訴求。


            三種方式對(duì)比


            下表是三種方式對(duì)比,從多個(gè)方面進(jìn)行了對(duì)比。

            三種微服務(wù)治理產(chǎn)品方式對(duì)比


            • 如果您傾向于使用無(wú)侵入式的 Java Agent 的方式,但又擔(dān)心自建帶來(lái)的穩(wěn)定性問(wèn)題,您可以選擇 MSE 微服務(wù)治理產(chǎn)品,該產(chǎn)品是阿里巴巴內(nèi)部多年在微服務(wù)治理領(lǐng)域的沉淀的產(chǎn)出,經(jīng)歷了各種大促考驗(yàn)。

            • 如果您傾向于使用語(yǔ)言無(wú)關(guān)、無(wú)侵入式的 Service Mesh 的方式,但又擔(dān)心自建帶來(lái)的穩(wěn)定性問(wèn)題,您可以選擇阿里云 ASM 產(chǎn)品,相比開(kāi)源 Istio,在功能性、穩(wěn)定性和安全性都有很大的提升。

            3
             流量入口:網(wǎng)關(guān)


            在分布式應(yīng)用中,作為流量入口的網(wǎng)關(guān)是不可或缺的。在全鏈路灰度場(chǎng)景中,就要求微服務(wù)網(wǎng)關(guān)具備豐富的流量治理能力,支持服務(wù)多版本路由,支持對(duì)特定路由規(guī)則上的請(qǐng)求進(jìn)行動(dòng)態(tài)打標(biāo)。對(duì)于入口服務(wù)可見(jiàn)性問(wèn)題,網(wǎng)關(guān)需要支持多種服務(wù)發(fā)現(xiàn)方式。安全性問(wèn)題上,網(wǎng)關(guān)作為集群對(duì)外的入口可以對(duì)所有請(qǐng)求流量進(jìn)行認(rèn)證鑒權(quán),保障業(yè)務(wù)系統(tǒng)不被非法流量入侵。


            在虛擬化時(shí)期的微服務(wù)架構(gòu)下,業(yè)務(wù)通常采用流量網(wǎng)關(guān) + 微服務(wù)網(wǎng)關(guān)的兩層架構(gòu),流量網(wǎng)關(guān)負(fù)責(zé)南北向流量調(diào)度和安全防護(hù),微服務(wù)網(wǎng)關(guān)負(fù)責(zé)東西向流量調(diào)度和服務(wù)治理。在容器和 K8s 主導(dǎo)的云原生時(shí)代,Ingress 成為 K8s 生態(tài)的網(wǎng)關(guān)標(biāo)準(zhǔn),賦予了網(wǎng)關(guān)新的使命,使得流量網(wǎng)關(guān) + 微服務(wù)網(wǎng)關(guān)合二為一成為可能。阿里云 MSE 發(fā)布的云原生網(wǎng)關(guān)在能力不打折的情況下,將兩層網(wǎng)關(guān)變?yōu)橐粚?,不僅可以節(jié)省 50% 的資源成本,還可以降低運(yùn)維及使用成本。最重要的是,云原生網(wǎng)關(guān)支持與后端微服務(wù)治理聯(lián)動(dòng)實(shí)現(xiàn)端到端的全鏈路灰度。

            流量入口網(wǎng)關(guān)