日逼高清无码视频,黄色p网站,国产不卡精品视频,女人18毛片水真多免费,9l视频自拍蝌蚪九色9l视频成人,欧美成人乱妇一级在线视频,俺来俺去www色官网,和女老板做爰3

作者：揚少

當(dāng)服務(wù)有新版本要發(fā)布上線時，通過引流一小部分流量到新版本，可以及時發(fā)現(xiàn)程序問題，有效阻止大面積故障的發(fā)生。業(yè)界上已經(jīng)有比較成熟的服務(wù)發(fā)布策略，比如藍綠發(fā)布、A/B 測試以及金絲雀發(fā)布，這些發(fā)布策略主要專注于如何對單個服務(wù)進行發(fā)布。在微服務(wù)體系架構(gòu)中，服務(wù)之間的依賴關(guān)系錯綜復(fù)雜，有時某個功能發(fā)版依賴多個服務(wù)同時升級上線。我們希望可以對這些服務(wù)的新版本同時進行小流量灰度驗證，這就是微服務(wù)架構(gòu)中特有的全鏈路灰度場景，通過構(gòu)建從網(wǎng)關(guān)到整個后端服務(wù)的環(huán)境隔離來對多個不同版本的服務(wù)進行灰度驗證。

本文將會揭開全鏈路灰度的神秘面紗，深入剖析全鏈路灰度技術(shù)內(nèi)幕，引出兩種不同的實現(xiàn)方案，并對實現(xiàn)方案的技術(shù)細節(jié)進行深入探討，最后通過實踐環(huán)節(jié)來展示全鏈路灰度在實際業(yè)務(wù)中的使用場景。

微服務(wù)架構(gòu)帶來的挑戰(zhàn)

Cloud Native

為了滿足業(yè)務(wù)的迭代速度，開發(fā)者開始對原來的單體架構(gòu)進行細粒度的拆分，將單體應(yīng)用中的服務(wù)模塊拆分成一個個獨立部署運行的微服務(wù)，并且這些微服務(wù)的生命周期由對應(yīng)的業(yè)務(wù)團隊獨自負責(zé)，有效的解決了單體架構(gòu)中存在的敏捷性不足、靈活性不強的問題。常見的做法是根據(jù)業(yè)務(wù)域或者功能域進行服務(wù)拆分，如下圖：

其中，流量網(wǎng)關(guān)是四層代理，主要功能有負載均衡、TLS 卸載以及一些安全防護功能；微服務(wù)網(wǎng)關(guān)是七層代理，主要用來暴露后端服務(wù)、流量治理、訪問控制和流量監(jiān)控。以"高內(nèi)聚、低耦合"作為設(shè)計理念的微服務(wù)架構(gòu)為開發(fā)者帶來了前所未有的開發(fā)體驗，每個業(yè)務(wù)團隊專注于自身業(yè)務(wù)的代碼邏輯，并通過 API 形式對外發(fā)布。服務(wù)依賴方只需引入服務(wù)提供方的 API 定義，即可完成服務(wù)之間通信，無需關(guān)心服務(wù)提供方的部署形態(tài)和內(nèi)部實現(xiàn)。

但任何架構(gòu)都不是銀彈，在解決舊問題同時勢必會引入一些新的問題。微服務(wù)體系中最令人頭疼的問題，是如何對眾多微服務(wù)進行高效、便捷的治理，主要表現(xiàn)在可見性、連接性和安全性這三個方面。進一步細化，微服務(wù)架構(gòu)帶來了以下的挑戰(zhàn)：

本文的重點主要關(guān)注服務(wù)發(fā)布這一子領(lǐng)域，如何保證微服務(wù)體系中服務(wù)新版本升級過程中平滑無損，以及如何低成本的為多個微服務(wù)構(gòu)建流量隔離環(huán)境，方便開發(fā)者同時對多個服務(wù)新版本進行充分的灰度驗證，避免故障的發(fā)生。

什么是全鏈路灰度

Cloud Native

?單體架構(gòu)下的服務(wù)發(fā)布

首先，我們先看一下在單體架構(gòu)中，如何對應(yīng)用中某個服務(wù)模塊進行新版本發(fā)布。如下圖，應(yīng)用中的 Cart 服務(wù)模塊有新版本迭代：

由于 Cart 服務(wù)是應(yīng)用的一部分，所以新版本上線時需要對整個應(yīng)用進行編譯、打包以及部署。服務(wù)級別發(fā)布問題變成了應(yīng)用級別的發(fā)布問題，我們需要對應(yīng)用的新版本而不是服務(wù)來實施有效的發(fā)布策略。

目前，業(yè)界已經(jīng)有非常成熟的服務(wù)發(fā)布方案，例如藍綠發(fā)布和灰度發(fā)布。藍綠發(fā)布需要對服務(wù)的新版本進行冗余部署，一般新版本的機器規(guī)格和數(shù)量與舊版本保持一致，相當(dāng)于該服務(wù)有兩套完全相同的部署環(huán)境，只不過此時只有舊版本在對外提供服務(wù)，新版本作為熱備。當(dāng)服務(wù)進行版本升級時，我們只需將流量全部切換到新版本即可，舊版本作為熱備。我們的例子使用藍綠發(fā)布的示意圖如下，流量切換基于四層代理的流量網(wǎng)關(guān)即可完成。

在藍綠發(fā)布中，由于存在流量整體切換，所以需要按照原服務(wù)占用的機器規(guī)模為新版本克隆一套環(huán)境，相當(dāng)于要求原來1倍的機器資源?；叶劝l(fā)布的核心思想是根據(jù)請求內(nèi)容或者請求流量的比例將線上流量的一小部分轉(zhuǎn)發(fā)至新版本，待灰度驗證通過后，逐步調(diào)大新版本的請求流量，是一種循序漸進的發(fā)布方式。我們的例子使用灰度發(fā)布的示意圖如下，基于內(nèi)容或比例的流量控制需要借助于一個七層代理的微服務(wù)網(wǎng)關(guān)來完成。

其中，Traffic Routing 是基于內(nèi)容的灰度方式，比如請求中含有頭部 stag=gray 的流量路由到應(yīng)用 v2 版本；Traffic Shifting 是基于比例的灰度方式，以無差別的方式對線上流量按比重進行分流。相比藍綠發(fā)布，灰度發(fā)布在機器資源成本以及流量控制能力上更勝一籌，但缺點就是發(fā)布周期過長，對運維基礎(chǔ)設(shè)施要求較高。

?微服務(wù)架構(gòu)下的服務(wù)發(fā)布

在分布式微服務(wù)架構(gòu)中，應(yīng)用中被拆分出來的子服務(wù)都是獨立部署、運行和迭代的。單個服務(wù)新版本上線時，我們再也不需要對應(yīng)用整體進行發(fā)版，只需關(guān)注每個微服務(wù)自身的發(fā)布流程即可，如下：

為了驗證服務(wù) Cart 的新版本，流量在整個調(diào)用鏈路上能夠通過某種方式有選擇的路由到 Cart 的灰度版本，這屬于微服務(wù)治理領(lǐng)域中流量治理問題。常見的治理策略包括基于 Provider 和基于 Consumer 的方式。

基于 Provider 的治理策略。配置 Cart 的流量流入規(guī)則，User 路由到 Cart 時使用 Cart 的流量流入規(guī)則。

基于 Consumer 的治理策略。配置 User 的流量流出規(guī)則， User 路由到 Cart 時使用 User 的流量流出規(guī)則。

此外，使用這些治理策略時可以結(jié)合上面介紹的藍綠發(fā)布和灰度發(fā)布方案來實施真正的服務(wù)級別的版本發(fā)布。

?全鏈路灰度

繼續(xù)考慮上面微服務(wù)體系中對服務(wù) Cart 進行發(fā)布的場景，如果此時服務(wù) Order 也需要發(fā)布新版本，由于本次新功能涉及到服務(wù) Cart 和 Order 的共同變動，所以要求在灰度驗證時能夠使得灰度流量同時經(jīng)過服務(wù) Cart 和 Order 的灰度版本。如下圖：

按照上一小節(jié)提出的兩種治理策略，我們需要額外配置服務(wù) Order 的治理規(guī)則，確保來自灰度環(huán)境的服務(wù) Cart 的流量轉(zhuǎn)發(fā)至服務(wù) Order 的灰度版本。這樣的做法看似符合正常的操作邏輯，但在真實業(yè)務(wù)場景中，業(yè)務(wù)的微服務(wù)規(guī)模和數(shù)量遠超我們的例子，其中一條請求鏈路可能經(jīng)過數(shù)十個微服務(wù)，新功能發(fā)布時也可能會涉及到多個微服務(wù)同時變更，并且業(yè)務(wù)的服務(wù)之間依賴錯綜復(fù)雜，頻繁的服務(wù)發(fā)布、以及服務(wù)多版本并行開發(fā)導(dǎo)致流量治理規(guī)則日益膨脹，給整個系統(tǒng)的維護性和穩(wěn)定性帶來了不利因素。

對于以上的問題，開發(fā)者結(jié)合實際業(yè)務(wù)場景和生產(chǎn)實踐經(jīng)驗，提出了一種端到端的灰度發(fā)布方案，即全鏈路灰度。全鏈路灰度治理策略主要專注于整個調(diào)用鏈，它不關(guān)心鏈路上經(jīng)過具體哪些微服務(wù)，流量控制視角從服務(wù)轉(zhuǎn)移至請求鏈路上，僅需要少量的治理規(guī)則即可構(gòu)建出從網(wǎng)關(guān)到整個后端服務(wù)的多個流量隔離環(huán)境，有效保證了多個親密關(guān)系的服務(wù)順利安全發(fā)布以及服務(wù)多版本并行開發(fā)，進一步促進業(yè)務(wù)的快速發(fā)展。

全鏈路灰度的解決方案

Cloud Native

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

?物理環(huán)境隔離

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

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

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

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

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

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

那么全鏈路灰度具體是如何實現(xiàn)呢？通過上面的討論，我們需要解決以下問題：

鏈路上各個組件和服務(wù)能夠根據(jù)請求流量特征進行動態(tài)路由
需要對服務(wù)下的所有節(jié)點進行分組，能夠區(qū)分版本

需要對流量進行灰度標(biāo)識、版本標(biāo)識
需要識別出不同版本的灰度流量

接下來，會介紹解決上述問題需要用到的技術(shù)。

標(biāo)簽路由

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

節(jié)點打標(biāo)

那么如何給服務(wù)節(jié)點添加不同的標(biāo)簽?zāi)兀吭谌缃窕馃岬脑圃夹g(shù)推動下，大多數(shù)業(yè)務(wù)都在積極進行容器化改造之旅。這里，我就以容器化的應(yīng)用為例，介紹在使用 Kubernetes Service 作為服務(wù)發(fā)現(xiàn)和使用比較流行的 Nacos 注冊中心這兩種場景下如何對服務(wù) Workload 進行節(jié)點打標(biāo)。

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

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

流量染色

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

分布式鏈路追蹤

還有一個很重要的問題是如何保證灰度標(biāo)識能夠在鏈路中一直傳遞下去呢？如果在請求源頭染色，那么請求經(jīng)過網(wǎng)關(guān)時，網(wǎng)關(guān)作為代理會將請求原封不動的轉(zhuǎn)發(fā)給入口服務(wù)，除非開發(fā)者在網(wǎng)關(guān)的路由策略中實施請求內(nèi)容修改策略。接著，請求流量會從入口服務(wù)開始調(diào)用下一個微服務(wù)，會根據(jù)業(yè)務(wù)代碼邏輯形成新的調(diào)用請求，那么我們?nèi)绾螌⒒叶葮?biāo)識添加到這個新的調(diào)用請求，從而可以在鏈路中傳遞下去呢？

從單體架構(gòu)演進到分布式微服務(wù)架構(gòu)，服務(wù)之間調(diào)用從同一個線程中方法調(diào)用變?yōu)閺谋镜剡M程的服務(wù)調(diào)用遠端進程中服務(wù)，并且遠端服務(wù)可能以多副本形式部署，以至于一條請求流經(jīng)的節(jié)點是不可預(yù)知的、不確定的，而且其中每一跳的調(diào)用都有可能因為網(wǎng)絡(luò)故障或服務(wù)故障而出錯。分布式鏈路追蹤技術(shù)對大型分布式系統(tǒng)中請求調(diào)用鏈路進行詳細記錄，核心思想就是通過一個全局唯一的 traceid 和每一條的 spanid 來記錄請求鏈路所經(jīng)過的節(jié)點以及請求耗時，其中 traceid 是需要整個鏈路傳遞的。

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

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

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

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

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

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

但仍然無法避免是開發(fā)者需要為業(yè)務(wù)使用版本不一致的開發(fā)框架維護對應(yīng)的 Java Agent 的版本。如果您比較傾向于這種無侵入的方案但又不想自己來維護，您可以選擇阿里云 MSE 服務(wù)治理產(chǎn)品，該產(chǎn)品就是一款基于 Java Agent 實現(xiàn)的無侵入式企業(yè)生產(chǎn)級服務(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ù)棧、語言棧的微服務(wù)，Java Agent 的方式就無能為力了。我們可能需要為每一個語言的 SDK 編寫和維護全鏈路灰度代碼，不僅需要不同語言棧的開發(fā)者，而且涉及到語言無關(guān)的 bug 修復(fù)時需要全語言版本的 SDK 共同升級，這種代價不見得比基于物理環(huán)境隔離方案小。

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

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

三種方式對比

下表是三種方式對比，從多個方面進行了對比。

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

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

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

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

在虛擬化時期的微服務(wù)架構(gòu)下，業(yè)務(wù)通常采用流量網(wǎng)關(guān) + 微服務(wù)網(wǎng)關(guān)的兩層架構(gòu)，流量網(wǎng)關(guān)負責(zé)南北向流量調(diào)度和安全防護，微服務(wù)網(wǎng)關(guān)負責(zé)東西向流量調(diào)度和服務(wù)治理。在容器和 K8s 主導(dǎo)的云原生時代，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)橐粚樱粌H可以節(jié)省 50% 的資源成本，還可以降低運維及使用成本。最重要的是，云原生網(wǎng)關(guān)支持與后端微服務(wù)治理聯(lián)動實現(xiàn)端到端的全鏈路灰度。

從 0 到 1 實踐全鏈路灰度

Cloud Native

看到這里，相信大多數(shù)讀者對全鏈路灰度有了大概的認識，也了解了幾種解決方案以及實現(xiàn)細節(jié)。接下來，我們會基于文中提到的 MSE 云原生網(wǎng)關(guān)和 MSE 服務(wù)治理產(chǎn)品，從 0 到 1 對全鏈路灰度進行實踐，一方面加深對全鏈路灰度的認識，另一方面可以了解下阿里云是如何將阿里巴巴內(nèi)部的最佳實踐輸出到云產(chǎn)品中。

我們假設(shè)應(yīng)用的架構(gòu)由 MSE 云原生網(wǎng)關(guān)以及后端的微服務(wù)架構(gòu)（Spring Cloud）來組成，后端調(diào)用鏈路有 3 跳，購物車（a），交易中心（b），庫存中心（c），通過客戶端或者是 H5 頁面來訪問后端服務(wù)，它們通過 Nacos 注冊中心做服務(wù)發(fā)現(xiàn)?，F(xiàn)在希望使用全鏈路灰度能力構(gòu)建一個灰度環(huán)境，方便對服務(wù) A 和服務(wù) C 同時進行灰度驗證。

?前提條件

必備的資源列表

已擁有一個 MSE 云原生網(wǎng)關(guān)
已擁有一個 MSE Nacos 注冊中心

已擁有一個 ACK 運維集群
已開通 MSE 微服務(wù)治理專業(yè)版

部署 Demo 應(yīng)用程序

將下面的文件保存到 ingress-gray.yaml 中，并執(zhí)行 kubectl apply -f ingress-gray.yaml 以部署應(yīng)用，這里我們將要部署 A，B，C 三個應(yīng)用，A 和 C 應(yīng)用分別部署一個基線版本和一個灰度版本，B 應(yīng)用部署一個基線版本。

有以下注意點：

全鏈路灰度能力是與注冊中心無關(guān)的，本文用例暫以 MSE Nacos 作為注冊中心，所以需要將 spring.cloud.nacos.discovery.server-addr 換成業(yè)務(wù)自己的 Nacos 注冊中心地址
接入云原生網(wǎng)關(guān)的服務(wù)，如果需要使用灰度發(fā)布，需要在發(fā)布服務(wù)時在元數(shù)據(jù)信息增加版本標(biāo)。在我們的例子，服務(wù) A 是需要暴露給網(wǎng)關(guān)，所以發(fā)布時為基線版本添加spring.cloud.nacos.discovery.metadata.version=base，為灰度版本添加 spring.cloud.nacos.discovery.metadata.version=gray。


# A 應(yīng)用 base 版本---apiVersion: apps/v1kind: Deploymentmetadata:  labels:    app: spring-cloud-a  name: spring-cloud-aspec:  replicas: 2  selector:    matchLabels:      app: spring-cloud-a  template:    metadata:      annotations:        msePilotCreateAppName: spring-cloud-a      labels:        app: spring-cloud-a    spec:      containers:      - env:        - name: LANG          value: C.UTF-8        - name: JAVA_HOME          value: /usr/lib/jvm/java-1.8-openjdk/jre        - name: spring.cloud.nacos.discovery.server-addr          value: mse-455e0c20-nacos-ans.mse.aliyuncs.com:8848        - name: spring.cloud.nacos.discovery.metadata.version          value: base        image: registry.cn-shanghai.aliyuncs.com/yizhan/spring-cloud-a:0.1-SNAPSHOT        imagePullPolicy: Always        name: spring-cloud-a        ports:        - containerPort: 20001          protocol: TCP        resources:          requests:            cpu: 250m            memory: 512Mi      # A 應(yīng)用 gray 版本---            apiVersion: apps/v1kind: Deploymentmetadata:  labels:    app: spring-cloud-a-new  name: spring-cloud-a-newspec:  replicas: 2  selector:    matchLabels:      app: spring-cloud-a-new  strategy:  template:    metadata:      annotations:        alicloud.service.tag: gray        msePilotCreateAppName: spring-cloud-a      labels:        app: spring-cloud-a-new    spec:      containers:      - env:        - name: LANG          value: C.UTF-8        - name: JAVA_HOME          value: /usr/lib/jvm/java-1.8-openjdk/jre        - name: profiler.micro.service.tag.trace.enable          value: "true"        - name: spring.cloud.nacos.discovery.server-addr          value: mse-455e0c20-nacos-ans.mse.aliyuncs.com:8848        - name: spring.cloud.nacos.discovery.metadata.version          value: gray        image: registry.cn-shanghai.aliyuncs.com/yizhan/spring-cloud-a:0.1-SNAPSHOT        imagePullPolicy: Always        name: spring-cloud-a-new        ports:        - containerPort: 20001          protocol: TCP        resources:          requests:            cpu: 250m            memory: 512Mi            # B 應(yīng)用 base 版本---apiVersion: apps/v1kind: Deploymentmetadata:  labels:    app: spring-cloud-b  name: spring-cloud-bspec:  replicas: 2  selector:    matchLabels:      app: spring-cloud-b  strategy:  template:    metadata:      annotations:        msePilotCreateAppName: spring-cloud-b      labels:        app: spring-cloud-b    spec:      containers:      - env:        - name: LANG          value: C.UTF-8        - name: JAVA_HOME          value: /usr/lib/jvm/java-1.8-openjdk/jre        - name: spring.cloud.nacos.discovery.server-addr          value: mse-455e0c20-nacos-ans.mse.aliyuncs.com:8848        image: registry.cn-shanghai.aliyuncs.com/yizhan/spring-cloud-b:0.2-demo-SNAPSHOT         imagePullPolicy: Always        name: spring-cloud-b        ports:        - containerPort: 8080          protocol: TCP        resources:          requests:            cpu: 250m            memory: 512Mi            # C 應(yīng)用 base 版本---apiVersion: apps/v1kind: Deploymentmetadata:  labels:    app: spring-cloud-c  name: spring-cloud-cspec:  replicas: 2  selector:    matchLabels:      app: spring-cloud-c  template:    metadata:      annotations:        msePilotCreateAppName: spring-cloud-c      labels:        app: spring-cloud-c    spec:      containers:      - env:        - name: LANG          value: C.UTF-8        - name: JAVA_HOME          value: /usr/lib/jvm/java-1.8-openjdk/jre        - name: spring.cloud.nacos.discovery.server-addr          value: mse-455e0c20-nacos-ans.mse.aliyuncs.com:8848        image: registry.cn-shanghai.aliyuncs.com/yizhan/spring-cloud-c:0.2-demo-SNAPSHOT        imagePullPolicy: Always        name: spring-cloud-c        ports:        - containerPort: 8080          protocol: TCP        resources:          requests:            cpu: 250m            memory: 512Mi            # C 應(yīng)用 gray 版本---apiVersion: apps/v1kind: Deploymentmetadata:  labels:    app: spring-cloud-c-new  name: spring-cloud-c-newspec:  replicas: 2  selector:    matchLabels:      app: spring-cloud-c-new  template:    metadata:      annotations:        alicloud.service.tag: gray        msePilotCreateAppName: spring-cloud-c      labels:        app: spring-cloud-c-new    spec:      containers:      - env:        - name: LANG          value: C.UTF-8        - name: JAVA_HOME          value: /usr/lib/jvm/java-1.8-openjdk/jre        - name: spring.cloud.nacos.discovery.server-addr          value: mse-455e0c20-nacos-ans.mse.aliyuncs.com:8848        image: registry.cn-shanghai.aliyuncs.com/yizhan/spring-cloud-c:0.2-demo-SNAPSHOT        imagePullPolicy: Always        name: spring-cloud-c-new        ports:        - containerPort: 8080          protocol: TCP        resources:          requests:            cpu: 250m            memory: 512Mi

完成云原生網(wǎng)關(guān)初步配置

第一步，為云原生網(wǎng)關(guān)添加 Nacos 服務(wù)來源，服務(wù)管理，來源管理，點擊創(chuàng)建來源，

選擇 MSE Nacos 服務(wù)來源，選擇需要關(guān)聯(lián)的 Nacos 注冊中心，點擊確定。

第二步，導(dǎo)入要通過云原生網(wǎng)關(guān)暴露給外部的服務(wù)。選擇服務(wù)管理，服務(wù)列表，點擊創(chuàng)建服務(wù)。

選擇服務(wù)來源為 MSE Nacos，選擇服務(wù) sc-A。

點擊服務(wù) A 的策略配置，為入口服務(wù) A 創(chuàng)建多版本，版本劃分依據(jù)服務(wù)注冊時所帶的元數(shù)據(jù)信息 version（注意，這里可以是任意可以區(qū)分服務(wù)版本的標(biāo)簽值，取決于用戶注冊服務(wù)時所采用的元數(shù)據(jù)信息），創(chuàng)建以下兩個版本 base 和 gray。

?路由配置

創(chuàng)建基線環(huán)境的路由匹配規(guī)則，關(guān)聯(lián)域名 base.example.com，路由到服務(wù) sc-A 的 base 版本中。

創(chuàng)建灰度環(huán)境的路由匹配規(guī)則，關(guān)聯(lián)的域名與基線環(huán)境保持一致，注意此處增加了請求頭相關(guān)的配置，并且路由的目標(biāo)服務(wù)為服務(wù) sc-A 的 gray 版本。

這時，我們有了如下兩條路由規(guī)則，

此時，訪問?base.example.com?路由到基線環(huán)境

curl -H "Host: base.example.com" http://118.31.118.69/aA[172.21.240.105] -> B[172.21.240.106] -> C[172.21.240.46]

如何訪問灰度環(huán)境呢？只需要在請求中增加一個 header x-mse-tag: gray 即可。


curl -H "Host: base.example.com" -H "x-mse-tag: gray" http://118.31.118.69/aAgray[172.21.240.44] -> B[172.21.240.146] -> Cgray[172.21.240.147]

可以看到云原生網(wǎng)關(guān) 將灰度流量路由到了 A 和 C 的灰度版本，由于B沒有指定的灰度版本，所以流量自動回退到基線版本。

?分析

從上面可以看出，我們只需要開通 MSE 微服務(wù)治理專業(yè)版，在云原生網(wǎng)關(guān)配置入口服務(wù)的路由規(guī)則，并且對入口流量進行灰度染色，即可滿足我們對 A 和?C 全鏈路灰度的要求。另外還有一個很重要的點是，業(yè)務(wù)需要自行對節(jié)點打標(biāo)并對入口服務(wù)開啟鏈路傳遞。為 Pod 模板的 Annotations添加 alicloud.service.tag 鍵值對完成節(jié)點打標(biāo)，Java Agent 會在業(yè)務(wù)向注冊中心時登記節(jié)點時自動為其添加這個元數(shù)據(jù)信息，同時需要為入口服務(wù)的業(yè)務(wù)容器添加環(huán)境變量 profiler.micro.service.tag.trace.enable=true 開啟鏈路傳遞灰度標(biāo)識。MSE 服務(wù)治理組件默認使用 x-mse-tag 來標(biāo)識流量，并在整個調(diào)用鏈路中傳遞。

另外，您可以設(shè)置其他自定義或業(yè)務(wù)已有的字段來標(biāo)識流量，更多詳情操作、場景展示參考文檔：

https://help.aliyun.com/document_detail/359851.html

總結(jié)

Cloud Native

本文從單體架構(gòu)向微服務(wù)架構(gòu)演進過程中帶來的挑戰(zhàn)展開，著重對其子領(lǐng)域服務(wù)發(fā)布在單體架構(gòu)和微服務(wù)架構(gòu)體系下的形態(tài)進行分析，引出了分布式應(yīng)用場景中特有的全鏈路灰度問題。針對業(yè)務(wù)對全鏈路能力的要求，介紹了基于物理環(huán)境隔離和基于邏輯環(huán)境隔離兩種方案，其中對基于邏輯環(huán)境隔離方案進行詳細分析，對涉及到的各個技術(shù)點也進行了很好的解釋，接著提出了三種基于邏輯環(huán)境隔離的落地方案，并進行了簡單的對比分析，最后引出了阿里云 MSE 云原生、MSE 服務(wù)治理和服務(wù)網(wǎng)格 ASM 是如何提供不限于全鏈路灰度的流量治理能力。

国产秋霞理论久久久电影-婷婷色九月综合激情丁香-欧美在线观看乱妇视频-精品国avA久久久久久久-国产乱码精品一区二区三区亚洲人-欧美熟妇一区二区三区蜜桃视频

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

標(biāo)簽路由

節(jié)點打標(biāo)

流量染色

分布式鏈路追蹤

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

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

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

三種方式對比

必備的資源列表

部署 Demo 應(yīng)用程序

完成云原生網(wǎng)關(guān)初步配置