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