欧美成人午夜视频在线观看,欧美一区二区三区…,草比视频网,亚洲免费观看高清完整版在线观看,琪琪色综合,97男人的天堂,性生活视频网站,女裸体网站

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

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

引言

Cloud Native

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

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

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

ECS 故障節(jié)點(diǎn)上運(yùn)行著 K8s 集群的核心基礎(chǔ)組件 CoreDNS 的所有 Pod，它沒有打散，導(dǎo)致集群 DNS 解析出現(xiàn)問題。
該客戶的服務(wù)發(fā)現(xiàn)使用了有缺陷的客戶端版本（nacos-client 的 1.4.1 版本），這個(gè)版本的缺陷就是跟 DNS 有關(guān)——心跳請求在域名解析失敗后，會導(dǎo)致進(jìn)程后續(xù)不會再續(xù)約心跳，只有重啟才能恢復(fù)。
這個(gè)缺陷版本實(shí)際上是已知問題，阿里云在 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ù)無法調(diào)用下游，可用性降低，業(yè)務(wù)受損。下圖示意的是客戶端缺陷導(dǎo)致問題的根因：

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

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

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

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

Cloud Native

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

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

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

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

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

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

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

注冊配置中心在微服務(wù)體系的核心鏈路上，牽一發(fā)動全身，任何一個(gè)抖動都可能會較大范圍地影響整個(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)自動離群，就能盡可能減少影響。

減少上下游依賴

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

變更可灰度

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

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

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

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

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

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

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

核心思路就是：盡早識別、盡快處理

識別 —— 可觀測

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Cloud Native

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

?Consumer 端高可用

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

推空保護(hù)

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

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

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

無推空保護(hù)

Provider 端注冊失?。ū热缇W(wǎng)絡(luò)、SDKbug 等原因）

注冊中心判斷 Provider 心跳過期

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

開啟推空保護(hù)

同上

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

開啟方式

開啟方式比較簡單

開源的客戶端 nacos-client 1.4.2 以上版本支持

配置項(xiàng)

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

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

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

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

服務(wù)降級

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

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

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

?Provider 端高可用

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

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

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

下面我們來具體看一下：

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

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

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

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

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

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

同上；

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

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

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

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

離群實(shí)例摘除

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

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

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

Request 處理的線程池滿

依賴的 RDS 連接異?；蚵?SQL

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

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

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

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

無損下線

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

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

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

配置管理高可用方案

Cloud Native

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

配置管理解決什么問題？

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

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

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

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

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

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

功能、活動頁面等開關(guān)。

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

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

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

客戶端高可用

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

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

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

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

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

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

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

服務(wù)端高可用

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

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

限連接：單機(jī)最大連接限流，單客戶端 IP 的連接限流

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

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

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

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

配置灰度

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

變更對比

動手實(shí)踐

Cloud Native

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

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

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

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

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

基本思路：

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

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

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

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

?開始

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

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

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

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

部署應(yīng)用

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

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

配置示意（無法直接使用）：


# 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)注冊服務(wù)

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

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

驗(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]

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

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

觀測調(diào)用

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

注入故障

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

這里我們可以使用 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á)注冊中心的 8848 端口就被禁用了）。這里 B 的下游是 C。

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

再次觀測

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

回到大盤，成功率在 50% 附近不再波動。

小結(jié)

Cloud Native

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

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

集群高可用

減少上下游依賴

變更可灰度

服務(wù)可降級、限流、熔斷

識別 —— 可觀測

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

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

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

推空保護(hù)

開啟方式

服務(wù)降級

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

離群實(shí)例摘除

無損下線

客戶端高可用

服務(wù)端高可用

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

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

部署應(yīng)用

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

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

觀測調(diào)用

注入故障

再次觀測

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

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