作者：三辰｜阿里云云原生微服務基礎架構團隊技術專家，負責 MSE 引擎高可用架構

****本篇是微服務高可用最佳實踐系列分享的開篇，系列內容持續更新中，期待大家的關注。

引言

在開始正式內容之前，先給大家分享一個真實的案例。

某客戶在阿里云上使用 K8s 集群部署了許多自己的微服務，但是某一天，其中一臺節點的網卡發生了異常，最終導致服務不可用，無法調用下游，業務受損。我們來看一下這個問題鏈是如何形成的？

ECS 故障節點上運行著 K8s 集群的核心基礎組件 CoreDNS 的所有 Pod，它沒有打散，導致集群 DNS 解析出現問題。

該客戶的服務發現使用了有缺陷的客戶端版本（nacos-client 的 1.4.1 版本），這個版本的缺陷就是跟 DNS 有關——心跳請求在域名解析失敗后，會導致進程后續不會再續約心跳，只有重啟才能恢復。

這個缺陷版本實際上是已知問題，阿里云在 5 月份推送了 nacos-client 1.4.1 存在嚴重 bug 的公告，但客戶研發未收到通知，進而在生產環境中使用了這個版本。

風險環環相扣，缺一不可。

最終導致故障的原因是服務無法調用下游，可用性降低，業務受損。下圖示意的是客戶端缺陷導致問題的根因：

Provider 客戶端在心跳續約時發生 DNS 異常；

心跳線程正確地處理這個 DNS 異常，導致線程意外退出了；

注冊中心的正常機制是，心跳不續約，30 秒后自動下線。由于 CoreDNS 影響的是整個 K8s 集群的 DNS 解析，所以 Provider 的所有實例都遇到相同的問題，整個服務所有實例都被下線；

在 Consumer 這一側，收到推送的空列表后，無法找到下游，那么調用它的上游（比如網關）就會發生異常。

回顧整個案例，每一環每個風險看起來發生概率都很小，但是一旦發生就會造成惡劣的影響。

所以，本篇文章就來探討，微服務領域的高可用方案怎么設計，細化到服務發現和配置管理領域，都有哪些具體的方案。

微服務高可用方案

首先，有一個事實不容改變：沒有任何系統是百分百沒有問題的，所以高可用架構方案就是面對失敗（風險）設計的。

風險是無處不在的，盡管有很多發生概率很小很小，卻都無法完全避免。

在微服務系統中，都有哪些風險的可能？

這只是其中一部分，但是在阿里巴巴內部十幾年的微服務實踐過程中，這些問題全部都遇到過，而且有些還不止一次。雖然看起來坑很多，但我們依然能夠很好地保障雙十一大促的穩定，背后靠的就是成熟穩健的高可用體系建設。

我們不能完全避免風險的發生，但我們可以控制它（的影響），這就是做高可用的本質。

控制風險有哪些策略？

注冊配置中心在微服務體系的核心鏈路上，牽一發動全身，任何一個抖動都可能會較大范圍地影響整個系統的穩定性。

策略一：縮小風險影響范圍

集群高可用

多副本： 不少于 3 個節點進行實例部署。

多可用區（同城容災）： 將集群的不同節點部署在不同可用區（AZ）中。當節點或可用區發生的故障時，影響范圍只是集群其中的一部分，如果能夠做到迅速切換，并將故障節點自動離群，就能盡可能減少影響。

減少上下游依賴

系統設計上應該盡可能地減少上下游依賴，越多的依賴，可能會在被依賴系統發生問題時，讓整體服務不可用（一般是一個功能塊的不可用）。如果有必要的依賴，也必須要求是高可用的架構。

變更可灰度

新版本迭代發布，應該從最小范圍開始灰度，按用戶、按 Region 分級，逐步擴大變更范圍。一旦出現問題，也只是在灰度范圍內造成影響，縮小問題爆炸半徑。

服務可降級、限流、熔斷

• 注冊中心異常負載的情況下，降級心跳續約時間、降級一些非核心功能等

• 針對異常流量進行限流，將流量限制在容量范圍內，保護部分流量是可用的

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

如圖，微服務引擎 MSE 的同城雙活三節點的架構，經過精簡的上下游依賴，每一個都保證高可用架構。多節點的 MSE 實例，通過底層的調度能力，會自動分配到不同的可用區上，組成多副本集群。

策略二：縮短風險發生持續時間

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

識別 —— 可觀測

例如，基于 Prometheus 對實例進行監控和報警能力建設。

進一步地，在產品層面上做更強的觀測能力：包括大盤、告警收斂/分級（識別問題）、針對大客戶的保障、以及服務等級的建設。

MSE注冊配置中心目前提供的服務等級是 99.95%，并且正在向 4 個 9（99.99%）邁進。

快速處理 —— 應急響應

應急響應的機制要建立，快速有效地通知到正確的人員范圍，快速執行預案的能力（意識到白屏與黑屏的效率差異），常態化地進行故障應急的演練。

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

策略三：減少觸碰風險的次數

減少不必要的發布，例如：增加迭代效率，不隨意發布；重要事件、大促期間進行封網。

從概率角度來看，無論風險概率有多低，不斷嘗試，風險發生的聯合概率就會無限趨近于 1。

策略四：降低風險發生概率

架構升級，改進設計

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

升級數據存儲結構，Service 級粒度提升到到 Instance 級分區容錯（繞開了 Service 級數據不一致造成的服務掛的問題）；

升級連接模型（長連接），減少對線程、連接、DNS 的依賴。

提前發現風險

這個「提前」是指在設計、研發、測試階段盡可能地暴露潛在風險；

提前通過容量評估預知容量風險水位是在哪里；

通過定期的故障演練提前發現上下游環境風險，驗證系統健壯性。

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

服務發現高可用方案

服務發現包含服務消費者（Consumer）和服務提供者（Provider）。

Consumer 端高可用

通過推空保護、服務降級等手段，達到 Consumer 端的容災目的。

推空保護

可以應對開頭講的案例，服務空列表推送自動降級到緩存數據。

服務消費者（Consumer）會從注冊中心上訂閱服務提供者（Provider）的實例列表。

當遇到突發情況（例如，可用區斷網，Provider端無法上報心跳） 或 注冊中心（變配、重啟、升降級）出現非預期異常時，都有可能導致訂閱異常，影響服務消費者（Consumer）的可用性。

無推空保護

• Provider 端注冊失敗（比如網絡、SDKbug 等原因）

• 注冊中心判斷 Provider 心跳過期

• Consumer 訂閱到空列表，業務中斷報錯

開啟推空保護

• 同上

• Consumer 訂閱到空列表，推空保護生效，丟棄變更，保障業務服務可用

開啟方式

開啟方式比較簡單

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

配置項

• SpingCloudAlibaba 在 spring 配置項里增加：
  ???spring.cloud.nacos.discovery.namingPushEmptyProtection=true??

• Dubbo 加上 registryUrl 的參數：
  ???namingPushEmptyProtection=true??

提空保護依賴緩存，所以需要持久化緩存目錄，避免重啟后丟失，路徑為：??${user.home}/nacos/naming/${namespaceId}??

服務降級

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

服務降級的具體策略，包含返回 Null 值、返回 Exception 異常、返回自定義 JSON 數據和自定義回調。

MSE 微服務治理中心中默認就具備該項高可用能力。

Provider 端高可用

Provider 側通過注冊中心和服務治理提供的容災保護、離群摘除、無損下線等方案提升可用性。

容災保護

容災保護主要用于避免集群在異常流量下出現雪崩的場景。

下面我們來具體看一下：

無容災保護（默認閾值 =0）

• 突發請求量增加，容量水位較高時，個別 Provider 發生故障；

• 注冊中心將故障節點摘除，全量流量會給剩余節點；

• 剩余節點負載變高，大概率也會故障；

• 最后所有節點故障，100% 無法提供服務。

開啟容災保護（閾值=0.6）

• 同上；

• 故障節點數達到保護閾值，流量平攤給所有機器；

• 最終****保障 50% 節點能夠提供服務。

容災保護能力，在緊急情況下，能夠保存服務可用性在一定的水平之上，可以說是整體系統的兜底了。

這套方案曾經救過不少業務系統。

離群實例摘除

心跳續約是注冊中心感知實例可用性的基本途徑。

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

因為仍然存在心跳正常，但服務不可用的情況，例如：

• Request 處理的線程池滿

• 依賴的 RDS 連接異常或慢 SQL

微服務治理中心提供離群實例摘除

• 基于異常檢測的摘除策略：包含網絡異常和網絡異常 + 業務異常（HTTP 5xx）

• 設置異常閾值、QPS 下限、摘除比例下限

離群實例摘除的能力是一個補充，根據特定接口的調用異常特征，來衡量服務的可用性。

無損下線

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

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

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

配置管理高可用方案

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

配置管理解決什么問題？

多環境、多機器的配置發布、配置動態實時推送。

基于配置管理做服務高可用

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

發布環境管理

一次管理上百臺機器、多套環境，如何正確無誤地推送、誤操作或出現線上問題如何快速回滾，發布過程如何灰度。

業務開關動態推送

功能、活動頁面等開關。

容災降級預案的推送

預置的方案通過推送開啟，實時調整流控閾值等。

上圖是大促期間配置管理整體高可用解決方案。比如降級非核心業務、功能降級、日志降級、禁用高風險操作。

客戶端高可用

配置管理客戶端側同樣有容災方案。

本地目錄分為兩級，高優先級是容災目錄、低優先級是緩存目錄。

緩存目錄： 每次客戶端和配置中心進行數據交互后，會保存最新的配置內容至本地緩存目錄中，當服務端不可用狀態下，會使用本地緩存目錄中內容。

容災目錄： 當服務端不可用狀態下，可以在本地的容災目錄中手動更新配置內容，客戶端會優先加載容災目錄下的內容，模擬服務端變更推送的效果。

簡單來說，當配置中心不可用時，優先查看容災目錄的配置，否則使用之前拉取到的緩存。

容災目錄的設計，是因為有時候不一定會有緩存過的配置，或者業務需要緊急覆蓋使用新的內容開啟一些必要的預案和配置。

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

服務端高可用

在配置中心側，主要是針對讀、寫的限流。
限制連接數、限制寫：

• 限連接：單機最大連接限流，單客戶端 IP 的連接限流

• 限寫接口：發布操作&特定配置的秒級分鐘級數量限流

控制操作風險

控制人員做配置發布的風險。

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

配置灰度

發布歷史&回滾

變更對比

動手實踐

最后我們一起來做一個實踐。

場景取自前面提到的一個高可用方案，在服務提供者所有機器發生注冊異常的情況下，看服務消費者在推空保護打開的情況下的表現。

實驗架構和思路

上圖是本次實踐的架構，右側是一個簡單的調用場景，外部流量通過網關接入，這里選擇了 MSE 產品矩陣中的云原生網關，依靠它提供的可觀測能力，方便我們觀察服務調用情況。

網關的下游有 A、B、C 三個應用，支持使用配置管理的方式動態地將調用關系連接起來，后面我們會實踐到。

基本思路：

部署服務，調整調用關系是網關->A->B->C，查看網關調用成功率。

通過模擬網絡問題，將應用B與注冊中心的心跳鏈路斷開，模擬注冊異常的發生。

再次查看網關調用成功率，期望服務 A->B 的鏈路不受注冊異常的影響。

為了方便對照，應用 A 會部署兩種版本，一種是開啟推空保護的，一種是沒有開啟的情況。最終期望的結果是，推空保護開關開啟后，能夠幫助應用 A 在發生異常的情況下，繼續能夠尋址到應用B。

網關的流量打到應用 A 之后，可以觀察到，接口的成功率應該正好在 50%。

開始

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

環境準備

首先，購買好一套 MSE 注冊配置中心專業版，和一套 MSE 云原生網關。這邊不介紹具體的購買流程。

在應用部署前，提前準備好配置。這邊我們可以先配置 A 的下游是 C，B 的下游也是 C。

部署應用

接下來我們基于 ACK 部署三個應用。可以從下面的配置看到，應用 A 這個版本???spring-cloud-a-b??，推空保護開關已經打開。

這里 demo 選用的 nacos 客戶端版本是 1.4.2，因為推空保護在這個版本之后才支持。

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

# A 應用 base 版本 --- apiVersion: apps/v1 kind: Deployment metadata:labels:app: spring-cloud-aname: spring-cloud-a-b spec:replicas: 2selector:matchLabels:app: spring-cloud-atemplate:metadata:annotations:msePilotCreateAppName: spring-cloud-alabels:app: spring-cloud-aspec:containers:- env:- name: LANGvalue: C.UTF-8- name: spring.cloud.nacos.discovery.server-addrvalue: mse-xxx-nacos-ans.mse.aliyuncs.com:8848- name: spring.cloud.nacos.config.server-addrvalue: mse-xxx-nacos-ans.mse.aliyuncs.com:8848- name: spring.cloud.nacos.discovery.metadata.versionvalue: base- name: spring.application.namevalue: sc-A- name: spring.cloud.nacos.discovery.namingPushEmptyProtectionvalue: "true"image: mse-demo/demo:1.4.2imagePullPolicy: Alwaysname: spring-cloud-aports:- containerPort: 8080protocol: TCPresources:requests:cpu: 250mmemory: 512Mi --- apiVersion: apps/v1 kind: Deployment metadata:labels:app: spring-cloud-aname: spring-cloud-a spec:replicas: 2selector:matchLabels:app: spring-cloud-atemplate:metadata:annotations:msePilotCreateAppName: spring-cloud-alabels:app: spring-cloud-aspec:containers:- env:- name: LANGvalue: C.UTF-8- name: spring.cloud.nacos.discovery.server-addrvalue: mse-xxx-nacos-ans.mse.aliyuncs.com:8848- name: spring.cloud.nacos.config.server-addrvalue: mse-xxx-nacos-ans.mse.aliyuncs.com:8848- name: spring.cloud.nacos.discovery.metadata.versionvalue: base- name: spring.application.namevalue: sc-Aimage: mse-demo/demo:1.4.2imagePullPolicy: Alwaysname: spring-cloud-aports:- containerPort: 8080protocol: TCPresources:requests:cpu: 250mmemory: 512Mi # B 應用 base 版本 --- apiVersion: apps/v1 kind: Deployment metadata:labels:app: spring-cloud-bname: spring-cloud-b spec:replicas: 2selector:matchLabels:app: spring-cloud-bstrategy:template:metadata:annotations:msePilotCreateAppName: spring-cloud-blabels:app: spring-cloud-bspec:containers:- env:- name: LANGvalue: C.UTF-8- name: spring.cloud.nacos.discovery.server-addrvalue: mse-xxx-nacos-ans.mse.aliyuncs.com:8848- name: spring.cloud.nacos.config.server-addrvalue: mse-xxx-nacos-ans.mse.aliyuncs.com:8848- name: spring.application.namevalue: sc-Bimage: mse-demo/demo:1.4.2imagePullPolicy: Alwaysname: spring-cloud-bports:- containerPort: 8080protocol: TCPresources:requests:cpu: 250mmemory: 512Mi # C 應用 base 版本 --- apiVersion: apps/v1 kind: Deployment metadata:labels:app: spring-cloud-cname: spring-cloud-c spec:replicas: 2selector:matchLabels:app: spring-cloud-ctemplate:metadata:annotations:msePilotCreateAppName: spring-cloud-clabels:app: spring-cloud-cspec:containers:- env:- name: LANGvalue: C.UTF-8- name: spring.cloud.nacos.discovery.server-addrvalue: mse-xxx-nacos-ans.mse.aliyuncs.com:8848- name: spring.cloud.nacos.config.server-addrvalue: mse-xxx-nacos-ans.mse.aliyuncs.com:8848- name: spring.application.namevalue: sc-Cimage: mse-demo/demo:1.4.2imagePullPolicy: Alwaysname: spring-cloud-cports:- containerPort: 8080protocol: TCPresources:requests:cpu: 250mmemory: 512Mi

部署應用：

在網關注冊服務

應用部署好之后，在 MSE 云原生網關中，關聯上 MSE 的注冊中心，并將服務注冊進來。

我們設計的是網關只調用 A，所以只需要將 A 放進來注冊進來即可。

驗證和調整鏈路

基于 curl 命令驗證一下鏈路：

$ curl http://${網關IP}/ip sc-A[192.168.1.194] --> sc-C[192.168.1.195]

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

再看一下，這時三個應用的調用關系是 ABC，符合我們之前的計劃。

$ curl http://${網關IP}/ip sc-A[192.168.1.194] --> sc-B[192.168.1.191] --> sc-C[192.168.1.180]

接下來，我們通過一段命令，連續地調用接口，模擬真實場景下不間斷的業務流量。

$ while true; do sleep .1 ; curl -so /dev/null http://${網關IP}/ip ;done

觀測調用

通過網關監控大盤，可以觀察到成功率。

注入故障

一切正常，現在我們可以開始注入故障。

這里我們可以使用 K8s 的 NetworkPolicy 的機制，模擬出口網絡異常。

kind: NetworkPolicy apiVersion: networking.k8s.io/v1 metadata:name: block-registry-from-b spec:podSelector:matchLabels:app: spring-cloud-bingress:- {}egress:- to:- ipBlock:cidr: 0.0.0.0/0ports:- protocol: TCPport: 8080

這個 8080 端口的意思是，不影響內網調用下游的應用端口，只禁用其它出口流量（比如到達注冊中心的 8848 端口就被禁用了）。這里 B 的下游是 C。

網絡切斷后，注冊中心的心跳續約不上，過一會兒（30 秒后）就會將應用 B 的所有 IP 摘除。

再次觀測

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

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

小結

通過實踐，我們模擬了一次真實的風險發生的場景，并且通過客戶端的高可用方案（推空保護），成功實現了對風險的控制，防止服務調用的發生異常。

總結

以上是生活随笔為你收集整理的服务发现与配置管理高可用实践的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。