如何保證服務(wù)的高可用性 HA（High Availability）?

高可用HA（High Availability）是分布式系統(tǒng)架構(gòu)設(shè)計中必須考慮的因素之一，它通常是指，通過設(shè)計減少系統(tǒng)不能提供服務(wù)的時間。方法論上，高可用是通過冗余+自動故障轉(zhuǎn)移來實現(xiàn)的。

我們都知道，單點(diǎn)是系統(tǒng)高可用的大敵，單點(diǎn)往往是系統(tǒng)高可用最大的風(fēng)險和敵人，應(yīng)該盡量在系統(tǒng)設(shè)計的過程中避免單點(diǎn)。

方法論上，高可用保證的原則是“集群化”，或者叫“冗余”：只有一個單點(diǎn)，掛了服務(wù)會受影響；如果有冗余備份，掛了還有其他backup能夠頂上。

保證系統(tǒng)高可用，架構(gòu)設(shè)計的核心準(zhǔn)則是：冗余。有了冗余之后，還不夠，每次出現(xiàn)故障需要人工介入恢復(fù)勢必會增加系統(tǒng)的不可服務(wù)實踐。所以，又往往是通過“自動故障轉(zhuǎn)移”來實現(xiàn)系統(tǒng)的高可用。

互聯(lián)網(wǎng)架構(gòu)中，通常是通過冗余+自動故障轉(zhuǎn)移來保證系統(tǒng)的高可用特性。

從實戰(zhàn)經(jīng)驗來看如何保證服務(wù)的高可用性：

一：服務(wù)架構(gòu)層面
（1）根據(jù)服務(wù)對象地區(qū)，考慮節(jié)點(diǎn)分布

（2）避免服務(wù)單點(diǎn)，至少雙機(jī)
（3）防止代碼之間干擾，避免穩(wěn)定代碼和迭代頻繁代碼放在一起，可以按照業(yè)務(wù)或者功能做服務(wù)分離。
（4）防止服務(wù)之間干擾，重要服務(wù)最好做隔離，單獨(dú)部署
（5）防止數(shù)據(jù)庫壓力過大，不然，可能產(chǎn)生雪崩效應(yīng)，可以根據(jù)業(yè)務(wù)特點(diǎn)做分庫分表，加緩存等處理.
（6）保證服務(wù)能力buffer, 盡量有冗余處理能力.

二：運(yùn)維層面
（1）服務(wù)監(jiān)控。比如磁盤、CPU、網(wǎng)絡(luò)
（2）監(jiān)控多級別，到達(dá)不同級別給出不同警告

三：代碼層面
（1）保證代碼異常不會導(dǎo)致服務(wù)掛掉
（2）保證服務(wù)是無狀態(tài)的，可以支持水平擴(kuò)展

分層高可用架構(gòu)實踐

常見互聯(lián)網(wǎng)分布式架構(gòu)如上，分為：

（1）客戶端層：典型調(diào)用方是瀏覽器browser或者手機(jī)應(yīng)用APP
（2）反向代理層：系統(tǒng)入口，反向代理
（3）站點(diǎn)應(yīng)用層：實現(xiàn)核心應(yīng)用邏輯，返回html或者json
（4）服務(wù)層：如果實現(xiàn)了服務(wù)化，就有這一層
（5）數(shù)據(jù)-緩存層：緩存加速訪問存儲
（6）數(shù)據(jù)-數(shù)據(jù)庫層：數(shù)據(jù)庫固化數(shù)據(jù)存儲
整個系統(tǒng)的高可用，又是通過每一層的冗余+自動故障轉(zhuǎn)移來綜合實現(xiàn)的。

1. 客戶端層->反向代理層的高可用

客戶端層到反向代理層的高可用，是通過反向代理層的冗余來實現(xiàn)的。以nginx為例：有兩臺nginx，一臺對線上提供服務(wù)，另一臺冗余以保證高可用，常見的實踐是keepalived存活探測，相同virtual IP提供服務(wù)。

自動故障轉(zhuǎn)移：當(dāng)nginx掛了的時候，keepalived能夠探測到，會自動的進(jìn)行故障轉(zhuǎn)移，將流量自動遷移到shadow-nginx，由于使用的是相同的virtual IP，這個切換過程對調(diào)用方是透明的。

2. 反向代理層->站點(diǎn)層的高可用

反向代理層到站點(diǎn)層的高可用，是通過站點(diǎn)層的冗余來實現(xiàn)的。假設(shè)反向代理層是nginx，nginx.conf里能夠配置多個web后端，并且nginx能夠探測到多個后端的存活性。

自動故障轉(zhuǎn)移：當(dāng)web-server掛了的時候，nginx能夠探測到，會自動的進(jìn)行故障轉(zhuǎn)移，將流量自動遷移到其他的web-server，整個過程由nginx自動完成，對調(diào)用方是透明的。

3. 站點(diǎn)層->服務(wù)層的高可用

站點(diǎn)層到服務(wù)層的高可用，是通過服務(wù)層的冗余來實現(xiàn)的?！胺?wù)連接池”會建立與下游服務(wù)多個連接，每次請求會“隨機(jī)”選取連接來訪問下游服務(wù)。

自動故障轉(zhuǎn)移：當(dāng)service掛了的時候，service-connection-pool能夠探測到，會自動的進(jìn)行故障轉(zhuǎn)移，將流量自動遷移到其他的service，整個過程由連接池自動完成，對調(diào)用方是透明的（所以說RPC-client中的服務(wù)連接池是很重要的基礎(chǔ)組件）。

4. 服務(wù)層>緩存層的高可用

服務(wù)層到緩存層的高可用，是通過緩存數(shù)據(jù)的冗余來實現(xiàn)的。 緩存層的數(shù)據(jù)冗余又有幾種方式：第一種是利用客戶端的封裝，service對cache進(jìn)行雙讀或者雙寫。

緩存層也可以通過支持主從同步的緩存集群來解決緩存層的高可用問題。

以redis為例，redis天然支持主從同步，redis官方也有sentinel哨兵機(jī)制，來做redis的存活性檢測。

自動故障轉(zhuǎn)移：當(dāng)redis主掛了的時候，sentinel能夠探測到，會通知調(diào)用方訪問新的redis，整個過程由sentinel和redis集群配合完成，對調(diào)用方是透明的。

說完緩存的高可用，這里要多說一句，業(yè)務(wù)對緩存并不一定有“高可用”要求，更多的對緩存的使用場景，是用來“加速數(shù)據(jù)訪問”：把一部分?jǐn)?shù)據(jù)放到緩存里，如果緩存掛了或者緩存沒有命中，是可以去后端的數(shù)據(jù)庫中再取數(shù)據(jù)的。

這類允許“cache miss”的業(yè)務(wù)場景，緩存架構(gòu)的建議是：

將kv緩存封裝成服務(wù)集群，上游設(shè)置一個代理（代理可以用集群的方式保證高可用），代理的后端根據(jù)緩存訪問的key水平切分成若干個實例，每個實例的訪問并不做高可用。

緩存實例掛了屏蔽：當(dāng)有水平切分的實例掛掉時，代理層直接返回cache miss，此時緩存掛掉對調(diào)用方也是透明的。key水平切分實例減少，不建議做re-hash，這樣容易引發(fā)緩存數(shù)據(jù)的不一致。

5. 服務(wù)層>數(shù)據(jù)庫層的高可用

大部分互聯(lián)網(wǎng)技術(shù)，數(shù)據(jù)庫層都用了“主從同步，讀寫分離”架構(gòu)，所以數(shù)據(jù)庫層的高可用，又分為“讀庫高可用”與“寫庫高可用”兩類。

服務(wù)層>數(shù)據(jù)庫層“讀”的高可用

服務(wù)層到數(shù)據(jù)庫讀的高可用，是通過讀庫的冗余來實現(xiàn)的。

既然冗余了讀庫，一般來說就至少有2個從庫，“數(shù)據(jù)庫連接池”會建立與讀庫多個連接，每次請求會路由到這些讀庫。

自動故障轉(zhuǎn)移：當(dāng)讀庫掛了的時候，db-connection-pool能夠探測到，會自動的進(jìn)行故障轉(zhuǎn)移，將流量自動遷移到其他的讀庫，整個過程由連接池自動完成，對調(diào)用方是透明的（所以說DAO中的數(shù)據(jù)庫連接池是很重要的基礎(chǔ)組件）。

服務(wù)層>數(shù)據(jù)庫層“寫”的高可用

服務(wù)層到數(shù)據(jù)庫寫的高可用，是通過寫庫的冗余來實現(xiàn)的。

以mysql為例，可以設(shè)置兩個mysql雙主同步，一臺對線上提供服務(wù)，另一臺冗余以保證高可用，常見的實踐是keepalived存活探測，相同virtual IP提供服務(wù)。

自動故障轉(zhuǎn)移：

當(dāng)寫庫掛了的時候，keepalived能夠探測到，會自動的進(jìn)行故障轉(zhuǎn)移，將流量自動遷移到shadow-db-master，由于使用的是相同的virtual IP，這個切換過程對調(diào)用方是透明的。

小結(jié):

整個互聯(lián)網(wǎng)分層系統(tǒng)架構(gòu)的高可用，又是通過每一層的冗余+自動故障轉(zhuǎn)移來綜合實現(xiàn)的，具體的：

（1）客戶端層到反向代理層的高可用，是通過反向代理層的冗余實現(xiàn)的，常見實踐是keepalived + virtual IP自動故障轉(zhuǎn)移。
（2）反向代理層到站點(diǎn)層的高可用，是通過站點(diǎn)層的冗余實現(xiàn)的，常見實踐是nginx與web-server之間的存活性探測與自動故障轉(zhuǎn)移。
（3）站點(diǎn)層到服務(wù)層的高可用，是通過服務(wù)層的冗余實現(xiàn)的，常見實踐是通過service-connection-pool來保證自動故障轉(zhuǎn)移。
（4）服務(wù)層到緩存層的高可用，是通過緩存數(shù)據(jù)的冗余實現(xiàn)的，常見實踐是緩存客戶端雙讀雙寫，或者利用緩存集群的主從數(shù)據(jù)同步與sentinel?；钆c自動故障轉(zhuǎn)移；更多的業(yè)務(wù)場景，對緩存沒有高可用要求，可以使用緩存服務(wù)化來對調(diào)用方屏蔽底層復(fù)雜性。
（5）服務(wù)層到數(shù)據(jù)庫“讀”的高可用，是通過讀庫的冗余實現(xiàn)的，常見實踐是通過db-connection-pool來保證自動故障轉(zhuǎn)移。
（6）服務(wù)層到數(shù)據(jù)庫“寫”的高可用，是通過寫庫的冗余實現(xiàn)的，常見實踐是keepalived + virtual IP自動故障轉(zhuǎn)移。

SLA 是什么?

SLA：服務(wù)等級協(xié)議（簡稱：SLA，全稱：service level agreement）。是在一定開銷下為保障服務(wù)的性能和可用性，服務(wù)提供商與用戶間定義的一種雙方認(rèn)可的協(xié)定。通常這個開銷是驅(qū)動提供服務(wù)質(zhì)量的主要因素。

SLA的定義來源百度，這到底是什么意思呢？

我們平常經(jīng)常看到互聯(lián)網(wǎng)公司喊口號，我們今年一定要做到3個9、4個9，即99.9%、99.99%，甚至還有5個9，即99.999%。

這么多9代表什么意思呢？

首先，SLA的概念，對互聯(lián)網(wǎng)公司來說就是網(wǎng)站服務(wù)可用性的一個保證。9越多代表全年服務(wù)可用時間越長服務(wù)更可靠，停機(jī)時間越短，反之亦然。

這么多9是怎么計算的呢？

全年拿365天做計算吧，看看幾個9要停機(jī)多久時間做能才能達(dá)到！

1年 = 365天 = 8760小時

99.9 = 8760 * 0.1% = 8760 * 0.001 = 8.76小時

99.99 = 8760 * 0.0001 = 0.876小時 = 0.876 * 60 = 52.6分鐘

99.999 = 8760 * 0.00001 = 0.0876小時 = 0.0876 * 60 = 5.26分鐘

從以上看來，全年停機(jī)5.26分鐘才能做到99.999%，即5個9。依此類推，要達(dá)到6個9及更多9，可說是非常難了吧。

怎么做到更多的9?

每個公司對幾個9的定義都不一樣，互聯(lián)網(wǎng)公司至少都是99.99吧。像一些政府網(wǎng)站，如社保公積金等，經(jīng)常故障服務(wù)不可用，能做到99.9就不錯了。

如果我們提供的服務(wù)可用性越低，意味著造成的損失也越大，別的不說，如果是特別重要的時刻，或許就在某一分鐘，你可能就會因服務(wù)不可用而丟掉一筆大的訂單，這都是始料未及的。所以，只要盡可能的提升SLA可用性才能最大化的提高企業(yè)生產(chǎn)力。

要做到更多的9，就要不斷的監(jiān)控自己的服務(wù)，服務(wù)掛掉能及時恢復(fù)服務(wù)。就像開車出遠(yuǎn)門，首先得檢查輪胎，同時還得準(zhǔn)備一個備胎一樣的道理?，F(xiàn)在的產(chǎn)品和系統(tǒng)都非常的復(fù)雜，彼此連接依賴越來越復(fù)雜，為了整體的高速運(yùn)轉(zhuǎn)，對每個部件的穩(wěn)定性越來越高，越來越精密，發(fā)展到一定程度，人力已經(jīng)無法掌控，任何一個組件出異常都有可能牽一發(fā)而動全身，影響全局。每個部件的穩(wěn)定性和精密程度決定了整體的工程質(zhì)量，也決定了整體的發(fā)展速度。

定義SLI

SLI, Service Level Indicator 關(guān)鍵量化指標(biāo).

SLI關(guān)注下面五點(diǎn)：
要測量的指標(biāo)是什么？

測量時的系統(tǒng)狀態(tài)？

如何匯總處理測量的指標(biāo)？

測量指標(biāo)能否準(zhǔn)確描述服務(wù)質(zhì)量？

測量指標(biāo)的可靠度(trust worthy)？

SLO,Service-Level Objective 服務(wù)等級目標(biāo),指定了服務(wù)所提供功能的一種期望狀態(tài)。

一個有明確SLA的服務(wù)最理想的運(yùn)行狀態(tài)是： 增加額外資源來改進(jìn)系統(tǒng)所帶來的收益小于把該資源投給其他服務(wù)所帶來的收益。

一個簡單的例子就是某服務(wù)可用性從99.9%提高到99.99%所需要的資源和帶來的收益之比，是決定該服務(wù)是否應(yīng)該提供4個9的重要依據(jù)。

SLA的計算方式，是使用正常運(yùn)行時間/（正常運(yùn)行時間+故障時間），當(dāng)指標(biāo)為99.99的時候，每年的停機(jī)時間只有52.26分鐘。。。停機(jī)時間又分為兩種，一種是計劃內(nèi)停機(jī)時間，一種是計劃外停機(jī)時間，而運(yùn)維則主要關(guān)注計劃外停機(jī)時間。

在分布式系統(tǒng)中用時間指標(biāo)來衡量系統(tǒng)的可用性，簡直就是無效的。分布式系統(tǒng)中，部分可用的情況太多了，例如后端有兩個rs，而一個rs壞了，那么就會有百分之五十的請求失敗。這種情況SLA怎么來計算？扣時間還是不扣呢？

在分布式系統(tǒng)中，一般使用請求的成功率來計算SLA，也就是

SLA=請求成功/（請求成功+請求失敗）

在使用這種計算方式的時候，無論你是前端的web服務(wù)，還是后端的存儲服務(wù)，還是離線服務(wù)，都是可以很好的計算。畢竟是一個可以量化的數(shù)據(jù)。在定義SLA的時候，順便可以定義出監(jiān)控的主要指標(biāo)，例如請求的延遲，吞吐量等。

在進(jìn)行定義這些關(guān)鍵性指標(biāo)的時候，也就是定義哪些請求成功，哪些請求失敗，是有很大關(guān)系的，例如支付寶的核心功能是支付，如果支付功能可以，那么就滿足了大多數(shù)的高可用，而所謂的其他的一些附加功能，例如城市服務(wù)，也影響不了多少人，當(dāng)然, 也要看基數(shù)。

在提供服務(wù)的時候，服務(wù)可以分為兩種類型，一種類型是面對消費(fèi)者的服務(wù)，一種是基礎(chǔ)設(shè)施服務(wù)，例如微信就是面對消費(fèi)者的服務(wù)，而各種云平臺則是基礎(chǔ)設(shè)施服務(wù)。

當(dāng)面對消費(fèi)者服務(wù)的時候，一般會有對應(yīng)的產(chǎn)品經(jīng)理，那么可以由產(chǎn)品經(jīng)理定義各種關(guān)鍵性的指標(biāo)來衡量一個服務(wù)的可用性，例如微信在定義的時候，可以使用發(fā)送消息的成功率；消費(fèi)者服務(wù)，可以參考競爭對手的可用性水平；免費(fèi)的還是收費(fèi)的；有沒有替代產(chǎn)品可以使用。在這個時候，其實還可以定義服務(wù)降級，例如微信最常用的功能是發(fā)送消息和朋友圈，這兩個服務(wù)的可用性可以定義為四個9，而對于所謂的搖一搖，附近等服務(wù)，可以定義低等級的可用性，例如兩個9，這種構(gòu)建方式，可以很大程度上節(jié)省成本，畢竟物理服務(wù)器冗余才是提高可用性的唯一方式。

在消費(fèi)者服務(wù)類型中，還需要注意每個請求的成敗后果是不一樣的，例如系統(tǒng)注冊，或者是一個信息發(fā)送失敗，系統(tǒng)注冊失敗，可能就不用這個系統(tǒng)了，而一個信息發(fā)送失敗，用戶可能認(rèn)為是自己的網(wǎng)絡(luò)有問題。。。

在提供基礎(chǔ)設(shè)施服務(wù)的時候，一般分為兩個部分，一個部分是直接提供給用戶使用的功能，例如提供VM訪問服務(wù)；一個部分是平臺的管控功能，例如云平臺里面創(chuàng)建虛擬機(jī)，創(chuàng)建SLB等。這兩個的失敗是完全不一樣的，用戶的功能出了問題，那么就是故障了，但是管控服務(wù)出現(xiàn)問題，只要及時修好就行了，這種一般使用的評率很少，所以請求數(shù)量也不多。

亞馬遜的S3服務(wù)水平協(xié)議

可用性保證（Service Commitment ）

保證“每月99.9%的正常運(yùn)行時間”。S3 SLA保證一個月里所有以5分鐘為單位的時間片中，平均有99.9%是可用的。SLA容許的最遭情況等于每月有40分鐘不可用。

服務(wù)補(bǔ)償

如果達(dá)不到SLA的承諾，Amazon會提供服務(wù)補(bǔ)償，如果達(dá)不到 99.9%的服務(wù)水平，那么Amazon將減免下個月10%的費(fèi)用。如果可用性下降到99.0%以下，換算后相當(dāng)于一個月內(nèi)至少有將近7個小時無法服務(wù)， 那么Amazon將減免25%的費(fèi)用。

假設(shè)一個用戶存放了500G的數(shù)據(jù)。把500G數(shù)據(jù)放進(jìn)S3并且在一個月內(nèi)全部數(shù)據(jù)都使用10次的話，總共的費(fèi)用大約是 $1000。

如果發(fā)生5小時的故障，那么該用戶將得到 $100 的退款。如果故障時間從7個小時到一整個月的話， 該用戶將得到 $250 的補(bǔ)償。

附:支付寶高可用性架構(gòu)演進(jìn)

應(yīng)用中間件技術(shù)架構(gòu)應(yīng)用:

展現(xiàn) SOFA-MVC (full stack)分布式 session安全框架 security SOFA-Mashup (component) A/B Test組件

協(xié)調(diào)/調(diào)度中心 (scheduler)

服務(wù)容器 組件集合(rule,jbpm,xts,cache,schedule) SOFA3 (SCA:bundle,service/reference,pub/sub,extension,sla) CloudEngine (servlet 3.0,drm,management,osgi) web Tomcat Datasource zds drm webservice jetty Apache/nginx (spdy,https)

配置中心 (confreg2.0)

應(yīng)用中間件平臺

協(xié)調(diào)中心 (zdipper,zookeeper)

分布式鎖 (dlslock)

JVM (JVMTI,JNI)

超時調(diào)度中心 (timeout)

參考資料

https://blog.csdn.net/daiyudong2020/article/details/50550471
https://blog.csdn.net/chdhust/article/details/74086776
https://blog.csdn.net/tm6znf87mdg7bo/article/details/83663392
https://blog.csdn.net/chenyong19870904/article/details/52986784
https://wenku.baidu.com/view/444baa0ace2f0066f433221e.html

Kotlin開發(fā)者社區(qū)

專注分享 Java、 Kotlin、Spring/Spring Boot、MySQL、redis、neo4j、NoSQL、Android、JavaScript、React、Node、函數(shù)式編程、編程思想、"高可用，高性能，高實時"大型分布式系統(tǒng)架構(gòu)設(shè)計主題。

High availability, high performance, high real-time large-scale distributed system architecture design。

分布式框架：Zookeeper、分布式中間件框架等
分布式存儲：GridFS、FastDFS、TFS、MemCache、redis等
分布式數(shù)據(jù)庫：Cobar、tddl、Amoeba、Mycat
云計算、大數(shù)據(jù)、AI算法
虛擬化、云原生技術(shù)
分布式計算框架：MapReduce、Hadoop、Storm、Flink等
分布式通信機(jī)制：Dubbo、RPC調(diào)用、共享遠(yuǎn)程數(shù)據(jù)、消息隊列等
消息隊列MQ：Kafka、MetaQ，RocketMQ
怎樣打造高可用系統(tǒng)：基于硬件、軟件中間件、系統(tǒng)架構(gòu)等一些典型方案的實現(xiàn)：HAProxy、基于Corosync+Pacemaker的高可用集群套件中間件系統(tǒng)
Mycat架構(gòu)分布式演進(jìn)
大數(shù)據(jù)Join背后的難題：數(shù)據(jù)、網(wǎng)絡(luò)、內(nèi)存和計算能力的矛盾和調(diào)和
Java分布式系統(tǒng)中的高性能難題：AIO，NIO，Netty還是自己開發(fā)框架？
高性能事件派發(fā)機(jī)制：線程池模型、Disruptor模型等等。。。

合抱之木，生于毫末；九層之臺，起于壘土；千里之行，始于足下。不積跬步，無以至千里；不積小流，無以成江河。