從三萬(wàn)英尺看全鏈路灰度-創(chuàng)新互聯(lián)

作者：卜比

創(chuàng)新互聯(lián)專注為客戶提供全方位的互聯(lián)網(wǎng)綜合服務(wù)，包含不限于網(wǎng)站建設(shè)、做網(wǎng)站、新和網(wǎng)絡(luò)推廣、小程序開(kāi)發(fā)、新和網(wǎng)絡(luò)營(yíng)銷、新和企業(yè)策劃、新和品牌公關(guān)、搜索引擎seo、人物專訪、企業(yè)宣傳片、企業(yè)代運(yùn)營(yíng)等，從售前售中售后，我們都將竭誠(chéng)為您服務(wù)，您的肯定，是我們大的嘉獎(jiǎng)；創(chuàng)新互聯(lián)為所有大學(xué)生創(chuàng)業(yè)者提供新和建站搭建服務(wù)，24小時(shí)服務(wù)熱線：13518219792，官方網(wǎng)址：muchs.cn

全鏈路灰度是微服務(wù)領(lǐng)域，很實(shí)用的企業(yè)級(jí)場(chǎng)景下的技術(shù)能力。

從本期開(kāi)始，我們將通過(guò)《全鏈路灰度：自頂向下的方法》的系列文章，由遠(yuǎn)及近的剖析全鏈路灰度全貌，系列文章分為 4 篇：

《從三萬(wàn)英尺看全鏈路灰度》：介紹微服務(wù)的基礎(chǔ)概念、主流的部署模式。

《從三千英尺看全鏈路灰度》：介紹全鏈路灰度和涉及的組件，以及如何組裝成全鏈路灰度的能力。

《從三百英尺看全鏈路灰度》：從技術(shù)細(xì)節(jié)入手，分享如何實(shí)現(xiàn)路由能力和灰度能力。

《總結(jié)篇》：總結(jié)全鏈路灰度，目的是更加高效支持好業(yè)務(wù)同學(xué)，進(jìn)一步保證線上穩(wěn)定性。

微服務(wù)架構(gòu)的優(yōu)勢(shì) 劃分微服務(wù)層次結(jié)構(gòu)，拆分復(fù)雜度

在微服務(wù)架構(gòu)出現(xiàn)之前，更多的業(yè)務(wù)采用的是單體架構(gòu)。單體架構(gòu)在復(fù)雜業(yè)務(wù)場(chǎng)景下，每一個(gè)開(kāi)發(fā)人員都無(wú)法準(zhǔn)確的評(píng)估復(fù)雜度：每一個(gè)修改都需要遍歷代碼庫(kù)，確定這個(gè)修改不會(huì)影響其他功能。

在微服務(wù)架構(gòu)出現(xiàn)后，通過(guò) RPC、消息隊(duì)列等技術(shù)，我們可以很好的劃分出微服務(wù)體系結(jié)構(gòu)（microservices hierarchy）：架構(gòu)師關(guān)注業(yè)務(wù)邏輯；業(yè)務(wù)開(kāi)發(fā)者關(guān)注微服務(wù)內(nèi)的業(yè)務(wù)自洽；中間件開(kāi)發(fā)者關(guān)注基礎(chǔ)設(shè)施的高效和穩(wěn)定。分離、拆分了復(fù)雜度。

高內(nèi)聚低耦合，讓業(yè)務(wù)更加聚焦

在單體架構(gòu)中，代碼的模塊化一般是通過(guò) package、namespace 等語(yǔ)言特性來(lái)實(shí)現(xiàn)的，但這種模塊化的實(shí)現(xiàn)，會(huì)有各種各樣的問(wèn)題：

• package、namespace 等特性是語(yǔ)言相關(guān)的，如果出現(xiàn)跨語(yǔ)言的情況，需要重新組織代碼結(jié)構(gòu)
• 模塊化劃分沒(méi)有標(biāo)準(zhǔn)。以 Java 為例，是以 controller、service 等組件類型來(lái)劃分 package？還是以各個(gè)業(yè)務(wù)域來(lái)劃分 package？
• package 劃分缺少?gòu)?qiáng)制工具。即使我們定了劃分標(biāo)準(zhǔn)，但 package 仍不能強(qiáng)制限定模塊化，業(yè)務(wù)同學(xué)寫(xiě)出了跨模塊的調(diào)用，仍然能通過(guò)測(cè)試、上線。

面對(duì)上述問(wèn)題，亞馬遜提出了 API-first、FaceBook 開(kāi)源了 Thrift、Google 開(kāi)源了 gRPC，幫助開(kāi)源社區(qū)構(gòu)建了微服務(wù)基礎(chǔ)設(shè)施。

限制不好的架構(gòu)設(shè)計(jì)，讓代碼能夠無(wú)負(fù)擔(dān)進(jìn)化

在單體架構(gòu)時(shí)代，經(jīng)常遇到一些比較難看的設(shè)計(jì)，但是改動(dòng)這些代碼，總是會(huì)遇到兼容性問(wèn)題，不能徹底移除。

拆分成微服務(wù)后，每個(gè)微服務(wù)都可以有自己的開(kāi)發(fā)語(yǔ)言、設(shè)計(jì)模式，即使出現(xiàn)了設(shè)計(jì)問(wèn)題，我們也能夠?qū)⑦@些糟糕的設(shè)計(jì)限定在每個(gè)服務(wù)內(nèi)部，阻止了架構(gòu)的腐化和失控。

微服務(wù)的基礎(chǔ)概念

微服務(wù)生態(tài)圖

上面這張圖很好的展示了微服務(wù)體系下，我們需要依賴的基礎(chǔ)設(shè)施以及相關(guān)開(kāi)源項(xiàng)目，下面我們分模塊簡(jiǎn)要介紹下：

• 微服務(wù)之間要能夠互相發(fā)現(xiàn)、互相調(diào)用，就需要注冊(cè)中心。
• 微服務(wù)的部署需要標(biāo)準(zhǔn)化，方便遷移、擴(kuò)縮容，業(yè)界比較流行的部署模式有 Kubernetes。
• 微服務(wù)的問(wèn)題排查、監(jiān)控等，需要可觀測(cè)組件。
• 微服務(wù)體系需要引入外部流量、鑒權(quán)等，需要微服務(wù)網(wǎng)關(guān)。
• 微服務(wù)的數(shù)據(jù)存儲(chǔ)，根據(jù)存取的方式、成本不同，可以使用 MySQL 或者 Redis 等。
• 需要實(shí)現(xiàn)全鏈路灰度、API 管理等微服務(wù)治理功能，就需要治理中心。

微服務(wù)的拆分

技術(shù)層面上，微服務(wù)的拆分，通?？梢园凑諛I(yè)務(wù)模塊、業(yè)務(wù)場(chǎng)景等進(jìn)行拆分，盡量確保服務(wù)邏輯自洽、對(duì)外其他比較少，做到高內(nèi)聚低耦合。緊密關(guān)聯(lián)的業(yè)務(wù)邏輯，放在一個(gè)微服務(wù)內(nèi)，避免在服務(wù)與服務(wù)之間共享數(shù)據(jù)。

從組織結(jié)構(gòu)層面上，微服務(wù)解決的根本問(wèn)題是團(tuán)隊(duì)分工問(wèn)題，詳見(jiàn)康威定律，這是大型軟件發(fā)展的必然，不因?yàn)槿说南埠枚淖?。?dāng)你讀懂康威定律，就會(huì)發(fā)現(xiàn)“服務(wù)拆分粒度難以準(zhǔn)確把握”根本不是本質(zhì)問(wèn)題。

你有幾個(gè) 2 pizza 團(tuán)隊(duì)，最好就拆成幾個(gè)微服務(wù)。舉一個(gè)現(xiàn)實(shí)的例子：只有一個(gè)開(kāi)發(fā)人員時(shí)，盡量就做單體應(yīng)用，不要沒(méi)事找刺激拆成 10 個(gè)微服務(wù)，最終這個(gè)開(kāi)發(fā)人員還會(huì)把他合成一個(gè)。微服務(wù)要求縱向的 2 pizza 團(tuán)隊(duì)（無(wú)數(shù)個(gè)小團(tuán)隊(duì)，包含開(kāi)發(fā)、測(cè)試、運(yùn)維），當(dāng)然我們也實(shí)施過(guò)一些傳統(tǒng)大型企業(yè)，但團(tuán)隊(duì)還是處在橫向結(jié)構(gòu)的場(chǎng)景下（開(kāi)發(fā)、運(yùn)維、測(cè)試各是一個(gè)團(tuán)隊(duì)），拆分微服務(wù)讓他們很痛苦，尤其是運(yùn)維團(tuán)隊(duì)。

微服務(wù)的部署

從大體上來(lái)看，微服務(wù)至少需要部署在線上和測(cè)試環(huán)境。但需要注意的是，開(kāi)發(fā)口中的環(huán)境和此處的環(huán)境會(huì)很容易混淆，所以我們借用 K8s 命名空間的概念，使用命名空間來(lái)防止混淆。

在線上命名空間中，我們能夠保證代碼都是經(jīng)過(guò) review 的、數(shù)據(jù)庫(kù)都是線上數(shù)據(jù)。線上的應(yīng)用版本，一般分為 prod（生產(chǎn)版本）、gray（灰度版本，少部分線上流量進(jìn)入）、pre（預(yù)發(fā)版本，僅內(nèi)部人員可用）。

在測(cè)試命名空間中，測(cè)試同學(xué)和開(kāi)發(fā)同學(xué)發(fā)起流量進(jìn)行測(cè)試和開(kāi)發(fā)。在測(cè)試環(huán)境中，一般每個(gè)應(yīng)用都部署了 stable 版本，提供一個(gè)穩(wěn)定的測(cè)試環(huán)境；根據(jù)項(xiàng)目、開(kāi)發(fā)流程的不同，相關(guān)的應(yīng)用也會(huì)部署一些 project1 版本等。

另外，對(duì)于注冊(cè)中心、Kubernetes 集群、消息隊(duì)列等基礎(chǔ)組件，也應(yīng)當(dāng)在不同的部署環(huán)境中單獨(dú)部署一套。比如線上命名空間中的注冊(cè)中心，和測(cè)試命名空間中的注冊(cè)中心，應(yīng)當(dāng)分開(kāi)部署，做到硬性隔離。

微服務(wù)流量灰度路由

對(duì)于不同的命名空間，不同的部署版本，我們都要考慮到流量是怎么路由的，不合理的流量輕則困擾研發(fā)、測(cè)試進(jìn)度，重則導(dǎo)致線上事故。

線上流量

對(duì)于大部分用戶和流量，都應(yīng)該路由到 prod 版本上。

對(duì)于符合灰度要求（比如百分比規(guī)則、特定用戶等），應(yīng)該路由到 gray 版本上。

對(duì)于內(nèi)部驗(yàn)證賬號(hào)，應(yīng)該路由到 pre 版本上，驗(yàn)證功能是否正常。

測(cè)試環(huán)境流量

對(duì)于屬于項(xiàng)目環(huán)境中的流量，自然應(yīng)該路由到對(duì)應(yīng)的項(xiàng)目環(huán)境中。

對(duì)于不屬于任何項(xiàng)目環(huán)境中的流量，我們將其路由到 stable 版本中。

總結(jié)

下面這張圖能夠反映出恰當(dāng)?shù)纳a(chǎn)、測(cè)試部署環(huán)境下，整體微服務(wù)的部署、流量走向、環(huán)境隔離：

至此，我們對(duì)微服務(wù)全鏈路灰度有了一個(gè)全局（且粗糙）的認(rèn)知，我們當(dāng)然需要了解全鏈路灰度是如何實(shí)現(xiàn)的，如何讓流量根據(jù)不同的特征，路由到不同的節(jié)點(diǎn)。這些內(nèi)容就是下一篇文章要講的 《全鏈路灰度原理——從三千英尺看全鏈路灰度》 ，敬請(qǐng)期待！

點(diǎn)擊此處，前往微服務(wù)引擎官網(wǎng)查看更多詳情～

你是否還在尋找穩(wěn)定的海外服務(wù)器提供商？創(chuàng)新互聯(lián)www.cdcxhl.cn海外機(jī)房具備T級(jí)流量清洗系統(tǒng)配攻擊溯源，準(zhǔn)確流量調(diào)度確保服務(wù)器高可用性，企業(yè)級(jí)服務(wù)器適合批量采購(gòu)，新人活動(dòng)首月15元起，快前往官網(wǎng)查看詳情吧

網(wǎng)站題目：從三萬(wàn)英尺看全鏈路灰度-創(chuàng)新互聯(lián)
網(wǎng)頁(yè)路徑：http://muchs.cn/article36/deidsg.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供網(wǎng)站改版、服務(wù)器托管、營(yíng)銷型網(wǎng)站建設(shè)、小程序開(kāi)發(fā)、ChatGPT、網(wǎng)站設(shè)計(jì)

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請(qǐng)盡快告知，我們將會(huì)在第一時(shí)間刪除。文章觀點(diǎn)不代表本網(wǎng)站立場(chǎng)，如需處理請(qǐng)聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時(shí)需注明來(lái)源： 創(chuàng)新互聯(lián)