天天五月,色猫咪AV在线,黄色小片免费视频,精品内射一区,亚洲青娱乐在线观看,91久久久久,超碰人人澡,色色影音先锋

作者：三辰｜阿里云云原生微服務(wù)基礎(chǔ)架構(gòu)團(tuán)隊(duì)技術(shù)專(zhuān)家，負(fù)責(zé) MSE 引擎高可用架構(gòu)

本篇是微服務(wù)高可用最佳實(shí)踐系列分享的開(kāi)篇，系列內(nèi)容持續(xù)更新中，期待大家的關(guān)注。

引言

Cloud Native

在開(kāi)始正式內(nèi)容之前，先給大家分享一個(gè)真實(shí)的案例。

某客戶在阿里云上使用 K8s 集群部署了許多自己的微服務(wù)，但是某一天，其中一臺(tái)節(jié)點(diǎn)的網(wǎng)卡發(fā)生了異常，最終導(dǎo)致服務(wù)不可用，無(wú)法調(diào)用下游，業(yè)務(wù)受損。

我們來(lái)看一下這個(gè)問(wèn)題鏈?zhǔn)侨绾涡纬傻模?/span>

ECS 故障節(jié)點(diǎn)上運(yùn)行著 K8s 集群的核心基礎(chǔ)組件 CoreDNS 的所有 Pod，它沒(méi)有打散，導(dǎo)致集群 DNS 解析出現(xiàn)問(wèn)題。
該客戶的服務(wù)發(fā)現(xiàn)使用了有缺陷的客戶端版本（nacos-client 的 1.4.1 版本），這個(gè)版本的缺陷就是跟 DNS 有關(guān)——心跳請(qǐng)求在域名解析失敗后，會(huì)導(dǎo)致進(jìn)程后續(xù)不會(huì)再續(xù)約心跳，只有重啟才能恢復(fù)。
這個(gè)缺陷版本實(shí)際上是已知問(wèn)題，阿里云在 5 月份推送了 nacos-client 1.4.1 存在嚴(yán)重 bug 的公告，但客戶研發(fā)未收到通知，進(jìn)而在生產(chǎn)環(huán)境中使用了這個(gè)版本。

風(fēng)險(xiǎn)環(huán)環(huán)相扣，缺一不可。

最終導(dǎo)致故障的原因是服務(wù)無(wú)法調(diào)用下游，可用性降低，業(yè)務(wù)受損。下圖示意的是客戶端缺陷導(dǎo)致問(wèn)題的根因：

Provider 客戶端在心跳續(xù)約時(shí)發(fā)生 DNS 異常；
心跳線程正確地處理這個(gè) DNS 異常，導(dǎo)致線程意外退出了；
注冊(cè)中心的正常機(jī)制是，心跳不續(xù)約，30 秒后自動(dòng)下線。由于 CoreDNS 影響的是整個(gè) K8s 集群的 DNS 解析，所以 Provider 的所有實(shí)例都遇到相同的問(wèn)題，整個(gè)服務(wù)所有實(shí)例都被下線；
在 Consumer 這一側(cè)，收到推送的空列表后，無(wú)法找到下游，那么調(diào)用它的上游（比如網(wǎng)關(guān)）就會(huì)發(fā)生異常。

回顧整個(gè)案例，每一環(huán)每個(gè)風(fēng)險(xiǎn)看起來(lái)發(fā)生概率都很小，但是一旦發(fā)生就會(huì)造成惡劣的影響。

所以，本篇文章就來(lái)探討，微服務(wù)領(lǐng)域的高可用方案怎么設(shè)計(jì)，細(xì)化到服務(wù)發(fā)現(xiàn)和配置管理領(lǐng)域，都有哪些具體的方案。

微服務(wù)高可用方案

Cloud Native

首先，有一個(gè)事實(shí)不容改變：沒(méi)有任何系統(tǒng)是百分百?zèng)]有問(wèn)題的，所以高可用架構(gòu)方案就是面對(duì)失?。L(fēng)險(xiǎn)）設(shè)計(jì)的。

風(fēng)險(xiǎn)是無(wú)處不在的，盡管有很多發(fā)生概率很小很小，卻都無(wú)法完全避免。

在微服務(wù)系統(tǒng)中，都有哪些風(fēng)險(xiǎn)的可能？

這只是其中一部分，但是在阿里巴巴內(nèi)部十幾年的微服務(wù)實(shí)踐過(guò)程中，這些問(wèn)題全部都遇到過(guò)，而且有些還不止一次。

雖然看起來(lái)坑很多，但我們依然能夠很好地保障雙十一大促的穩(wěn)定，背后靠的就是成熟穩(wěn)健的高可用體系建設(shè)。

我們不能完全避免風(fēng)險(xiǎn)的發(fā)生，但我們可以控制它（的影響），這就是做高可用的本質(zhì)。

控制風(fēng)險(xiǎn)有哪些策略？

注冊(cè)配置中心在微服務(wù)體系的核心鏈路上，牽一發(fā)動(dòng)全身，任何一個(gè)抖動(dòng)都可能會(huì)較大范圍地影響整個(gè)系統(tǒng)的穩(wěn)定性。

?策略一：縮小風(fēng)險(xiǎn)影響范圍

集群高可用

多副本：不少于 3 個(gè)節(jié)點(diǎn)進(jìn)行實(shí)例部署。

多可用區(qū)（同城容災(zāi)）：將集群的不同節(jié)點(diǎn)部署在不同可用區(qū)（AZ）中。

當(dāng)節(jié)點(diǎn)或可用區(qū)發(fā)生的故障時(shí)，影響范圍只是集群其中的一部分，如果能夠做到迅速切換，并將故障節(jié)點(diǎn)自動(dòng)離群，就能盡可能減少影響。

減少上下游依賴(lài)

系統(tǒng)設(shè)計(jì)上應(yīng)該盡可能地減少上下游依賴(lài)，越多的依賴(lài)，可能會(huì)在被依賴(lài)系統(tǒng)發(fā)生問(wèn)題時(shí)，讓整體服務(wù)不可用（一般是一個(gè)功能塊的不可用）。如果有必要的依賴(lài)，也必須要求是高可用的架構(gòu)。

變更可灰度

新版本迭代發(fā)布，應(yīng)該從最小范圍開(kāi)始灰度，按用戶、按 Region 分級(jí)，逐步擴(kuò)大變更范圍。一旦出現(xiàn)問(wèn)題，也只是在灰度范圍內(nèi)造成影響，縮小問(wèn)題爆炸半徑。

服務(wù)可降級(jí)、限流、熔斷

注冊(cè)中心異常負(fù)載的情況下，降級(jí)心跳續(xù)約時(shí)間、降級(jí)一些非核心功能等

針對(duì)異常流量進(jìn)行限流，將流量限制在容量范圍內(nèi)，保護(hù)部分流量是可用的

客戶端側(cè)，異常時(shí)降級(jí)到使用本地緩存（推空保護(hù)也是一種降級(jí)方案），暫時(shí)犧牲列表更新的一致性，以保證可用性

如圖，微服務(wù)引擎 MSE 的同城雙活三節(jié)點(diǎn)的架構(gòu)，經(jīng)過(guò)精簡(jiǎn)的上下游依賴(lài)，每一個(gè)都保證高可用架構(gòu)。多節(jié)點(diǎn)的 MSE 實(shí)例，通過(guò)底層的調(diào)度能力，會(huì)自動(dòng)分配到不同的可用區(qū)上，組成多副本集群。

?策略二：縮短風(fēng)險(xiǎn)發(fā)生持續(xù)時(shí)間

核心思路就是：盡早識(shí)別、盡快處理

識(shí)別 —— 可觀測(cè)

例如，基于 Prometheus 對(duì)實(shí)例進(jìn)行監(jiān)控和報(bào)警能力建設(shè)。

進(jìn)一步地，在產(chǎn)品層面上做更強(qiáng)的觀測(cè)能力：包括大盤(pán)、告警收斂/分級(jí)（識(shí)別問(wèn)題）、針對(duì)大客戶的保障、以及服務(wù)等級(jí)的建設(shè)。

MSE注冊(cè)配置中心目前提供的服務(wù)等級(jí)是 99.95%，并且正在向 4 個(gè) 9（99.99%）邁進(jìn)。

快速處理 —— 應(yīng)急響應(yīng)

應(yīng)急響應(yīng)的機(jī)制要建立，快速有效地通知到正確的人員范圍，快速執(zhí)行預(yù)案的能力（意識(shí)到白屏與黑屏的效率差異），常態(tài)化地進(jìn)行故障應(yīng)急的演練。

預(yù)案是指不管熟不熟悉你的系統(tǒng)的人，都可以放心執(zhí)行，這背后需要一套沉淀好有含金量的技術(shù)支撐（技術(shù)厚度）。

?策略三：減少觸碰風(fēng)險(xiǎn)的次數(shù)

減少不必要的發(fā)布，例如：增加迭代效率，不隨意發(fā)布；重要事件、大促期間進(jìn)行封網(wǎng)。

從概率角度來(lái)看，無(wú)論風(fēng)險(xiǎn)概率有多低，不斷嘗試，風(fēng)險(xiǎn)發(fā)生的聯(lián)合概率就會(huì)無(wú)限趨近于 1。

?策略四：降低風(fēng)險(xiǎn)發(fā)生概率

架構(gòu)升級(jí)，改進(jìn)設(shè)計(jì)

Nacos2.0，不僅是性能做了提升，也做了架構(gòu)上的升級(jí)：

升級(jí)數(shù)據(jù)存儲(chǔ)結(jié)構(gòu)，Service 級(jí)粒度提升到到 Instance 級(jí)分區(qū)容錯(cuò)（繞開(kāi)了 Service 級(jí)數(shù)據(jù)不一致造成的服務(wù)掛的問(wèn)題）；
升級(jí)連接模型（長(zhǎng)連接），減少對(duì)線程、連接、DNS 的依賴(lài)。

提前發(fā)現(xiàn)風(fēng)險(xiǎn)

這個(gè)「提前」是指在設(shè)計(jì)、研發(fā)、測(cè)試階段盡可能地暴露潛在風(fēng)險(xiǎn)；
提前通過(guò)容量評(píng)估預(yù)知容量風(fēng)險(xiǎn)水位是在哪里；
通過(guò)定期的故障演練提前發(fā)現(xiàn)上下游環(huán)境風(fēng)險(xiǎn)，驗(yàn)證系統(tǒng)健壯性。

如圖，阿里巴巴大促高可用體系，不斷做壓測(cè)演練、驗(yàn)證系統(tǒng)健壯性和彈性、觀測(cè)追蹤系統(tǒng)問(wèn)題、驗(yàn)證限流、降級(jí)等預(yù)案的可執(zhí)行性。

服務(wù)發(fā)現(xiàn)高可用方案

Cloud Native

服務(wù)發(fā)現(xiàn)包含服務(wù)消費(fèi)者（Consumer）和服務(wù)提供者（Provider）。

?Consumer 端高可用

通過(guò)推空保護(hù)、服務(wù)降級(jí)等手段，達(dá)到 Consumer 端的容災(zāi)目的。

推空保護(hù)

可以應(yīng)對(duì)開(kāi)頭講的案例，服務(wù)空列表推送自動(dòng)降級(jí)到緩存數(shù)據(jù)。

服務(wù)消費(fèi)者（Consumer）會(huì)從注冊(cè)中心上訂閱服務(wù)提供者（Provider）的實(shí)例列表。

當(dāng)遇到突發(fā)情況（例如，可用區(qū)斷網(wǎng)，Provider端無(wú)法上報(bào)心跳）或注冊(cè)中心（變配、重啟、升降級(jí)）出現(xiàn)非預(yù)期異常時(shí)，都有可能導(dǎo)致訂閱異常，影響服務(wù)消費(fèi)者（Consumer）的可用性。

無(wú)推空保護(hù)

Provider 端注冊(cè)失敗（比如網(wǎng)絡(luò)、SDKbug 等原因）

注冊(cè)中心判斷 Provider 心跳過(guò)期

Consumer 訂閱到空列表，業(yè)務(wù)中斷報(bào)錯(cuò)

開(kāi)啟推空保護(hù)

同上

Consumer 訂閱到空列表，推空保護(hù)生效，丟棄變更，保障業(yè)務(wù)服務(wù)可用

開(kāi)啟方式

開(kāi)啟方式比較簡(jiǎn)單

開(kāi)源的客戶端 nacos-client 1.4.2 以上版本支持

配置項(xiàng)

SpingCloudAlibaba 在 spring 配置項(xiàng)里增加：
spring.cloud.nacos.discovery.namingPushEmptyProtection=true

Dubbo 加上 registryUrl 的參數(shù)：
namingPushEmptyProtection=true

提空保護(hù)依賴(lài)緩存，所以需要持久化緩存目錄，避免重啟后丟失，路徑為：

${user.home}/nacos/naming/${namespaceId}

服務(wù)降級(jí)

Consumer 端可以根據(jù)不同的策略選擇是否將某個(gè)調(diào)用接口降級(jí)，起到對(duì)業(yè)務(wù)請(qǐng)求流程的保護(hù)（將寶貴的下游 Provider 資源保留給重要的業(yè)務(wù) Consumer 使用），保護(hù)重要業(yè)務(wù)的可用性。

服務(wù)降級(jí)的具體策略，包含返回 Null 值、返回 Exception 異常、返回自定義 JSON 數(shù)據(jù)和自定義回調(diào)。

MSE 微服務(wù)治理中心中默認(rèn)就具備該項(xiàng)高可用能力。

?Provider 端高可用

Provider 側(cè)通過(guò)注冊(cè)中心和服務(wù)治理提供的容災(zāi)保護(hù)、離群摘除、無(wú)損下線等方案提升可用性。

容災(zāi)保護(hù)

容災(zāi)保護(hù)主要用于避免集群在異常流量下出現(xiàn)雪崩的場(chǎng)景。

下面我們來(lái)具體看一下：

無(wú)容災(zāi)保護(hù)（默認(rèn)閾值 =0）

突發(fā)請(qǐng)求量增加，容量水位較高時(shí)，個(gè)別 Provider 發(fā)生故障；

注冊(cè)中心將故障節(jié)點(diǎn)摘除，全量流量會(huì)給剩余節(jié)點(diǎn)；

剩余節(jié)點(diǎn)負(fù)載變高，大概率也會(huì)故障；

最后所有節(jié)點(diǎn)故障，100% 無(wú)法提供服務(wù)。

開(kāi)啟容災(zāi)保護(hù)（閾值=0.6）

同上；

故障節(jié)點(diǎn)數(shù)達(dá)到保護(hù)閾值，流量平攤給所有機(jī)器；

最終保障 50% 節(jié)點(diǎn)能夠提供服務(wù)。

容災(zāi)保護(hù)能力，在緊急情況下，能夠保存服務(wù)可用性在一定的水平之上，可以說(shuō)是整體系統(tǒng)的兜底了。

這套方案曾經(jīng)救過(guò)不少業(yè)務(wù)系統(tǒng)。

離群實(shí)例摘除

心跳續(xù)約是注冊(cè)中心感知實(shí)例可用性的基本途徑。

但是在特定情況下，心跳存續(xù)并不能完全等同于服務(wù)可用。

因?yàn)槿匀淮嬖谛奶＃?wù)不可用的情況，例如：

Request 處理的線程池滿

依賴(lài)的 RDS 連接異?；蚵?SQL

微服務(wù)治理中心提供離群實(shí)例摘除

基于異常檢測(cè)的摘除策略：包含網(wǎng)絡(luò)異常和網(wǎng)絡(luò)異常 + 業(yè)務(wù)異常（HTTP 5xx）

設(shè)置異常閾值、QPS 下限、摘除比例下限

離群實(shí)例摘除的能力是一個(gè)補(bǔ)充，根據(jù)特定接口的調(diào)用異常特征，來(lái)衡量服務(wù)的可用性。

無(wú)損下線

無(wú)損下線，又叫優(yōu)雅下線、或者平滑下線，都是一個(gè)意思。首先看什么是有損下線：

Provider 實(shí)例進(jìn)行升級(jí)過(guò)程中，下線后心跳在注冊(cè)中心存約以及變更生效都有一定的時(shí)間，在這個(gè)期間 Consumer 端訂閱列表仍然沒(méi)有更新到下線后的版本，如果魯莽地將 Provider 停止服務(wù)，會(huì)造成一部分的流量損失。

無(wú)損下線有很多不同的解決方案，但侵入性最低的還是服務(wù)治理中心默認(rèn)提供的能力，無(wú)感地整合到發(fā)布流程中，完成自動(dòng)執(zhí)行。免去繁瑣的運(yùn)維腳本邏輯的維護(hù)。

配置管理高可用方案

Cloud Native

配置管理主要包含配置訂閱和配置發(fā)布兩類(lèi)操作。

配置管理解決什么問(wèn)題？

多環(huán)境、多機(jī)器的配置發(fā)布、配置動(dòng)態(tài)實(shí)時(shí)推送。

?基于配置管理做服務(wù)高可用

微服務(wù)如何基于配置管理做高可用方案？

發(fā)布環(huán)境管理

一次管理上百臺(tái)機(jī)器、多套環(huán)境，如何正確無(wú)誤地推送、誤操作或出現(xiàn)線上問(wèn)題如何快速回滾，發(fā)布過(guò)程如何灰度。

業(yè)務(wù)開(kāi)關(guān)動(dòng)態(tài)推送

功能、活動(dòng)頁(yè)面等開(kāi)關(guān)。

容災(zāi)降級(jí)預(yù)案的推送

預(yù)置的方案通過(guò)推送開(kāi)啟，實(shí)時(shí)調(diào)整流控閾值等。

上圖是大促期間配置管理整體高可用解決方案。比如降級(jí)非核心業(yè)務(wù)、功能降級(jí)、日志降級(jí)、禁用高風(fēng)險(xiǎn)操作。

客戶端高可用

配置管理客戶端側(cè)同樣有容災(zāi)方案。

本地目錄分為兩級(jí)，高優(yōu)先級(jí)是容災(zāi)目錄、低優(yōu)先級(jí)是緩存目錄。

緩存目錄：每次客戶端和配置中心進(jìn)行數(shù)據(jù)交互后，會(huì)保存最新的配置內(nèi)容至本地緩存目錄中，當(dāng)服務(wù)端不可用狀態(tài)下，會(huì)使用本地緩存目錄中內(nèi)容。

容災(zāi)目錄：當(dāng)服務(wù)端不可用狀態(tài)下，可以在本地的容災(zāi)目錄中手動(dòng)更新配置內(nèi)容，客戶端會(huì)優(yōu)先加載容災(zāi)目錄下的內(nèi)容，模擬服務(wù)端變更推送的效果。

簡(jiǎn)單來(lái)說(shuō)，當(dāng)配置中心不可用時(shí)，優(yōu)先查看容災(zāi)目錄的配置，否則使用之前拉取到的緩存。

容災(zāi)目錄的設(shè)計(jì)，是因?yàn)橛袝r(shí)候不一定會(huì)有緩存過(guò)的配置，或者業(yè)務(wù)需要緊急覆蓋使用新的內(nèi)容開(kāi)啟一些必要的預(yù)案和配置。

整體思路就是，無(wú)法發(fā)生什么問(wèn)題，無(wú)論如何，都要能夠使客戶端能夠讀取到正確的配置，保證微服務(wù)的可用性。

服務(wù)端高可用

在配置中心側(cè)，主要是針對(duì)讀、寫(xiě)的限流。

限制連接數(shù)、限制寫(xiě)：

限連接：?jiǎn)螜C(jī)最大連接限流，單客戶端 IP 的連接限流

限寫(xiě)接口：發(fā)布操作&特定配置的秒級(jí)分鐘級(jí)數(shù)量限流

控制操作風(fēng)險(xiǎn)

控制人員做配置發(fā)布的風(fēng)險(xiǎn)。

配置發(fā)布的操作是可灰度、可追溯、可回滾的。

配置灰度

發(fā)布?xì)v史&回滾

變更對(duì)比

動(dòng)手實(shí)踐

Cloud Native

最后我們一起來(lái)做一個(gè)實(shí)踐。

場(chǎng)景取自前面提到的一個(gè)高可用方案，在服務(wù)提供者所有機(jī)器發(fā)生注冊(cè)異常的情況下，看服務(wù)消費(fèi)者在推空保護(hù)打開(kāi)的情況下的表現(xiàn)。

?實(shí)驗(yàn)架構(gòu)和思路

上圖是本次實(shí)踐的架構(gòu)，右側(cè)是一個(gè)簡(jiǎn)單的調(diào)用場(chǎng)景，外部流量通過(guò)網(wǎng)關(guān)接入，這里選擇了 MSE 產(chǎn)品矩陣中的云原生網(wǎng)關(guān)，依靠它提供的可觀測(cè)能力，方便我們觀察服務(wù)調(diào)用情況。

網(wǎng)關(guān)的下游有 A、B、C 三個(gè)應(yīng)用，支持使用配置管理的方式動(dòng)態(tài)地將調(diào)用關(guān)系連接起來(lái)，后面我們會(huì)實(shí)踐到。

基本思路：

部署服務(wù)，調(diào)整調(diào)用關(guān)系是網(wǎng)關(guān)->A->B->C，查看網(wǎng)關(guān)調(diào)用成功率。
通過(guò)模擬網(wǎng)絡(luò)問(wèn)題，將應(yīng)用B與注冊(cè)中心的心跳鏈路斷開(kāi)，模擬注冊(cè)異常的發(fā)生。
再次查看網(wǎng)關(guān)調(diào)用成功率，期望服務(wù) A->B 的鏈路不受注冊(cè)異常的影響。

為了方便對(duì)照，應(yīng)用 A 會(huì)部署兩種版本，一種是開(kāi)啟推空保護(hù)的，一種是沒(méi)有開(kāi)啟的情況。

最終期望的結(jié)果是，推空保護(hù)開(kāi)關(guān)開(kāi)啟后，能夠幫助應(yīng)用 A 在發(fā)生異常的情況下，繼續(xù)能夠?qū)ぶ返綉?yīng)用B。

網(wǎng)關(guān)的流量打到應(yīng)用 A 之后，可以觀察到，接口的成功率應(yīng)該正好在 50%。

?開(kāi)始

接下來(lái)開(kāi)始動(dòng)手實(shí)踐吧。這里我選用阿里云 MSE+ACK 組合做完整的方案。

環(huán)境準(zhǔn)備

首先，購(gòu)買(mǎi)好一套 MSE 注冊(cè)配置中心專(zhuān)業(yè)版，和一套 MSE 云原生網(wǎng)關(guān)。這邊不介紹具體的購(gòu)買(mǎi)流程。

在應(yīng)用部署前，提前準(zhǔn)備好配置。這邊我們可以先配置 A 的下游是 C，B 的下游也是 C。

部署應(yīng)用

接下來(lái)我們基于 ACK 部署三個(gè)應(yīng)用?？梢詮南旅娴呐渲每吹?，應(yīng)用 A 這個(gè)版本 spring-cloud-a-b，推空保護(hù)開(kāi)關(guān)已經(jīng)打開(kāi)。

這里 demo 選用的 nacos 客戶端版本是 1.4.2，因?yàn)橥瓶毡Ｗo(hù)在這個(gè)版本之后才支持。

配置示意（無(wú)法直接使用）：


# A 應(yīng)用 base 版本---apiVersion: apps/v1kind: Deploymentmetadata:  labels:    app: spring-cloud-a  name: spring-cloud-a-bspec:  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: spring.cloud.nacos.discovery.server-addr          value: mse-xxx-nacos-ans.mse.aliyuncs.com:8848        - name: spring.cloud.nacos.config.server-addr          value: mse-xxx-nacos-ans.mse.aliyuncs.com:8848        - name: spring.cloud.nacos.discovery.metadata.version          value: base        - name: spring.application.name          value: sc-A        - name: spring.cloud.nacos.discovery.namingPushEmptyProtection          value: "true"        image: mse-demo/demo:1.4.2        imagePullPolicy: Always        name: spring-cloud-a        ports:        - containerPort: 8080          protocol: TCP        resources:          requests:            cpu: 250m            memory: 512Mi---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: spring.cloud.nacos.discovery.server-addr          value: mse-xxx-nacos-ans.mse.aliyuncs.com:8848        - name: spring.cloud.nacos.config.server-addr          value: mse-xxx-nacos-ans.mse.aliyuncs.com:8848        - name: spring.cloud.nacos.discovery.metadata.version          value: base        - name: spring.application.name          value: sc-A        image: mse-demo/demo:1.4.2        imagePullPolicy: Always        name: spring-cloud-a        ports:        - containerPort: 8080          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: spring.cloud.nacos.discovery.server-addr          value: mse-xxx-nacos-ans.mse.aliyuncs.com:8848        - name: spring.cloud.nacos.config.server-addr          value: mse-xxx-nacos-ans.mse.aliyuncs.com:8848        - name: spring.application.name          value: sc-B        image: mse-demo/demo:1.4.2        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: spring.cloud.nacos.discovery.server-addr          value: mse-xxx-nacos-ans.mse.aliyuncs.com:8848        - name: spring.cloud.nacos.config.server-addr          value: mse-xxx-nacos-ans.mse.aliyuncs.com:8848        - name: spring.application.name          value: sc-C        image: mse-demo/demo:1.4.2        imagePullPolicy: Always        name: spring-cloud-c        ports:        - containerPort: 8080          protocol: TCP        resources:          requests:            cpu: 250m            memory: 512Mi

部署應(yīng)用：

在網(wǎng)關(guān)注冊(cè)服務(wù)

應(yīng)用部署好之后，在 MSE 云原生網(wǎng)關(guān)中，關(guān)聯(lián)上 MSE 的注冊(cè)中心，并將服務(wù)注冊(cè)進(jìn)來(lái)。

我們?cè)O(shè)計(jì)的是網(wǎng)關(guān)只調(diào)用 A，所以只需要將 A 放進(jìn)來(lái)注冊(cè)進(jìn)來(lái)即可。

驗(yàn)證和調(diào)整鏈路

基于 curl 命令驗(yàn)證一下鏈路：


$ curl http://${網(wǎng)關(guān)IP}/ipsc-A[192.168.1.194] --> sc-C[192.168.1.195]

驗(yàn)證一下鏈路。?可以看到這時(shí)候 A 調(diào)用的是 C，我們將配置做一下變更，實(shí)時(shí)地將 A 的下游改為 B。

再看一下，這時(shí)三個(gè)應(yīng)用的調(diào)用關(guān)系是 ABC，符合我們之前的計(jì)劃。


$ curl http://${網(wǎng)關(guān)IP}/ipsc-A[192.168.1.194] --> sc-B[192.168.1.191] --> sc-C[192.168.1.180]

接下來(lái)，我們通過(guò)一段命令，連續(xù)地調(diào)用接口，模擬真實(shí)場(chǎng)景下不間斷的業(yè)務(wù)流量。

$ while true; do sleep .1 ; curl -so /dev/null http://${網(wǎng)關(guān)IP}/ip ;done

觀測(cè)調(diào)用

通過(guò)網(wǎng)關(guān)監(jiān)控大盤(pán)，可以觀察到成功率。

注入故障

一切正常，現(xiàn)在我們可以開(kāi)始注入故障。

這里我們可以使用 K8s 的 NetworkPolicy 的機(jī)制，模擬出口網(wǎng)絡(luò)異常。


kind: NetworkPolicyapiVersion: networking.k8s.io/v1metadata:  name: block-registry-from-bspec:  podSelector:    matchLabels:      app: spring-cloud-b  ingress:  - {}  egress:  - to:    - ipBlock:        cidr: 0.0.0.0/0    ports:    - protocol: TCP      port: 8080

這個(gè) 8080 端口的意思是，不影響內(nèi)網(wǎng)調(diào)用下游的應(yīng)用端口，只禁用其它出口流量（比如到達(dá)注冊(cè)中心的 8848 端口就被禁用了）。這里 B 的下游是 C。

網(wǎng)絡(luò)切斷后，注冊(cè)中心的心跳續(xù)約不上，過(guò)一會(huì)兒（30 秒后）就會(huì)將應(yīng)用 B 的所有 IP 摘除。

再次觀測(cè)

再觀察大盤(pán)數(shù)據(jù)庫(kù)，成功率開(kāi)始下降，這時(shí)候，在控制臺(tái)上已經(jīng)看不到應(yīng)用 B 的 IP 了。

回到大盤(pán)，成功率在 50% 附近不再波動(dòng)。

小結(jié)

Cloud Native

通過(guò)實(shí)踐，我們模擬了一次真實(shí)的風(fēng)險(xiǎn)發(fā)生的場(chǎng)景，并且通過(guò)客戶端的高可用方案（推空保護(hù)），成功實(shí)現(xiàn)了對(duì)風(fēng)險(xiǎn)的控制，防止服務(wù)調(diào)用的發(fā)生異常。

服務(wù)發(fā)現(xiàn)與配置管理高可用最佳實(shí)踐

集群高可用

減少上下游依賴(lài)

變更可灰度

服務(wù)可降級(jí)、限流、熔斷

識(shí)別 —— 可觀測(cè)

快速處理 —— 應(yīng)急響應(yīng)

架構(gòu)升級(jí)，改進(jìn)設(shè)計(jì)

提前發(fā)現(xiàn)風(fēng)險(xiǎn)

推空保護(hù)

開(kāi)啟方式

服務(wù)降級(jí)

容災(zāi)保護(hù)

離群實(shí)例摘除

無(wú)損下線

客戶端高可用

服務(wù)端高可用

控制操作風(fēng)險(xiǎn)

環(huán)境準(zhǔn)備

部署應(yīng)用

在網(wǎng)關(guān)注冊(cè)服務(wù)

驗(yàn)證和調(diào)整鏈路

觀測(cè)調(diào)用

注入故障

再次觀測(cè)

服務(wù)可降級(jí)、限流、熔斷

架構(gòu)升級(jí)，改進(jìn)設(shè)計(jì)