摘要：本次分享將以 Service Mesh 與 Spring Cloud 應用互聯互通共同治理爲前提，着重介紹基於 Consul 的註冊中心高可用方案，通過各種限流、熔斷策略保證後端服務的高可用，以及通過智能路由策略（負載均衡、實例容錯等）實現服務間調用的高可用。Spring Cloud 應用通過 SDK、Service Mesh 應用實現 Sidecar 分別向註冊中心註冊，註冊的請求先通過微服務控制中心進行認證處理與多租戶隔離。

Service Mesh Virtual Meetup 是 ServiceMesher 社區和 CNCF 聯合主辦的線上系列直播。本期爲 Service Mesh Virtual Meetup#1 ，邀請了四位來自不同公司的嘉賓，從不同角度展開了 Service Mesh 的應用實踐分享，分享涵蓋來自陌陌和百度的 Service Mesh 生產實踐，Service Mesh 的可觀察性和生產實踐以及與傳統微服務中可觀察性的區別，還有如何使用 SkyWalking 來觀測 Service Mesh。

本文根據5月13日晚，百度高級工程師羅廣明的主題分享《Service Mesh 高可用在企業級生產中的實踐》整理。文末包含本次分享的視頻回顧鏈接以及 PPT 下載地址。

前言

Service Mesh 在企業落地中有諸多挑戰，當與傳統微服務應用共同部署治理時可用性挑戰更爲嚴峻。本次分享將以 Service Mesh 與 Spring Cloud 應用互聯互通共同治理爲前提，着重介紹基於 Consul 的註冊中心高可用方案，通過各種限流、熔斷策略保證後端服務的高可用，以及通過智能路由策略（負載均衡、實例容錯等）實現服務間調用的高可用。

Service Mesh 與 Spring Cloud 應用的互通、互聯

微服務是時下技術熱點，大量互聯網公司都在做微服務架構的推廣和落地。同時，也有很多傳統企業基於微服務和容器，在做互聯網技術轉型。而在這個技術轉型中，國內有一個現象，以 Spring Cloud 與 Dubbo 爲代表的微服務開發框架非常普及和受歡迎。近年來， 新興的 Service Mesh 技術也越來越火熱，受到越來越多開發者的關注，大有後來居上的趨勢。

在聽到社區裏很多人談到微服務技術選型時，注意到他們討論一個非此即彼的問題：採用 Spring Cloud 還是以 Istio 爲代表的 Service Mesh 技術？然而這個答案並非非黑即白、非你即我，一部分應用採用 Spring Cloud，另一部分採用 Service Mesh（Istio）是完全可能的。今天我就和大家一起來討論這個問題。

首先，我們來看一下 Spring Cloud 這個傳統侵入式微服務框架。它包含以下優點：

  • 集大成者，Spring Cloud 包含了微服務架構的方方面面；選用目前各家公司開發的比較成熟的、經得住實踐考驗的服務框架；
  • 輕量級組件，Spring Cloud 整合的組件大多比較輕量級，且都是各自領域的佼佼者；
  • 開發簡便，Spring Cloud 對各個組件進行了大量的封裝，從而簡化了開發；
  • 開發靈活，Spring Cloud 的組件都是解耦的，開發人員可以靈活按需選擇組件。

特別感謝 Netflix ，這家很早就成功實踐微服務的公司，幾年前把自家幾乎整個微服務框架棧貢獻給了社區，早期的 Spring Cloud 主要是對 Netflix 開源組件的進一步封裝。不過近兩年，Spring Cloud 社區開始自研了很多新的組件，也接入了其他一些互聯網公司的優秀實踐。

接下來，我們簡單看一下 Service Mesh 框架。它帶來了兩大變革：微服務治理與業務邏輯的解耦，異構系統的統一治理。此外，服務網格相對於傳統微服務框架，還擁有三大技術優勢：可觀察性、流量控制、安全。服務網格帶來了巨大變革並且擁有其強大的技術優勢，被稱爲第二代“微服務架構”。

然而就像之前說的軟件開發沒有銀彈，傳統微服務架構有許多痛點，而服務網格也不例外，也有它的侷限性。這些侷限性包括：增加了鏈路與運維的複雜度、需要更專業的運維技能、帶來了一定的延遲以及對平臺的適配。

更多關於 Spring Cloud 與 Service Mesh 的優缺點與比較，請閱讀 Istio-Handbook [Service Mesh 概述]。

前面提到過，對於傳統微服務框架 Spring Cloud 與新興微服務框架 Service Mesh，並非是個非黑即白，非你即我，延伸到微服務與單體架構，它們也是可以共存的。

也可以將其與混合雲相類比，混合雲中包含了公有云、私有云，可能還有其它的自有基礎設施。目前來看，混合雲是一種流行的實踐方式；實際上，可能很難找到一個完全單一雲模式的組織。對多數組織來說，將一個單體應用完全重構爲微服務的過程中，對開發資源的調動是一個很嚴峻的問題；採用混合微服務策略是一個較好的方式，對開發團隊來說，這種方式讓微服務架構觸手可及；否則的話，開發團隊可能會因爲時間、經驗等方面的欠缺，無法接受對單體應用的重構工作。

構建混合微服務架構的最佳實踐：

  • 最大化收益的部分優先重構；
  • 非 Java 應用優先採用 Service Mesh 框架。

混合微服務出現的原因是爲了更好的支持平滑遷移，最大限度的提升服務治理水平，降低運維通信成本等，並且可能會在一個較長的週期存在着。而實現這一架構的前提，就是各服務的“互聯互通”。

要想實現上述“混合微服務架構”，運行時支撐服務必不可少，它主要包括服務註冊中心、服務網關和集中式配置中心三個產品。

傳統微服務和 Service Mesh 雙劍合璧（雙模微服務），即“基於 SDK 的傳統微服務”可以和“基於 Sidecar 的 Service Mesh 微服務”實現下列目標：

  • 互聯互通：兩個體系中的應用可以相互訪問；
  • 平滑遷移：應用可以在兩個體系中遷移，對於調用該應用的其他應用，做到透明無感知；
  • 靈活演進：在互聯互通和平滑遷移實現之後，我們就可以根據實際情況進行靈活的應用改造和架構演進。

這裏還包括對應用運行平臺的要求，即兩個體系下的應用，既可以運行在虛擬機之上，也可以運行在容器 /K8s 之上。我們不希望把用戶綁定在 K8s 上，因此 Service Mesh 沒有采用 K8s 的 Service 機制來做服務註冊與發現，這裏就突出了註冊中心的重要性。

百度智能雲 CNAP 團隊實現了上述混合微服務架構，即實現了兩個微服務體系的應用互聯互通、平滑遷移、靈活演進。上述混合微服務架構圖包括以下幾個組件：

  • API Server：前後端解耦，接口權限控制、請求轉發、異常本地化處理等等；
  • 微服務控制中心：微服務治理的主要邏輯，包括服務註冊的多租戶處理、治理規則（路由、限流、熔斷）的創建和轉換、微服務配置的管理；
  • 監控數據存儲、消息隊列：主要是基於 Trace 的監控方案使用的組件；
  • 配置中心：微服務配置中心，最主要的功能是支持配置管理，包括治理規則、用戶配置等所有微服務配置的存儲和下發，微服務配置中心的特色是藉助 SDK 可以實現配置/規則熱更新。

接下來主要看一下注冊中心的服務註冊和發現機制：

  • Spring Cloud 應用通過 SDK、Service Mesh 應用實現 Sidecar 分別向註冊中心註冊，註冊的請求先通過微服務控制中心進行認證處理與多租戶隔離；
  • Mesh 控制面直接對接註冊中心獲取服務實例、Spring Cloud 應用通過 SDK 獲取服務實例；
  • 雙模異構，支持容器與虛機兩種模型。

註冊中心與高可用方案

前面提到過，要想實現實現混合微服務架構，註冊中心很關鍵。談到註冊中心，目前主流的開源註冊中心包括：

  • Zookeeper：Yahoo 公司開發的分佈式協調系統，可用於註冊中心，目前仍有很多公司使用其作爲註冊中心；
  • Eureka：Netflix 開源組件，可用於服務註冊發現組件，被廣大 Spring Cloud 開發者熟知，遺憾的是目前已經不再維護，也不再被 Spring Cloud 生態推薦使用；
  • Consul： HashiCorp 公司推出的產品，其可作爲實現註冊中心，也是本文介紹的重點；
  • Etcd：Etcd 官方將其定義爲可靠的分佈式 KV 存儲。

我們註冊中心選擇了 Consul，Consul 包含了以下幾個重要的功能：

  • 服務發現：可以註冊服務，也可以通過 Http 或 DNS 的方式發現已經註冊的服務；
  • 豐富的健康檢查機制；
  • 服務網格能力，最新版本已經支持 Envoy 作爲數據面；
  • KV 存儲：可以基於 Consul KV 存儲實現一個分佈式配置中心；
  • 多數據中心：藉助多數據中心，無需使用額外的抽象層，即可構建多地域的場景，支持多 DC 數據同步、異地容災。

上圖是 Consul 官網提供的架構圖。Consul 架構中幾個核心的概念如下：

  • Agent: Agent 是運行在 Consul 集羣的每個節點上的 Daemon 進程，通過 Consul Agent 命令將其啓動，Agent 可以運行在 Client 或者 Server 模式下；
  • Client：Client 是一種 Agent，其將會重定向所有的 RPC 請求到 Server，Client 是無狀態的，其主要參與 LAN Gossip 協議池，其佔用很少的資源，並且消耗很少的網絡帶寬；
  • Server：Server 是一種 Agent，其包含了一系列的責任包括：參與 Raft 協議寫半數（Raft Quorum）、維護集羣狀態、響應 RPC 響應、和其他 Datacenter 通過 WAN gossip 交換信息和重定向查詢請求至 Leader 或者遠端 Datacenter；
  • Datacenter: Datacenter 其是私有的、低延遲、高帶寬的網絡環境，去除了在公共網絡上的網絡交互。

註冊中心作爲基礎組件，其自身的可用性顯得尤爲重要，高可用的設計需要對其進行分佈式部署，同時因在分佈式環境下的複雜性，節點因各種原因都有可能發生故障，因此在分佈式集羣部署中，希望在部分節點故障時，集羣依然能夠正常對外服務。註冊中心作爲微服務基礎設施，因此對其容災和其健壯性有一定的要求，主要體現在：

  • 註冊中心作爲微服務基礎設施，因此要求出現某些故障（如節點掛掉、網絡分區）後註冊中心仍然能夠正常運行；
  • 當註冊中心的發生故障時，不能影響服務間的正常調用。

Consul 使用 Raft 協議作爲其分佈式一致性協議，本身對故障節點有一定的容忍性，在單個 DataCenter中 Consul 集羣中節點的數量控制在 2*n + 1 個節點，其中 n 爲可容忍的宕機個數。Quorum size: Raft 協議選舉需要半數以上節點寫入成功。

Q1: 節點的個數是否可以爲偶數個？

A2：答案是可以的，但是不建議部署偶數個節點。一方面如上表中偶數節點4和奇數節點3可容忍的故障數是一樣的，另一方面，偶數個節點在選主節點的時候可能會出現瓜分選票的情形（雖然 Consul 通過重置 election timeout 來重新選舉），所以還是建議選取奇數個節點。

Q2: 是不是 Server 節點個數越多越好？

A2：答案是否定的，雖然上表中顯示 Server 數量越多可容忍的故障數越多，熟悉 Raft 協議的讀者肯定熟悉 Log Replication（ 如上文介紹，日誌複製時過半寫成功才返回寫成功），隨着 Server 的數量越來越多，性能就會越低，所以結合實際場景一般建議 Server 部署3個節點。

推薦採用三節點或五節點，最爲有效，且能容錯。

註冊中心設計的一個重要前提是：註冊中心不能因爲自身的原因或故障影響服務之間的相互調用。因此在實踐過程中，如果註冊中心本身發生了宕機故障/不可用，絕對不能影響服務之間的調用。這要求對接註冊中心的 SDK 針對這種特殊情況進行客戶端容災設計，『客戶端緩存』就是一種行之有效的手段。當註冊中心發生故障無法提供服務時，服務本身並不會更新本地客戶端緩存，利用其已經緩存的服務列表信息，正常完成服務間調用。

我們在設計時採用同 Datacenter 集羣內部部署3個 Server 節點，來保障高可用性，當集羣中1個節點發生故障後，集羣仍然能夠正常運行，同時這3個節點部署在不同的機房，達到機房容災的能力。

在雲上環境，涉及多 region 環境，因此在架構設計設計時，我們首先將 Consul 的一個 Datacenter 對應雲上一個 region，這樣更符合 Consul 對於 Datecenter 的定義（DataCenter 數據中心是私有性、低延遲、高帶寬的網絡環境）。中間代理層實現了服務鑑權、多租戶隔離等功能；還可以通過中間代理層，對接多註冊中心。

雲上環境存在多租戶隔離的需求，即：A租戶的服務只能發現A租戶服務的實例。針對此場景，需要在 『中間代理層』完成對多租戶隔離功能的實現，其主要實踐思路爲使用 Consul Api Feature 具備 Filtering 功能：

  • 利用 Filtering 功能實現租戶隔離需求；
  • 減少查詢註冊中心接口時網絡負載。

通過治理策略保證服務高可用

什麼是高可用？維基百科這麼定義：系統無中斷地執行其功能的能力，代表系統的可用性程度，是進行系統設計時的準則之一。我們通常用 N 個9來定義系統的可用性，如果能達到4個9，則說明系統具備自動恢復能力；如果能達到5個9，則說明系統極其健壯，具有極高可用性，而能達到這個指標則是非常難的。

常見的系統不可用因素包括：程序和配置出 bug、機器故障、機房故障、容量不足、依賴服務出現響應超時等。高可用的抓手包括：研發質量、測試質量、變更管理、監控告警、故障預案、容量規劃、放火盲測、值班巡檢等。這裏，將主要介紹通過藉助治理策略採用高可用設計手段來保障高可用。

高可用是一個比較複雜的命題，所以設計高可用方案也涉及到了方方面面。這中間將會出現的細節是多種多樣的，所以我們需要對這樣一個微服務高可用方案進行一個頂層的設計。

比如服務冗餘：

  • 冗餘策略：每個機器每個服務都可能出現問題，所以第一個考慮到的就是每個服務必須不止一份，而是多份。所謂多份一致的服務就是服務的冗餘，這裏說的服務泛指了機器的服務、容器的服務、還有微服務本身的服務。在機器服務層面需要考慮，各個機器間的冗餘是否有在物理空間進行隔離冗餘。
  • 無狀態化：我們可以隨時對服務進行擴容或者縮容，想要對服務進行隨時隨地的擴縮容，就要求我們的服務是一個無狀態化，所謂無狀態化就是每個服務的服務內容和數據都是一致的。

比如柔性化/異步化：

  • 所謂的柔性化，就是在我們業務允許的情況下，做不到給予用戶百分百可用的，通過降級的手段給到用戶儘可能多的服務，而不是非得每次都交出去要麼 100 分或 0 分的答卷。柔性化更多是一種思維，需要對業務場景有深入的瞭解。
  • 異步化：在每一次調用，時間越長存在超時的風險就越大，邏輯越複雜執行的步驟越多，存在失敗的風險也就越大。如果在業務允許的情況下，用戶調用只給用戶必須要的結果，不是需要同步的結果可以放在另外的地方異步去操作，這就減少了超時的風險也把複雜業務進行拆分減低複雜度。

上面講到的幾種提高服務高可用的手段，大多需要從業務以及部署運維的角度實現。而接下來會重點介紹，可以通過 SDK/Sidecar 手段提供服務高可用的治理策略，這些策略往往對業務是非侵入或者弱侵入的，能夠讓絕大多數服務輕鬆實現服務高可用。

微服務之間一旦建立起路由，就意味着會有數據在服務之間流通。由於不同服務可以提供的資源和對數據流量的承載能力不盡相同，爲了防止單個 Consumer 佔用 Provider 過多的資源，或者突發的大流量衝擊導致 Provider 故障，需要服務限流來保證服務的高可用。

在服務治理中，雖然我們可以通過限流規則儘量避免服務承受過高的流量，但是在實際生產中服務故障依然難以完全避免。當整個系統中某些服務產生故障時，如果不及時採取措施，這種故障就有可能因爲服務之間的互相訪問而被傳播開來，最終導致故障規模的擴大，甚至導致整個系統奔潰，這種現象我們稱之爲“雪崩”。熔斷降級其實不只是服務治理中，在金融行業也有很廣泛的應用。比如當股指的波動幅度超過規定的熔斷點時，交易所爲了控制風險採取的暫停交易措施。

負載均衡是高可用架構的一個關鍵組件，主要用來提高性能和可用性，通過負載均衡將流量分發到多個服務器，同時多服務器能夠消除這部分的單點故障。

以上治理規則在某種程度上可以在 Spring Cloud 與 Service Mesh 兩個框架上進行對齊，即同一套治理配置，可以通過轉換分發到 Spring Cloud 應用的 SDK 上以及 Service Mesh 的 Sidecar 上。可以由 Config-server 負責規則下發，也可以由 Service Mesh 的控制面負責下發，取決於具體的架構方案。

服務限流

對於一個應用系統來說一定會有極限併發/請求數，即總有一個 TPS/QPS 閥值，如果超了閥值則系統就會不響應用戶請求或響應的非常慢，因此我們最好進行過載保護，防止大量請求湧入擊垮系統。限流的目的是通過對併發訪問/請求進行限速或者一個時間窗口內的請求進行限速來保護系統，一旦達到限制速率則可以拒絕服務或進行流量整形。

常用的微服務限流架構包括：

  • 接入層（api-gateway）限流：
    • 單實例；
    • 多實例：分佈式限流算法；
  • 調用外部限流服務限流：
    • 微服務收到請求後，通過限流服務暴露的 RPC 接口查詢是否超過閾值；
    • 需單獨部署限流服務；
  • 切面層限流（SDK）：
    • 限流功能集成在微服務系統切面層，與業務解耦；
    • 可結合遠程配置中心使用；

常用的限流策略包括：

  • 拒絕策略：
    • 超過閾值直接返回錯誤；
    • 調用方可做熔斷降級處理。
  • 延遲處理：
    • 前端設置一個流量緩衝池，將所有的請求全部緩衝進這個池子，不立即處理。然後後端真正的業務處理程序從這個池子中取出請求依次處理，常見的可以用隊列模式來實現（MQ：削峯填谷）；
    • 用異步的方式去減少了後端的處理壓力。
  • 特權處理：
    • 這個模式需要將用戶進行分類，通過預設的分類，讓系統優先處理需要高保障的用戶羣體，其它用戶羣的請求就會延遲處理或者直接不處理。

常用的限流算法包括：

  • 固定時間窗口限流：
    • 首先需要選定一個時間起點，之後每次接口請求到來都累加計數器，如果在當前時間窗口內，根據限流規則（比如每秒鐘最大允許 100 次接口請求），累加訪問次數超過限流值，則限流熔斷拒絕接口請求。當進入下一個時間窗口之後，計數器清零重新計數；
    • 缺點在於：限流策略過於粗略，無法應對兩個時間窗口臨界時間內的突發流量。

  • 滑動時間窗口算法：

    • 流量經過滑動時間窗口算法整形之後，可以保證任意時間窗口內，都不會超過最大允許的限流值，從流量曲線上來看會更加平滑，可以部分解決上面提到的臨界突發流量問題，是對固定時間窗口算法的一種改進；
    • 缺點在於：需要記錄在時間窗口內每個接口請求到達的時間點，對內存的佔用會比較多。

  • 令牌桶算法：

    • 接口限制 t 秒內最大訪問次數爲 n，則每隔 t/n 秒會放一個 token 到桶中；
    • 桶中最多可以存放 b 個 token，如果 token 到達時令牌桶已經滿了，那麼這個 token 會被丟棄；
    • 接口請求會先從令牌桶中取 token，拿到 token 則處理接口請求，拿不到 token 就阻塞或者拒絕服務。

  • 漏桶算法：

    • 對於取令牌的頻率也有限制，要按照 t/n 固定的速度來取令牌；
    • 實現往往依賴於隊列，請求到達如果隊列未滿則直接放入隊列，然後有一個處理器按照固定頻率從隊列頭取出請求進行處理。如果請求量大，則會導致隊列滿，那麼新來的請求就會被拋棄；
    • 令牌桶和漏桶算法的算法思想大體類似，漏桶算法作爲令牌桶限流算法的改進版本。

令牌桶算法和漏桶算法，在某些場景下（內存消耗、應對突發流量），這兩種算法會優於時間窗口算法成爲首選。

熔斷

斷路器模式是微服務架構中廣泛採用的模式之一，旨在將故障的影響降到最低，防止級聯故障和雪崩，並確保端到端性能。我們將比較使用兩種不同方法實現它的優缺點: Hystrix 和 Istio。

在電路領域中，斷路器是爲保護電路而設計的一種自動操作的電氣開關。它的基本功能是在檢測到故障後中斷電流，然後可以重置(手動或自動)，以在故障解決後恢復正常操作。這看起來與我們的問題非常相似：爲了保護應用程序不受過多請求的影響，最好在後端檢測到重複出現的錯誤時立即中斷前端和後端之間的通信。Michael Nygard 在他的《Release It》一書中使用了這個類比，併爲應用於上述超時問題的設計模式提供了一個典型案例，可以用上圖來總結。

Istio 通過 DestinationRule 實現斷路器模式，或者更具體的路徑 TrafficPolicy (原斷路器) -> OutlierDetection，根據上圖模型：

  • consecutiveErrors 斷路器打開前的出錯次數；
  • interval 斷路器檢查分析的時間間隔；
  • baseEjectionTime 最小的開放時間，該電路將保持一段時間等於最小彈射持續時間和電路已打開的次數的乘積；
  • maxEjectionPercent 可以彈出的上游服務的負載平衡池中主機的最大百分比，如果驅逐的主機數量超過閾值，則主機不會被驅逐。

與上述公稱斷路器相比，有兩個主要偏差:

  • 沒有半開放的狀態。然而，斷路器持續打開的時間取決於被調用服務之前失敗的次數，持續的故障服務將導致斷路器的開路時間越來越長。
  • 在基本模式中，只有一個被調用的應用程序(後端)。在更實際的生產環境中，負載均衡器後面可能部署同一個應用程序的多個實例。某些情況下有些實例可能會失敗，而有些實例可能會工作。因爲 Istio 也有負載均衡器的功能，能夠追蹤失敗的實例，並把它們從負載均衡池中移除，在一定程度上: ‘maxEjectionPercent’ 屬性的作用是保持一小部分的實例池。

Hystrix 提供了一個斷路器實現，允許在電路打開時執行 fallback 機制。最關鍵的地方就在 HystrixCommand 的方法 run() 和 getFallback()：

  • run() 是要實際執行的代碼 e.g. 從報價服務中獲取價格；
  • getFallback() 獲取當斷路器打開時的 fallback 結果 e.g. 返回緩存的價格。

Spring Cloud 是建立在 Spring Boot 之上的框架，它提供了與 Spring 的良好集成。它讓開發者在處理 Hystrix 命令對象的實例化時，只需註釋所需的 fallback 方法。

實現斷路器的方法有兩種，一種是黑盒方式，另一種是白盒方式。Istio 作爲一種代理管理工具，使用了黑盒方式，它實現起來很簡單，不依賴於底層技術棧，而且可以在事後配置。另一方面，Hystrix 庫使用白盒方式，它允許所有不同類型的 fallback:

  • 單個默認值；
  • 一個緩存；
  • 調用其他服務。

它還提供了級聯回退（cascading fallbacks）。這些額外的特性是有代價的：它需要在開發階段就做出fallback 的決策。

這兩種方法之間的最佳匹配可能會依靠自己的上下文: 在某些情況下，如引用的服務，一個白盒戰略後備可能是一個更好的選擇，而對於其他情況下快速失敗可能是完全可以接受的，如一個集中的遠程登錄服務。

常用的熔斷方法包括自動熔斷與手動熔斷。發生熔斷時也可以選擇 fail-fast 或者 fallback。這些用戶都可以基於需求靈活使用。

智能路由

最後，我們來看一下智能路由帶來的高可用。智能路由這裏包括（客戶端）負載均衡與實例容錯策略。對於 Spring Cloud 框架來說，這部分能力由 Ribbon 來提供，Ribbon 支持隨機、輪詢、響應時間權重等負載均衡算法。而對於 Service Mesh 框架，這部分能力由 Envoy 提供，Envoy 支持隨機、輪詢（加權）、環哈希等算法。爲了實現兩套系統的規則統一對齊，可以採用其交集。

而容錯策略包括：

  • failover：失敗後自動切換其他服務器，支持配置重試次數；
  • failfast：失敗立即報錯，不再重試；
  • failresnd：將失敗請求放入緩存隊列、異步處理，搭配 failover 使用。

Istio 支持重試策略配置，而 fail-fast 即對應與重試次數爲0。

總結

微服務的高可用是一個複雜的問題，往往需要從多個角度去看，包括：

  1. 從手段看高可用。主要使用的技術手段是服務和數據的冗餘備份和失效轉移，一組服務或一組數據都能在多節點上，之間相互備份。當一臺機器宕機或出現問題的時候，可以從當前的服務切換到其他可用的服務，不影響系統的可用性，也不會導致數據丟失。
  2. 從架構看高可用。保持簡單的架構，目前多數網站採用的是比較經典的分層架構，應用層、服務層、數據層。應用層是處理一些業務邏輯，服務層提供一些數據和業務緊密相關服務，數據層負責對數據進行讀寫。簡單的架構可以使應用層，服務層可以保持無狀態化進行水平擴展，這個屬於計算高可用。同時在做架構設計的時候，也應該考慮 CAP 理論。
  3. 從硬件看高可用。首先得確認硬件總是可能壞的，網絡總是不穩定的。解決它的方法也是一個服務器不夠就來多幾個，一個機櫃不夠就來幾個，一個機房不夠就來幾個。
  4. 從軟件看高可用。軟件的開發不嚴謹，發佈不規範也是導致各種不可用出現，通過控制軟件開發過程質量監控，通過測試，預發佈，灰度發佈等手段也是減少不可用的措施。
  5. 從治理看高可用。將服務規範化，事前做好服務分割，做好服務監控，預判不可用的出現，在不可用出現之前發現問題，解決問題。比如在服務上線後，根據經驗，配置服務限流規則以及自動熔斷規則。

以上就是本期分享的全部內容。

直播回放地址： https://www.bilibili.com/video/BV1WT4y1u73W

分享 PPT 下載地址： https://github.com/servicemesher/meetup-slides/tree/master/2020/05/virtual

參考資料

相關文章