【51CTO.com原創(chuàng)稿件】高可用并不是一套整體解決方案，而是由諸多環(huán)節(jié)組成，一環(huán)扣一環(huán)，鬼知道為了這些串聯(lián)起來的環(huán)節(jié)，我得出多少張牌去應(yīng)對，才能最終組成一個整個系統(tǒng)的高可用落地方案。
圖片來自 Pexels
什么是高可用
在定義什么是高可用，可以先定義下什么是不可用，一個網(wǎng)站的內(nèi)容最終呈現(xiàn)在用戶面前需要經(jīng)過若干個環(huán)節(jié)，而其中只要任何一個環(huán)節(jié)出現(xiàn)了故障，都可能導(dǎo)致網(wǎng)站頁面不可訪問，這個也就是網(wǎng)站不可用的情況。
參考維基百科，看看維基怎么定義高可用：
系統(tǒng)無中斷地執(zhí)行其功能的能力，代表系統(tǒng)的可用性程度，是進(jìn)行系統(tǒng)設(shè)計時的準(zhǔn)則之一。
這個難點或是重點在于“無中斷”，要做到 7x24 小時無中斷無異常的服務(wù)提供。
為什么需要高可用
一套對外提供服務(wù)的系統(tǒng)是需要硬件，軟件相結(jié)合，但是我們的硬件總是會出故障，軟件會有 Bug，硬件會慢慢老化，網(wǎng)絡(luò)總是不穩(wěn)定，軟件會越來越復(fù)雜和龐大。
除了硬件軟件在本質(zhì)上無法做到“無中斷”，外部環(huán)境也可能導(dǎo)致服務(wù)的中斷，例如斷電，地震，火災(zāi)，光纖被挖掘機挖斷，這些影響的程度可能更大。
高可用的評價緯度
在業(yè)界有一套比較出名的評定網(wǎng)站可用性的指標(biāo)，常用 N 個 9 來量化可用性，可以直接映射到網(wǎng)站正常運行時間的百分比上：
之前就職的一家互聯(lián)網(wǎng)公司也是按照這個指標(biāo)去界定可用性，不過在執(zhí)行的過程中也碰到了一些問題。
例如，有一些服務(wù)的升級或數(shù)據(jù)遷移明明可以在深夜停機或停服務(wù)進(jìn)行，然而考慮到以后的報告要顯示出我們的系統(tǒng)達(dá)到了多少個 9 的高可用，而放棄停服務(wù)這種簡單的解決方案，例如停機 2 個小時，就永遠(yuǎn)也達(dá)不到 4 個 9。
然而在一些高并發(fā)的場合，例如在秒殺或拼團，雖然服務(wù)停止了幾分鐘，但是這個對整個公司業(yè)務(wù)的影響可能是非常重大的，分分鐘丟失的訂單可能是一個龐大的數(shù)量。
所以 N 個 9 來量化可用性其實也得考慮業(yè)務(wù)的情況。
微服務(wù)高可用設(shè)計手段
高可用是一個比較復(fù)雜的命題，基本上在所有的處理中都會涉及到高可用，所有在設(shè)計高可用方案也涉及到了方方面面。
這中間將會出現(xiàn)的細(xì)節(jié)是多種多樣的，所以我們需要對這樣一個微服務(wù)高可用方案進(jìn)行一個頂層的設(shè)計，圍繞服務(wù)高可用，先檢查下我們手里有多少張牌。
服務(wù)冗余
①冗余策略
每一個訪問可能都會有多個服務(wù)組合而成，每個機器每個服務(wù)都可能出現(xiàn)問題，所以第一個考慮到的就是每個服務(wù)必須不止一份可以是多份。
所謂多份一致的服務(wù)就是服務(wù)的冗余，這里說的服務(wù)泛指了機器的服務(wù)，容器的服務(wù)，還有微服務(wù)本身的服務(wù)。
在機器服務(wù)層面需要考慮，各個機器間的冗余是否有在物理空間進(jìn)行隔離冗余。
例如是否所有機器分別部署在不同機房，如果在同一個機房是否做到了部署在不同的機柜，如果是 Docker 容器是否部署在分別不同的物理機上面。
采取的策略其實也還是根據(jù)服務(wù)的業(yè)務(wù)而定，所以需要對服務(wù)進(jìn)行分級評分，從而采取不同的策略。
不同的策略安全程度不同，伴隨著的成本也是不同，安全等級更高的服務(wù)可能還不止考慮不同機房，還需要把各個機房所處的區(qū)域考慮進(jìn)行。
例如，兩個機房不要處在同一個地震帶上等等。
②無狀態(tài)化
服務(wù)的冗余會要求我們可以隨時對服務(wù)進(jìn)行擴容或者縮容，有可能我們會從 2 臺機器變成 3 臺機器。
想要對服務(wù)進(jìn)行隨時隨地的擴縮容，就要求我們的服務(wù)是一個無狀態(tài)化，所謂無狀態(tài)化就是每個服務(wù)的服務(wù)內(nèi)容和數(shù)據(jù)都是一致的。
例如，從我們的微服務(wù)架構(gòu)來看，我們總共分水平劃分了好幾個層，正因為我們每個層都做到了無狀態(tài)，所以在這個水平架構(gòu)的擴張是非常的簡單。
假設(shè)，我們需要對網(wǎng)關(guān)進(jìn)行擴容，我們只需要增加服務(wù)就可以，而不需要去考慮網(wǎng)關(guān)是否存儲了一個額外的數(shù)據(jù)。
網(wǎng)關(guān)不保存任何的 Session 數(shù)據(jù)，不提供會造成一致性的服務(wù)，將不一致的數(shù)據(jù)進(jìn)行幾種存儲，借助更加擅長數(shù)據(jù)同步的中間件來完成。
這個是目前主流的方案，服務(wù)本身盡可能提供邏輯的服務(wù)，將數(shù)據(jù)的一致性保證集中式處理，這樣就可以把“狀態(tài)”抽取出來，讓網(wǎng)關(guān)保持一個“無狀態(tài)”。
這里僅僅是舉了網(wǎng)關(guān)的例子，在微服務(wù)基本所有的服務(wù)，都應(yīng)該按照這種思路去做。
如果服務(wù)中有狀態(tài)，就應(yīng)該把狀態(tài)抽取出來，讓更加擅長處理數(shù)據(jù)的組件來處理，而不是在微服務(wù)中去兼容有數(shù)據(jù)的狀態(tài)。
數(shù)據(jù)存儲高可用
之前上面說的服務(wù)冗余，可以簡單的理解為計算的高可用，計算高可用只需要做到無狀態(tài)既可簡單的擴容縮容，但是對于需要存儲數(shù)據(jù)的系統(tǒng)來說，數(shù)據(jù)本身就是有狀態(tài)。
跟存儲與計算相比，有一個本質(zhì)的差別：將數(shù)據(jù)從一臺機器搬到另一臺機器，需要經(jīng)過線路進(jìn)行傳輸。
網(wǎng)絡(luò)是不穩(wěn)定的，特別是跨機房的網(wǎng)絡(luò)，Ping 的延時可能是幾十幾百毫秒，雖然毫秒對于人來說幾乎沒有什么感覺，但是對于高可用系統(tǒng)來說，就是本質(zhì)上的不同，這意味著整個系統(tǒng)在某個時間點上，數(shù)據(jù)肯定是不一致的。
按照“數(shù)據(jù)+邏輯=業(yè)務(wù)”的公式來看，數(shù)據(jù)不一致，邏輯一致，最后的業(yè)務(wù)表現(xiàn)也會不一致。
舉個例子：
無論是正常情況下的傳輸延時，還是異常情況下的傳輸中斷，都會導(dǎo)致系統(tǒng)的數(shù)據(jù)在某個時間點出現(xiàn)不一致。
而數(shù)據(jù)的不一致又會導(dǎo)致業(yè)務(wù)出現(xiàn)問題，但是如果數(shù)據(jù)不做冗余，系統(tǒng)的高可用無法保證。
所以，存儲高可用的難點不在于怎么備份數(shù)據(jù)，而在于如何減少或者規(guī)避數(shù)據(jù)不一致對業(yè)務(wù)造成的影響。
分布式領(lǐng)域中有一個著名的 CAP 定理，從理論上論證了存儲高可用的復(fù)雜度，也就是說，存儲高可用不可能同時滿足“一致性，可用性，分區(qū)容錯性”。
最多只能滿足 2 個，其中分區(qū)容錯在分布式中是必須的，就意味著，我們在做架構(gòu)設(shè)計時必須結(jié)合業(yè)務(wù)對一致性和可用性進(jìn)行取舍。
存儲高可用方案的本質(zhì)是將數(shù)據(jù)復(fù)制到多個存儲設(shè)備中，通過數(shù)據(jù)冗余的方式來實現(xiàn)高可用，其復(fù)雜度主要呈現(xiàn)在數(shù)據(jù)復(fù)制的延遲或中斷導(dǎo)致數(shù)據(jù)的不一致性。
我們在設(shè)計存儲架構(gòu)時必須考慮到以下幾個方面：
- 數(shù)據(jù)怎么進(jìn)行復(fù)制
- 架構(gòu)中每個節(jié)點的職責(zé)是什么
- 數(shù)據(jù)復(fù)制出現(xiàn)延遲怎么處理
- 當(dāng)架構(gòu)中節(jié)點出現(xiàn)錯誤怎么保證高可用
①數(shù)據(jù)主從復(fù)制
主從復(fù)制是最常見的也是最簡單的存儲高可用方案，例如 MySQL，redis 等等。
其架構(gòu)的優(yōu)點就是簡單，主機復(fù)制寫和讀，而從機只負(fù)責(zé)讀操作，在讀并發(fā)高時候可用擴張從庫的數(shù)量減低壓力，主機出現(xiàn)故障，讀操作也可以保證讀業(yè)務(wù)的順利進(jìn)行。
缺點就是客戶端必須感知主從關(guān)系的存在，將不同的操作發(fā)送給不同的機器進(jìn)行處理。
而且主從復(fù)制中，從機器負(fù)責(zé)讀操作，可能因為主從復(fù)制時延大，出現(xiàn)數(shù)據(jù)不一致性的問題。
②數(shù)據(jù)主從切換
剛說了主從切換存在兩個問題：
主機故障寫操作無法進(jìn)行。
需要人工將其中一臺從機器升級為主機。
為了解決這個兩個問題，我們可以設(shè)計一套主從自動切換的方案，其中涉及到對主機的狀態(tài)檢測，切換的決策，數(shù)據(jù)丟失和沖突的問題。
主機狀態(tài)檢測：需要多個檢查點來檢測主機的機器是否正常，進(jìn)程是否存在，是否出現(xiàn)超時，是否寫操作不可執(zhí)行，是否讀操作不可執(zhí)行，將其進(jìn)行匯總，交給切換決策。
切換決策：確定切換的時間決策，什么情況下從機就應(yīng)該升級為主機，是進(jìn)程不存在，是寫操作不可行，連續(xù)檢測多少失敗次就進(jìn)行切換。
應(yīng)該選擇哪一個從節(jié)點升級為主節(jié)點，一般來說或應(yīng)該選同步步驟最大的從節(jié)點來進(jìn)行升級。切換是自動切換還是半自動切換，通過報警方式，讓人工做一次確認(rèn)。
數(shù)據(jù)丟失和數(shù)據(jù)沖突：數(shù)據(jù)寫到主機，還沒有復(fù)制到從機，主機就掛了，這個時候怎么處理，這個也得考慮業(yè)務(wù)的方式，是要確保 CP 或 AP。
還要考慮一個數(shù)據(jù)沖突的問題，這個問題在 MySQL 中大部分是由自增主鍵引起。
就算不考慮自增主鍵會引起數(shù)據(jù)沖突的問題，其實自增主鍵還要引起很多的問題，這里不細(xì)說，避免使用自增主鍵。
③數(shù)據(jù)分片
上述的數(shù)據(jù)冗余可以通過數(shù)據(jù)的復(fù)制來進(jìn)行解決，但是數(shù)據(jù)的擴張需要通過數(shù)據(jù)的分片來進(jìn)行解決(如果在關(guān)系型數(shù)據(jù)庫是分表)。
何為數(shù)據(jù)分片(Segment，F(xiàn)ragment， Shard， Partition)，就是按照一定的規(guī)則，將數(shù)據(jù)集劃分成相互獨立、正交的數(shù)據(jù)子集，然后將數(shù)據(jù)子集分布到不同的節(jié)點上。
HDFS ， MongoDB 的 Sharding 模式也基本是基于這種分片的模式去實現(xiàn)。
我們在設(shè)計分片主要考慮到的點是：
- 做數(shù)據(jù)分片，如何將數(shù)據(jù)映射到節(jié)點。
- 數(shù)據(jù)分片的特征值，即按照數(shù)據(jù)中的哪一個屬性(字段)來分片。
- 數(shù)據(jù)分片的元數(shù)據(jù)的管理，如何保證元數(shù)據(jù)服務(wù)器的高性能、高可用，如果是一組服務(wù)器，如何保證強一致性。
柔性化/異步化
①異步化
在每一次調(diào)用，時間越長存在超時的風(fēng)險就越大，邏輯越復(fù)雜執(zhí)行的步驟越多，存在失敗的風(fēng)險也就越大。
如果在業(yè)務(wù)允許的情況下，用戶調(diào)用只給用戶必須要的結(jié)果，而不是需要同步的結(jié)果可以放在另外的地方異步去操作，這就減少了超時的風(fēng)險也把復(fù)雜業(yè)務(wù)進(jìn)行拆分減低復(fù)雜度。
當(dāng)然異步化的好處是非常多，例如削峰解耦等等，這里只是從可用的角度出發(fā)。
異步化大致有這三種的實現(xiàn)方式：
- 服務(wù)端接收到請求后，創(chuàng)建新的線程處理業(yè)務(wù)邏輯，服務(wù)端先回應(yīng)答給客戶端。
- 服務(wù)端接收到請求后，服務(wù)端先回應(yīng)答給客戶端，再繼續(xù)處理業(yè)務(wù)邏輯。
- 服務(wù)端接收到請求后，服務(wù)端把信息保存在消息隊列或者數(shù)據(jù)庫，回應(yīng)答給客戶端，服務(wù)端業(yè)務(wù)處理進(jìn)程再從消息隊列或者數(shù)據(jù)庫上讀取信息處理業(yè)務(wù)邏輯。
②柔性化
什么是柔性化?想象一個場景，我們的系統(tǒng)會給每個下單的用戶增加他們下單金額對應(yīng)的積分，當(dāng)一個用戶下單完畢后，我們給他增加積分的服務(wù)出現(xiàn)了問題。
這個時候，我們是要取消掉這個訂單還是先讓訂單通過，積分的問題通過重新或者報警來處理呢?
所謂的柔性化，就是在我們業(yè)務(wù)中允許的情況下，做不到給予用戶百分百可用的，通過降級的手段給到用戶盡可能多的服務(wù)，而不是非得每次都交出去要么 100 分或 0 分的答卷。
怎么去做柔性化，更多其實是對業(yè)務(wù)的理解和判斷，柔性化更多是一種思維，需要對業(yè)務(wù)場景有深入的了解。
在電商訂單的場景中，下單，扣庫存，支付是一定要執(zhí)行的步驟，如果失敗則訂單失敗。
但是加積分，發(fā)貨，售后是可以柔性處理，就算出錯也可以通過日志報警讓人工去檢查，沒必要為加積分損失整個下單的可用性。
兜底/容錯
兜底可能是我們經(jīng)常談?wù)摰囊环N降級的方案，方案是用來實施，但是這里兜底可能更多是一種思想，更多的是一種預(yù)案，每個操作都可以犯錯，我們也可以接受犯錯。
但是每個犯錯我們都必須有一個兜底的預(yù)案，這個兜底的預(yù)案其實就是我們的容錯或者說最大程度避免更大傷害的措施，實際上也是一個不斷降級的過程。
舉個例子：
例如我們首頁請求的用戶個性化推薦商品的接口，發(fā)現(xiàn)推薦系統(tǒng)出錯，我們不應(yīng)該去擴大(直接把異常拋給用戶)或保持調(diào)用接口的錯誤，而是應(yīng)該兼容調(diào)用接口的錯誤，做到更加柔性化。
這時候可以選擇獲取之前沒有失敗接口的緩存數(shù)據(jù)，如果沒有則可以獲取通用商品不用個性化推薦，如果也沒有可以讀取一些靜態(tài)文字進(jìn)行展示。
由于我們架構(gòu)進(jìn)行了分層，分層 App，網(wǎng)關(guān)，業(yè)務(wù)邏輯層，數(shù)據(jù)訪問層等等，在組織結(jié)構(gòu)也進(jìn)行了劃分，與之對應(yīng)的是前端組，后端業(yè)務(wù)邏輯組，甚至有中臺組等等。
既然有代碼和人員架構(gòu)的層級劃分，那么每一層都必須有這樣的思想：包容下一層的錯誤，為上一層提供盡可能無錯的服務(wù)。
舉個例子：
商品的美元售價假設(shè)要用商品人民幣售價/匯率，這個時候錯誤發(fā)生在低層的數(shù)據(jù)層，上一層如果直接進(jìn)行除，肯定就拋出 JAVA.lang.ArithmeticException: / by zero。
本著我們對任何一層調(diào)用服務(wù)都不可信的原則，應(yīng)該對其進(jìn)行容錯處理，不能讓異常擴散，更要保證我們這一層對上一次盡可能的作出最大努力確定的服務(wù)。
負(fù)載均衡
相信負(fù)載均衡這個話題基本已經(jīng)深入每個做微服務(wù)開發(fā)或設(shè)計者的人心，負(fù)載均衡的實現(xiàn)有硬件和軟件。
硬件有 F5，A10 等機器;軟件有 LVS，Nginx，HAProxy 等等，負(fù)載均衡的算法有 Random，RoundRobin，ConsistentHash 等等。
①Nginx 負(fù)載均衡故障轉(zhuǎn)移
轉(zhuǎn)移流程：Nginx 根據(jù)給定好的負(fù)載均衡算法進(jìn)行調(diào)度，當(dāng)請求到 Tomcat1，Nginx 發(fā)現(xiàn) Tomcat1 出現(xiàn)連接錯誤(節(jié)點失效)，Nginx 會根據(jù)一定的機制將 Tomcat1 從調(diào)用的負(fù)載列表中清除。
在下一次請求，Nginx 不會分配請求到有問題的 Tomcat1 上面，會將請求轉(zhuǎn)移到其他的 Tomcat 之上。
節(jié)點失效：Nginx 默認(rèn)判斷節(jié)點失效是以 connect refuse 和 timeout 為標(biāo)準(zhǔn)，在對某個節(jié)點進(jìn)行 fails 累加，當(dāng) fails 大于 max_fails 時，該節(jié)點失效。
節(jié)點恢復(fù)：當(dāng)某個節(jié)點失敗的次數(shù)大于 max_fails 時，但不超過 fail_timeout，Nginx 將不再對該節(jié)點進(jìn)行探測，直到超過失效時間或者所有的節(jié)點都失效，Nginx 會對節(jié)點進(jìn)行重新探測。
②ZK 負(fù)載均衡故障轉(zhuǎn)移
在使用 ZK 作為注冊中心時，故障的發(fā)現(xiàn)是由 ZK 去進(jìn)行發(fā)現(xiàn)，業(yè)務(wù)邏輯層通過 Watch 的心跳機制將自己注冊到 ZK 上，網(wǎng)關(guān)對 ZK 進(jìn)行訂閱就可以知道有多少可以調(diào)用的列表。
當(dāng)業(yè)務(wù)邏輯層在重啟或者被關(guān)閉時就會跟 ZK 斷了心跳，ZK 會更新可調(diào)用列表。
使用 ZK 作為負(fù)載均衡的協(xié)調(diào)器，最大的問題是 ZK 對于服務(wù)是否可用是基于 Pingpong 的方式。
只要服務(wù)心跳存在，ZK 就認(rèn)為服務(wù)是處在可用狀態(tài)，但是服務(wù)如果處在假死的狀態(tài)，ZK 是無從得知的。這個時候，業(yè)務(wù)邏輯服務(wù)是否真正可用只能夠由網(wǎng)關(guān)知道。
冪等設(shè)計：為何會牽出冪等設(shè)計的問題，主要是因為負(fù)載均衡的 Failover 策略，就是對失敗的服務(wù)會進(jìn)行重試。
一般來說，如果是讀操作的服務(wù)，重復(fù)執(zhí)行也不會出問題，但想象一下，如果是一個創(chuàng)建訂單減庫存的操作，第一次調(diào)用也 Tomcat1 超時，再重新調(diào)用了 Tomcat2。
這個時候我們都不能確認(rèn)超時調(diào)用的 Tomcat1 是否真的被調(diào)用，有可能根本就調(diào)用不成功，有可能已經(jīng)調(diào)用成功但是因為某些原因返回超時而已。
所以，很大程度這個接口會被調(diào)用 2 次。如果我們沒有保證冪等性，就有可能一個訂單導(dǎo)致了減少 2 次的庫存。
所謂的冪等性，就是得保證在同一個業(yè)務(wù)中，一個接口被調(diào)用了多次，其導(dǎo)致的結(jié)果都是一樣的。
服務(wù)限流降級熔斷
先來講講微服務(wù)中限流/熔斷的目的是什么，微服務(wù)后，系統(tǒng)分布式部署，系統(tǒng)之間通過 RPC 框架通信，整個系統(tǒng)發(fā)生故障的概率隨著系統(tǒng)規(guī)模的增長而增長，一個小的故障經(jīng)過鏈路的傳遞放大，有可能會造成更大的故障。
限流跟高可用的關(guān)系是什么?假定我們的系統(tǒng)最多只能承受 500 個人的并發(fā)訪問，但某個時候突然增加到 1000 個人進(jìn)來，一下子就把整個系統(tǒng)給壓垮了。
本來還有 500 個人能享受到我們系統(tǒng)的服務(wù)，突然間變成了所有人都無法得到服務(wù)。
與其讓 1000 人都無法得到服務(wù)，不如就讓 500 個人得到服務(wù)，拒絕掉另外 500 個人。限流是對訪問的隔離，是保證了部門系統(tǒng)承受范圍內(nèi)用戶的可用性。
熔斷跟高可用的關(guān)系是什么?上面說了微服務(wù)是一個錯綜復(fù)雜的調(diào)用鏈關(guān)系，假設(shè)模塊 A 調(diào)用模塊 B，模塊 B 又調(diào)用了模塊 C，模塊 C 調(diào)用了模塊 D。
這個時候，模塊 D 出了問題出現(xiàn)嚴(yán)重的時延，這個時候，整個調(diào)用鏈就會被模塊 D 給拖垮。
A 等 B，B 等 C，C 等 D，而且 A B C D 的資源被鎖死得不到釋放，如果流量大的話還容易引起雪崩。
熔斷，主動丟棄模塊 D 的調(diào)用，并在功能上作出一些降級才能保證到我們系統(tǒng)的健壯性。熔斷是對模塊的隔離，是保證了最大功能的可用性。
服務(wù)治理
①服務(wù)模塊劃分
服務(wù)模塊與服務(wù)模塊之間有著千絲萬縷的關(guān)系，但服務(wù)模塊在業(yè)務(wù)中各有權(quán)重。
例如訂單模塊可能是一家電商公司的重中之重，如果出問題將會直接影響整個公司的營收。
而一個后臺的查詢服務(wù)模塊可能也重要，但它的重要等級絕對是沒有像訂單這么重要。
所以，在做服務(wù)治理時，必須明確各個服務(wù)模塊的重要等級，這樣才能更好的做好監(jiān)控，分配好資源。
這個在各個公司有各個公司的一個標(biāo)準(zhǔn)，例如在電商公司，確定服務(wù)的級別可能會更加傾向?qū)τ脩粽埱髷?shù)和營收相關(guān)的作為指標(biāo)。
可能真正的劃分要比這個更為復(fù)雜，必須根據(jù)具體業(yè)務(wù)去定，這個可以從平時服務(wù)模塊的訪問量和流量去預(yù)估。
往往更重要的模塊也會提供更多的資源，所以不僅要對技術(shù)架構(gòu)了如指掌，還要對公司各種業(yè)務(wù)形態(tài)了然于心才可以。
服務(wù)分級不僅僅在故障界定起到重要主要，而且決定了服務(wù)監(jiān)控的力度，服務(wù)監(jiān)控在高可用中起到了一個保障的作用。
它不僅可以保留服務(wù)崩潰的現(xiàn)場以等待日后復(fù)盤，更重要的是它可以起到一個先知，先行判斷的角色，很多時候可以預(yù)先判斷危險，防范于未然。
②服務(wù)監(jiān)控
服務(wù)監(jiān)控是微服務(wù)治理的一個重要環(huán)節(jié)，監(jiān)控系統(tǒng)的完善程度直接影響到我們微服務(wù)質(zhì)量的好壞。
我們的微服務(wù)在線上運行的時候有沒有一套完善的監(jiān)控體系能去了解到它的健康情況，對整個系統(tǒng)的可靠性和穩(wěn)定性是非常重要，可靠性和穩(wěn)定性是高可用的一個前提保證。
服務(wù)的監(jiān)控更多是對于風(fēng)險的預(yù)判，在出現(xiàn)不可用之間就提前的發(fā)現(xiàn)問題，如果系統(tǒng)獲取監(jiān)控報警系統(tǒng)能自我修復(fù)則可以將錯誤消滅在無形，如果系統(tǒng)發(fā)現(xiàn)報警無法自我修復(fù)則可以通知人員提早進(jìn)行接入。
一個比較完善的微服務(wù)監(jiān)控體系需要涉及到哪些層次?如下圖，大致可以劃分為五個層次的監(jiān)控：
基礎(chǔ)設(shè)施監(jiān)控：例如網(wǎng)絡(luò)，交換機，路由器等低層設(shè)備，這些設(shè)備的可靠性穩(wěn)定性就直接影響到上層服務(wù)應(yīng)用的穩(wěn)定性。
所以需要對網(wǎng)絡(luò)的流量，丟包情況，錯包情況，連接數(shù)等等這些基礎(chǔ)設(shè)施的核心指標(biāo)進(jìn)行監(jiān)控。
系統(tǒng)層監(jiān)控：涵蓋了物理機，虛擬機，操作系統(tǒng)這些都是屬于系統(tǒng)級別監(jiān)控的方面，對幾個核心指標(biāo)監(jiān)控，如 CPU 使用率，內(nèi)存占用率，磁盤 IO 和網(wǎng)絡(luò)帶寬情況。
應(yīng)用層監(jiān)控：例如對 URL 訪問的性能，訪問的調(diào)用數(shù)，訪問的延遲，還有對服務(wù)提供性能進(jìn)行監(jiān)控，服務(wù)的錯誤率。
對 SQL 也需要進(jìn)行監(jiān)控，查看是否有慢 SQL，對于 Cache 來說，需要監(jiān)控緩存的命中率和性能，每個服務(wù)的響應(yīng)時間和 QPS 等等。
業(yè)務(wù)監(jiān)控：比方說一個電商網(wǎng)站，需要關(guān)注它的用戶登錄情況，注冊情況，下單情況，支付情況。
這些直接影響到實際觸發(fā)的業(yè)務(wù)交易情況，這個監(jiān)控可以提供給運營和公司高管他們需要關(guān)注的數(shù)據(jù)，直接可能對公司戰(zhàn)略產(chǎn)生影響。
端用戶監(jiān)控：用戶通過瀏覽器，客戶端打開連到到我們的服務(wù)，那么在用戶端用戶的體驗是怎么樣，用戶端的性能是怎么樣，有沒有產(chǎn)生錯誤，這些信息也是需要進(jìn)行監(jiān)控并記錄下來。
如果沒有監(jiān)控，有可能用戶因為某些原因出錯或者性能問題造成體驗非常的差，而我們并沒有感知。
這里面包括了，監(jiān)控用戶端的使用性能，返回碼，在哪些城市地區(qū)他們的使用情況是怎么樣，還有運營商的情況，包括電信，聯(lián)通用戶的連接情況。
我們需要進(jìn)一步去知道是否有哪些渠道哪些用戶接入的時候存在著問題，包括我們還需要知道客戶端使用的操作系統(tǒng)瀏覽器的版本。
總結(jié)
出了那么多張牌，出牌只是術(shù)，真正的道還是得靜下心來看看整個服務(wù)高可用的本質(zhì)是什么。
隨著微服務(wù)架構(gòu)的相互調(diào)用越來越復(fù)雜，環(huán)節(jié)只會越來越多，只有建立清晰的架構(gòu)和層次才能理清楚每個環(huán)節(jié)高可用的保障，保持簡單。
從手段看高可用
主要使用的技術(shù)手段是服務(wù)和數(shù)據(jù)的冗余備份和失效轉(zhuǎn)移，一組服務(wù)或一組數(shù)據(jù)都能在多節(jié)點上，之間相互備份。
當(dāng)一臺機器宕機或出現(xiàn)問題的時候，可以從當(dāng)前的服務(wù)切換到其他可用的服務(wù)，不影響系統(tǒng)的可用性，也不會導(dǎo)致數(shù)據(jù)丟失。
從架構(gòu)看高可用
保持簡單的架構(gòu)，目前多數(shù)網(wǎng)站采用的是比較經(jīng)典的分層架構(gòu)，應(yīng)用層，服務(wù)層，數(shù)據(jù)層。
應(yīng)用層是處理一些業(yè)務(wù)邏輯，服務(wù)層提供一些數(shù)據(jù)和業(yè)務(wù)緊密相關(guān)服務(wù)，數(shù)據(jù)層負(fù)責(zé)對數(shù)據(jù)進(jìn)行讀寫。
簡單的架構(gòu)可以使應(yīng)用層，服務(wù)層可以保持無狀態(tài)化進(jìn)行水平擴展，這個屬于計算高可用。
相比計算高可用，在數(shù)據(jù)層思考的高可用則屬于數(shù)據(jù)高可用，數(shù)據(jù)高可用相比計算高可用需要考慮到數(shù)據(jù)的一致性問題會更加的復(fù)雜。
這個時候 CAP 理論在里面會發(fā)揮關(guān)鍵的作用，究竟是選擇 AP 或 CP，這個得根據(jù)業(yè)務(wù)去選擇模型。
從硬件看高可用
首先得確認(rèn)硬件總是可能壞的，網(wǎng)絡(luò)總是不穩(wěn)定的。解決它的方法也是一個服務(wù)器不夠就來多幾個，一個機柜不夠就來幾個，一個機房不夠就來幾個。
從軟件看高可用
軟件的開發(fā)不嚴(yán)謹(jǐn)，發(fā)布不規(guī)范也是導(dǎo)致各種不可用出現(xiàn)，通過控制軟件開發(fā)過程質(zhì)量監(jiān)控，通過測試，預(yù)發(fā)布，灰度發(fā)布等手段也是減少不可用的措施。
從治理看高可用
一個系統(tǒng)在線上跑的好好的，但我們也不能確保它在下一秒會不會出現(xiàn)不可用狀態(tài)。
將服務(wù)規(guī)范化，事前做好服務(wù)分割，做好服務(wù)監(jiān)控，預(yù)判不可用的出現(xiàn)，在不可用出現(xiàn)之前發(fā)現(xiàn)問題，解決問題。
【注：文章部分內(nèi)容參考 李云華《從 0 開始學(xué)架構(gòu)》楊波老師《微服務(wù)》】
作者：陳于喆
簡介：十余年的開發(fā)和架構(gòu)經(jīng)驗，國內(nèi)較早一批微服務(wù)開發(fā)實施者。曾任職國內(nèi)互聯(lián)網(wǎng)公司網(wǎng)易和唯品會高級研發(fā)工程師，后在創(chuàng)業(yè)公司擔(dān)任技術(shù)總監(jiān)/架構(gòu)師，目前在洋蔥集團任職技術(shù)研發(fā)副總監(jiān)。
【51CTO原創(chuàng)稿件，合作站點轉(zhuǎn)載請注明原文作者和出處為51CTO.com】
