如何做高可用的架構設計

定義目標

既然我們的目標是做到高可用,那么我們就有必要先明確清楚高可用的含義,并通過拆解目標,讓目標可以被量化。按照我的理解,可以將目標按照以下三條進行拆解:

1. 保持業(yè)務高穩(wěn)定性

系統(tǒng)穩(wěn)定性是高可用的根本目的,通俗的說,系統(tǒng)能持續(xù)可用,不會無故宕機,在高壓下仍然能正常工作。

2. 支持快速定位故障

從實際工程的角度看,不出故障的服務是不存在的,所以出了故障要能夠快速發(fā)現(xiàn)和定位,在外部用戶發(fā)現(xiàn)前,通過報警機制,能準確定位故障原因,幫助工程師盡快處理問題,防止進一步影響業(yè)務。

3. 支持快速恢復業(yè)務

這一點需要多說兩句,有關“恢復業(yè)務”和“解決問題”之間的區(qū)別,這兩個詞也正好說明了線上出現(xiàn)故障后,我們解決問題的兩種不同思路。簡單的說,“恢復業(yè)務”的意思是線上故障是什么原因可以先暫時放在一邊,我們先找到快速的臨時方案,讓業(yè)務跑起來。很多同學在處理生產故障的時候有一個思維慣性:先努力找到問題的起因,然后改代碼解決問題,測試,發(fā)布上線,最后業(yè)務功能才能正常工作。實際上,一個流程走下來,時間成本是很高的,業(yè)務因為本次故障受到較大的影響。比如說某臺機器上的服務響應很慢,導致請求超時,可能的原因有:網(wǎng)絡帶寬出現(xiàn)問題、機器磁盤有問題、機器的CPU或者Memory不夠用了、應用程序有死循環(huán)、jvm垃圾回收時間變長......要在短短幾分鐘內排查這么多可能的原因是很難的,但我們不知道真正的原因也可以恢復業(yè)務,比如說最簡單的方法就是直接把這臺機器立刻下線,讓流量分配到其它的機器或者新添加的機器上。

現(xiàn)在我們有了這三條分拆后的目標,那么接下來的架構方案就會圍繞著這三個目標來執(zhí)行。

服務分級 + 服務降級

服務分級:根據(jù)業(yè)務的需求,將服務進行分類,劃分核心服務和普通服務,核心服務與普通服務不會相互影響,服務背后的資源,緩存,數(shù)據(jù)庫,MQ相互分離。服務分級,對應于我們的子目標1。

這里有兩個關鍵點:

1. 抽取核心服務,例如我們互金業(yè)務中,用戶,訂單,支付這三個服務是核心業(yè)務,消息推送、營銷券積分等是普通服務,核心服務的穩(wěn)定與否也關乎業(yè)務的KPI。核心服務是客戶必須要使用的,核心服務一旦有問題,客戶就不能購買產品了;而普通服務即使有問題,暫時也不會對交易產生影響。從另外一個角度看,普通服務的代碼在我們日常的工作中反而變動頻繁。因此,優(yōu)先保證核心服務正常使用,是我們首要目標。

2. 不同級別的服務資源分離,包括服務器, 緩存,MQ, DB等建議都分離出來,因為只要不同服務共享資源,就有可能因為普通服務影響核心服務。舉個最簡單的例子,如果服務間共用一套redis,那么如果大量的消息請求占用了redis的連接數(shù),那么核心服務的質量就會因此受到很大的影響。

服務降級:當出現(xiàn)故障的時候,可以將普通服務直接降級,保護核心服務不受影響。服務降級,對應于我們的子目標3。

拆分為核心服務和普通服務后,在很多業(yè)務場景下,服務間是相互調用的,這就存在服務之間可能是相互影響的。例如,我們在推送消息(普通服務)之前,需要查詢用戶的信息(核心服務),大量消息下發(fā),就會給核心業(yè)務系統(tǒng)產生較大的壓力。這種情況下我們可以通過將非核心服務停掉,以保證核心服務不受影響。

另外,在做服務降級的時候,最佳的方式,是通過修改動態(tài)配置來執(zhí)行。而不是靠手工到線上修改靜態(tài)配置或者發(fā)布新版本的方式來完成,因為容易出錯,而且效率還不高。所以,這里我比較推薦類似阿里diamond的服務, 接入diamond后,通過diamond后臺,修改配置后,groovy腳本直接就將最新的配置同步到服務中,甚至都不要重啟服務就完成了降級操作。

建立分層監(jiān)控

建立監(jiān)控分層的目的對應于我們的子目標2,就是將故障分析和定位時涉及的所有的相關信息都要監(jiān)控起來,共分為5層,具體各層和含義如下:

網(wǎng)絡層

分析網(wǎng)絡出入的情況,比方說有大量的外部請求,導致外網(wǎng)網(wǎng)卡的帶寬被占滿,需要立刻分析是否是正常流量,如果是活動帶來高頻訪問,那么需要做帶寬升級,如果是外部攻擊,那么需要考慮做流量清洗等防護操作。

接口層

收集對外暴露的接口的訪問情況,包括接口執(zhí)行時間、返回狀態(tài)碼、調用次數(shù)等,我們需要時刻關注我們訪問次數(shù)最多的API接口,根據(jù)接口的訪問情況,決定了是否需要服務擴容,并判斷是否有外部的不正常訪問,機刷等。如果存在某些接口有大量的錯誤碼返回,我們需要第一時間查明這些接口訪問失敗的原因。

業(yè)務層

收集和分析核心業(yè)務和普通服務的運行情況和相互調用情況,比方說,如果某個服務產生了大量的Exceptions或者dubbo服務調用超時。

中間件層

中間件層指服務依賴的各類中間件,例如容器、緩存、消息隊列。不同的中間件關注不一樣的信息,例如數(shù)據(jù)庫Redis監(jiān)控指標包括連接數(shù)、請求數(shù), rdb&aof的執(zhí)行情況, IO的頻率等,緩存命中率等。

系統(tǒng)層

系統(tǒng)層指操作系統(tǒng)狀態(tài)、收集的信息包括cpu使用率、內存使用率、網(wǎng)卡流量、連接數(shù)等。

總結

歡迎工作一到十年的Java工程師朋友們加入Java進階高級架構裙:858327216

本群提供免費的學習指導 架構資料 以及免費的解答

不懂得問題都可以在本群提出來 之后還會有職業(yè)生涯規(guī)劃以及面試指導

將實現(xiàn)高可用架構拆分為3個子目標,針對這3個子目標提出了三個優(yōu)化思路:服務分級 + 服務降級+分層監(jiān)控。圍繞這三塊優(yōu)化的方向,層層推進,最終讓系統(tǒng)的技術架構得到質的提升。未來,我會針對里面的每一點,進一步展開討論一下里面的細節(jié),除此之外,還會討論一些本文還未涉及到的內容,例如DNS的優(yōu)化,異地多活等等,歡迎大家一起討論。

?著作權歸作者所有,轉載或內容合作請聯(lián)系作者
【社區(qū)內容提示】社區(qū)部分內容疑似由AI輔助生成,瀏覽時請結合常識與多方信息審慎甄別。
平臺聲明:文章內容(如有圖片或視頻亦包括在內)由作者上傳并發(fā)布,文章內容僅代表作者本人觀點,簡書系信息發(fā)布平臺,僅提供信息存儲服務。

相關閱讀更多精彩內容

友情鏈接更多精彩內容