服務(wù)器又崩了？深度解析高可用架構(gòu)的挑戰(zhàn)和實踐

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

 軟件架構(gòu)的演進歷程

首先我們先來看下軟件架構(gòu)的演進歷程：

單體架構(gòu)：沒有復(fù)雜邏輯分層，前后代碼耦合，單個應(yīng)用可能與多個數(shù)據(jù)庫關(guān)聯(lián)

適用于：迭代頻率低，并發(fā)量小，業(yè)務(wù)邏輯簡單的應(yīng)用場景，目前單體架構(gòu)在政府、金融、工業(yè)領(lǐng)域仍有廣泛應(yīng)用。

SOA架構(gòu)：按業(yè)務(wù)邏輯進行服務(wù)拆分，服務(wù)間通過服務(wù)總線進行服務(wù)管理及流量轉(zhuǎn)發(fā)

其主要問題在于：服務(wù)總線成為系統(tǒng)新的瓶頸，難以伴隨業(yè)務(wù)的不斷發(fā)展?jié)M足線性擴容的要求。

微服務(wù)架構(gòu)：服務(wù)架構(gòu)通過服務(wù)注冊中心實現(xiàn)服務(wù)注冊發(fā)現(xiàn)，服務(wù)啟動時將服務(wù)實例注冊到注冊中心，調(diào)用方在發(fā)起調(diào)用時通過注冊中心進行服務(wù)尋址，直接與提供方進行通信。理論上服務(wù)可以伴隨業(yè)務(wù)發(fā)展實現(xiàn)線性擴展，不同服務(wù)之間可單獨迭代，實現(xiàn)敏捷開發(fā)。

服務(wù)網(wǎng)格：版本云原生k8s及容器技術(shù)發(fā)展，服務(wù)網(wǎng)格技術(shù)已趨于成熟，相較于傳統(tǒng)的微服務(wù)架構(gòu)，服務(wù)網(wǎng)格通過sidercar模式進行流量代理和服務(wù)注冊發(fā)現(xiàn)，無需業(yè)務(wù)感知，輕松實現(xiàn)跨語言服務(wù)治理，幫助業(yè)務(wù)快速遷移，使業(yè)務(wù)應(yīng)用更加專注自身業(yè)務(wù)邏輯實現(xiàn)。

每種軟件架構(gòu)沒有嚴格意義上的好壞之分，用戶需要根據(jù)自身的業(yè)務(wù)特點進行架構(gòu)選型。

微服務(wù)應(yīng)用常見問題

微服務(wù)架構(gòu)在滿足高并發(fā)、敏捷迭代的同時，業(yè)務(wù)模塊數(shù)量成幾何數(shù)增長，給應(yīng)用運維帶來了嚴峻挑戰(zhàn)，微服務(wù)架構(gòu)相較于傳統(tǒng)單體架構(gòu)，具有流量洪峰激增、模塊依賴復(fù)雜、故障定位難度大、故障恢復(fù)耗時長的特點。

• 流量激增：單體應(yīng)用拆分為微服務(wù)應(yīng)用后，原有的單一請求邏輯拆分為多個微服務(wù)應(yīng)用的組合業(yè)務(wù)邏輯，接口調(diào)用量成1:N的增長關(guān)系，面對流量洪峰，接口調(diào)用量激增。

  
  

• 模塊依賴復(fù)雜：原有的單體應(yīng)用僅存在單一進程內(nèi)的業(yè)務(wù)邏輯組合，微服務(wù)應(yīng)用拆分為多個進程，各模塊間的服務(wù)上下游依賴關(guān)系復(fù)雜，單個微服務(wù)或單個接口異常通常引發(fā)鏈式反應(yīng)，造成服務(wù)雪崩。

  
  

• 故障定位難度大：單次請求異常需要依據(jù)各模塊的依賴關(guān)系分析整個調(diào)用鏈路定位故障原因，由于橫跨多個微服務(wù)應(yīng)用進程的不同業(yè)務(wù)邏輯，故障定位難度陡增。

  
  

• 故障恢復(fù)耗時長：由于各微服務(wù)模塊依賴關(guān)系復(fù)雜，需要根據(jù)調(diào)用鏈準確定位故障問題根源并進行逐級恢復(fù)，故障恢復(fù)及恢復(fù)后驗證評價結(jié)果耗時長。

如何度量系統(tǒng)可用性指標

管理學(xué)大師彼得德魯克曾說“你如果無法度量它，就無法管理它”(“It you can’t measure it, you can’t manage it”)。要想有效管理，就難以繞開度量的問題。

那如何度量分布式系統(tǒng)的可用性指標呢，這里有一個簡單公式，可用性=平均故障間隔時間/平均故障間隔時間與平均故障恢復(fù)時間之和。

所謂平均故障間隔時間是指相鄰兩次故障之間的平均工作時間，也稱為平均故障間隔。平均修復(fù)時間是從出現(xiàn)故障到修復(fù)中間的這段時間。MTTR 越短表示易恢復(fù)性越好。

MTBF：即平均故障間隔時間，英文全稱是“Mean Time Between Failure”。是衡量一個產(chǎn)品（尤其是電器產(chǎn)品）的可靠性指標。單位為“小時”。

MTTR：全稱是 Mean Time To Repair，即平均修復(fù)時間。是指可修復(fù)產(chǎn)品的平均修復(fù)時間，就是從出現(xiàn)故障到修復(fù)中間的這段時間。MTTR 越短表示易恢復(fù)性越好。

高可用架構(gòu)設(shè)計的道、法、術(shù)

那如何設(shè)計高可用的微服務(wù)架構(gòu)呢？接下來我將分別從道、法、術(shù)三個層面講高可用微服務(wù)架構(gòu)設(shè)計的基本原理、架構(gòu)設(shè)計原則、以及高可用架構(gòu)常用的解決方法。

道：從CAP到BASE

CAP 理論：在一個分布式系統(tǒng)中， 一致性（C：Consistency）、可用性（A：Availability） 和 分區(qū)容忍性（P：Partition Tolerance），最多只能同時滿足其中兩項。其中分區(qū)容忍性（P：Partition Tolerance）是復(fù)雜網(wǎng)絡(luò)環(huán)境下的必須要素，因此分布式系統(tǒng)的架構(gòu)設(shè)計需要在一致性和可用性之間進行取舍。就誕生了諸如：Paxos 算法 和 Raft 算法強一致性共識算法，以及2階段提交，3階段提交的最終一致性算法。

BASE 理論：BASE是對 CAP 中一致性和可用性權(quán)衡的結(jié)果，它的理論的核心思想是：即使無法做到強一致性，但每個應(yīng)用都可以根據(jù)自身業(yè)務(wù)特點，采用適當?shù)姆绞絹硎瓜到y(tǒng)達到最終一致性。

法：微服務(wù)高可用架構(gòu)設(shè)計原則

結(jié)合我對微服務(wù)高可用架構(gòu)的理解，總結(jié)出以下6點高可用架構(gòu)設(shè)計的原則，分別是服務(wù)無狀態(tài)、異步解耦、分區(qū)容錯、故障隔離、快速恢復(fù)、最終一致性：

服務(wù)無狀態(tài)：服務(wù)應(yīng)用進行無狀態(tài)設(shè)計，將服務(wù)應(yīng)用的狀態(tài)數(shù)據(jù)通過緩存、數(shù)據(jù)庫進行集中存儲，通過nginx或網(wǎng)關(guān)進行負載均衡實現(xiàn)水平擴展。

異步解耦：各服務(wù)模塊通過發(fā)布訂閱、事件驅(qū)動方式進行異步解耦，單次請求調(diào)用通過異步回調(diào)方式快速響應(yīng)，將通知事件與處理結(jié)果分離，避免異常雪崩。

分區(qū)容錯：基于指定的業(yè)務(wù)規(guī)則實現(xiàn)業(yè)務(wù)分流路由，將流量分發(fā)至多個可用區(qū)，不同可用區(qū)通過數(shù)據(jù)同步、多備份機制保障數(shù)據(jù)一致性。

故障隔離：單一進程、單一接口、單一服務(wù)通過熔斷、降級機制實現(xiàn)故障隔離，避免系統(tǒng)關(guān)聯(lián)異常，引發(fā)雪崩效應(yīng)。

快速恢復(fù)：通過流量切分，版本管理、應(yīng)用回滾機制實現(xiàn)應(yīng)用快速回退至健康版本，快速恢復(fù)應(yīng)用。

最終一致性：通過多數(shù)據(jù)源雙寫、數(shù)據(jù)稽核、數(shù)據(jù)修復(fù)實現(xiàn)數(shù)據(jù)跨可用區(qū)數(shù)據(jù)最終一致性。

術(shù)：高可用常用手段

分區(qū)容錯：

異地容災(zāi)是高可用架構(gòu)典型的應(yīng)用場景，通過將不同地域的數(shù)據(jù)中心構(gòu)建多套應(yīng)用服務(wù)，當單一地域服務(wù)宕機時可快速通過流量切換災(zāi)備中心保障業(yè)務(wù)持續(xù)、穩(wěn)定。異地容災(zāi)按保障級別不同分為，多可用區(qū)、同城冷備、同城雙活、異地冷備、兩地三中心五個級別，其保障級別、應(yīng)用成本、恢復(fù)延遲都呈遞增趨勢。

異步解耦：

在微服務(wù)應(yīng)用中通過引入消息中間件將上游組合服務(wù)對下游多個微服務(wù)的同步調(diào)用進行異步解耦，基于消息的可靠投遞能力快速響應(yīng)用戶請求，能夠大幅提升服務(wù)并發(fā)訪問性能及用戶體驗，并通過數(shù)據(jù)補償手段保障數(shù)據(jù)最終一致性。

服務(wù)限流：

由于 API 接口無法控制調(diào)用方的行為，因此當遇到瞬時請求量激增時，會導(dǎo)致接口占用過多服務(wù)器資源，使得其他請求響應(yīng)速度降低或是超時，嚴重導(dǎo)致服務(wù)器宕機。服務(wù)限流主要是保護服務(wù)節(jié)點或者數(shù)據(jù)節(jié)點，防止瞬時流量過大造成服務(wù)和數(shù)據(jù)崩潰，導(dǎo)致服務(wù)不可用。

• 局部限流：基于簡單計數(shù)、令牌桶、漏斗算法在單個節(jié)點內(nèi)的限流，僅能限制傳入此節(jié)點的請求，無需引入中間件，通過局部限流達到全局限流的目的，同時避免實例級別單一接口訪問量激增問題

• 全局限流：基于簡單計數(shù)、令牌桶算法，通過引入中間件如redis，針對整個集群流量進行全局控制。

從下圖中可以看出，當網(wǎng)關(guān)入口服務(wù)請求下游多個服務(wù)接口，當服務(wù)C接口異常將導(dǎo)致入口服務(wù)流量的不可用，服務(wù)A、服務(wù)E請求則白白占用。

從下圖中可以看出，當網(wǎng)關(guān)入口的服務(wù)請求下游的單一服務(wù)接口，當服務(wù)B接口異常將導(dǎo)致入口請求夯住，占用網(wǎng)關(guān)請求資源，導(dǎo)致整體業(yè)務(wù)異常。

針對以上兩種異常場景，通過在服務(wù)調(diào)用時配置熔斷策略能夠快速失敗，直接反饋上游業(yè)務(wù)異常結(jié)果，避免請求線程夯死及服務(wù)雪崩。

TSF高可用最佳實踐

TSF微服務(wù)平臺針對業(yè)務(wù)流量激增、服務(wù)異常容錯等問題提供架構(gòu)容災(zāi)、灰度發(fā)布、服務(wù)容錯兜底、實例優(yōu)雅啟停、應(yīng)用性能管理的一體化高可用服務(wù)架構(gòu)。突出立體化、自動化、可視化的優(yōu)勢，提供端到端的應(yīng)用性能監(jiān)控，多維度可視化的運行監(jiān)控數(shù)據(jù)聚合分析，實現(xiàn)故障自動感知，自動處理，快速恢復(fù)故障業(yè)務(wù)，保障系統(tǒng)的穩(wěn)定高效運行。

單元化架構(gòu)部署

單元化架構(gòu)是一種高級的高可用架構(gòu)設(shè)計模式，通過對核心業(yè)務(wù)數(shù)據(jù)分片，應(yīng)用服務(wù)無狀態(tài)設(shè)計將相同領(lǐng)域的業(yè)務(wù)服務(wù)劃分為一個個獨立的部署單元，單元內(nèi)整體業(yè)務(wù)閉環(huán)。通過單元化部署架構(gòu)能夠有效滿足彈性伸縮，故障隔離，異地容災(zāi)等高可用建設(shè)要求。此外基于單元化部署可以實現(xiàn)以部署單元為基準，構(gòu)建靈活的發(fā)布策略。

單元化架構(gòu)產(chǎn)品能力：

• 網(wǎng)關(guān)業(yè)務(wù)單元路由標簽 

• 支持跨單元橫向調(diào)用 

• 單元內(nèi)服務(wù)容錯兜底

通過配置動態(tài)伸縮規(guī)則，TSF中控服務(wù)基于agent上報的監(jiān)控數(shù)據(jù)實現(xiàn)實時統(tǒng)計，滿足流量激增自動擴容或流量低峰自動縮容能力，有效保障服務(wù)高效穩(wěn)定及資源利用率提升。

全鏈路灰度發(fā)布

灰度發(fā)布是將具有一定特征或者比例的流量分配到需要被驗證的版本中，用來觀察新的驗證版本的線上運行狀態(tài)。相比全量上線，灰度發(fā)布是更加謹慎的發(fā)布形式。當線上調(diào)用鏈路較為復(fù)雜時，全鏈路灰度發(fā)布可以將線上的各個服務(wù)隔離出一個單獨的運行環(huán)境。

優(yōu)雅啟停

在應(yīng)用滾動發(fā)布過程中，可以通過調(diào)整部署組滾動發(fā)布更新策略達到服務(wù)優(yōu)雅下線，降低發(fā)布過程中業(yè)務(wù)中斷影響。

這里簡單介紹優(yōu)雅下線的簡單流程

1. 下線實例在注冊中心進行反注冊，注銷該實例注冊信息；

2. 注冊中心節(jié)點訂閱更新周期為15s，調(diào)用方在感知注冊中心實例變更后，更新本地緩存服務(wù)地址，不再將流量路由到下線實例，期間保障業(yè)務(wù)無中斷；

3. 下線實例等待30s（2個心跳周期）后進行實際下線操作；

優(yōu)雅啟停產(chǎn)品能力：

• 支持容器、虛機部署方式

• 實例反注冊下線事件詳情 

• 實例啟動就緒檢測

服務(wù)限流

TSF 限流基于監(jiān)控服務(wù)流量的 QPS 指標，當達到指定的閾值時進行流量控制，避免被瞬時高峰流量沖垮，從而確保服務(wù)的高可用。支持在網(wǎng)關(guān)配置全局限流策略保障入口服務(wù)流量穩(wěn)定支持針對單一服務(wù)配置局部限流策略保障當前服務(wù)流量穩(wěn)定，同時提供靈活的限流規(guī)則配置及動態(tài)生效，提供可視化的限流操作及監(jiān)控數(shù)據(jù)展示。

服務(wù)熔斷

TSF服務(wù)熔斷能力支持服務(wù)、實例、API多維度的熔斷隔離級別，提供控制臺可視化配置及熔斷事件展示，滿足熔斷配置熱生效需求。

熔斷器狀態(tài)轉(zhuǎn)換：

• 熔斷器開始處于closed狀態(tài)，一旦檢測到錯誤（或慢響應(yīng)）達到一定閾值，便轉(zhuǎn)為open狀態(tài)，此時不再調(diào)用下游目標服務(wù)。

•  一段時間后轉(zhuǎn)化為half open狀態(tài)，嘗試放行一部分請求到下游服務(wù)。 

• 一旦檢測到響應(yīng)成功，回歸到closed狀態(tài)，也即恢復(fù)服務(wù)；否則回到open狀態(tài)。

健康檢查與注冊中心聯(lián)動流程

健康檢查分為存活檢查及就緒檢查；存活檢查主要作用是確定進程存活狀態(tài)，判斷是否需要進行實例重啟。就緒檢查主要作用是確定服務(wù)實例能否支持對外服務(wù)，將健康檢查結(jié)果與注冊中心狀態(tài)聯(lián)動避免流量接入異常節(jié)點。

健康檢查產(chǎn)品能力：

• 存活檢查

• 就緒檢查

• 多種探測方式：http，tcp，執(zhí)行命令

• 支持虛機&容器部署

應(yīng)用性能管理能力

最后我們從一個問題排查流程全局展示tsf應(yīng)用性能管理能力：

1. 用戶收到監(jiān)控平臺發(fā)送的告警信息，確定異常基本信息。

2. 通過服務(wù)依賴拓撲確定異常服務(wù)的上下游依賴關(guān)系，進行全局視圖分析。

3. 接下來可以服務(wù)接口調(diào)用情況確定是全局接口異常或是單一接口異常。

4. 如果是全局接口異常說明服務(wù)提供方服務(wù)實例存在異常問題，找到對應(yīng)的異常實例通過日志檢索或JVM監(jiān)控分析排查具體問題；如果是單一接口異常說明提供方接口邏輯處理，通過日志檢索可排查具體問題。

5. 當然也可以在全局視圖分析后通過對直接服務(wù)進行調(diào)用鏈分析排查單筆請求的調(diào)用鏈路，通過調(diào)用鏈與日志聯(lián)動排查具體異常。

以上是本次TSF高可用結(jié)構(gòu)設(shè)計及核心技術(shù)原理的全部分享。歡迎關(guān)注騰訊云中間件獲取最新產(chǎn)品信息，了解行業(yè)動態(tài)。