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：将失敗請求放入緩存隊列、異步處理，搭配
- 使用；
Istio 支援重試政策配置，而 fail-fast即對應與重試次數為0。
總結
微服務的高可用是一個複雜的問題，往往需要從多個角度去看，包括：
- 從手段看高可用。主要使用的技術手段是服務和資料的備援備份和失效轉移，一組服務或一組資料都能在多節點上，之間互相備份。當一台機器當機或出現問題的時候，可以從目前的服務切換到其他可用的服務，不影響系統的可用性，也不會導緻資料丢失。
-
從架構看高可用。保持簡單的架構，目前多數網站采用的是比較經典的分層架構，應用層、服務層、資料層。應用層是處理一些業務邏輯，服務層提供一些資料和業務緊密相關服務，資料層負責對資料進行讀寫。簡單的架構可以使應用層，服務層可以保持無狀态化進行水準擴充，這個屬于計算高可用。同時在做架構設計的時候，也應該考慮
CAP 理論。
- 從硬體看高可用。首先得确認硬體總是可能壞的，網絡總是不穩定的。解決它的方法也是一個伺服器不夠就來多幾個，一個機櫃不夠就來幾個，一個機房不夠就來幾個。
- 從軟體看高可用。軟體的開發不嚴謹，釋出不規範也是導緻各種不可用出現，通過控制軟體開發過程品質監控，通過測試，預釋出，灰階釋出等手段也是減少不可用的措施。
- 從治理看高可用。将服務規範化，事前做好服務分割，做好服務監控，預判不可用的出現，在不可用出現之前發現問題，解決問題。比如在服務上線後，根據經驗，配置服務限流規則以及自動熔斷規則。
以上就是本期分享的全部内容。
- 直播回放位址： https://www.bilibili.com/video/BV1WT4y1u73W
- 分享 PPT 下載下傳位址： https://github.com/servicemesher/meetup-slides/tree/master/2020/05/virtual