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