本篇的題目其實比較大，所以在寫的時候，我其實是有些“惶恐”的，怕這篇完成後有標題檔的嫌疑。不過為了將自己過去多年的經歷和最近1年改造架構的想法，做一個階段性總結，還是有必要好好寫一寫的，所以如果寫得不好，大家多包涵，歡迎大家補充。

定義目標

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

1. 保持業務高穩定性

系統穩定性是高可用的根本目的，通俗的說，系統能持續可用，不會無故宕機，在高壓下仍然能正常工作。

2. 支援快速定位故障

從實際工程的角度看，不出故障的服務是不存在的，所以出了故障要能夠快速發現和定位，在外部使用者發現前，通過報警機制，能準確定位故障原因，幫助工程師儘快處理問題，防止進一步影響業務。 

3. 支援快速恢復業務

這一點需要多說兩句，有關“恢復業務”和“解決問題”之間的區別，這兩個詞也正好說明了線上出現故障後，我們解決問題的兩種不同思路。簡單的說，“恢復業務”的意思是線上故障是什麼原因可以先暫時放在一邊，我們先找到快速的臨時方案，讓業務跑起來。很多同學在處理生產故障的時候有一個思維慣性：先努力找到問題的起因，然後改程式碼解決問題，測試，釋出上線，最後業務功能才能正常工作。實際上，一個流程走下來，時間成本是很高的，業務因為本次故障受到較大的影響。比如說某臺機器上的服務響應很慢，導致請求超時，可能的原因有：網路頻寬出現問題、機器磁碟有問題、機器的CPU或者Memory不夠用了、應用程式有死迴圈、jvm垃圾回收時間變長......要在短短几分鐘內排查這麼多可能的原因是很難的，但我們不知道真正的原因也可以恢復業務，比如說最簡單的方法就是直接把這臺機器立刻下線，讓流量分配到其它的機器或者新新增的機器上。

現在我們有了這三條分拆後的目標，那麼接下來的架構方案就會圍繞著這三個目標來執行。

服務分級 + 服務降級

服務分級：根據業務的需求，將服務進行分類，劃分核心服務和普通服務，核心服務與普通服務不會相互影響，服務背後的資源，快取，資料庫，MQ相互分離。服務分級，對應於我們的子目標1。

這裡有兩個關鍵點：

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

2. 不同級別的服務資源分離，包括伺服器, 快取,MQ, DB等建議都分離出來，因為只要不同服務共享資源，就有可能因為普通服務影響核心服務。舉個最簡單的例子，如果服務間共用一套redis，那麼如果大量的訊息請求佔用了redis的連線數，那麼核心服務的質量就會因此受到很大的影響。

服務降級：當出現故障的時候，可以將普通服務直接降級，保護核心服務不受影響。服務降級，對應於我們的子目標3。

拆分為核心服務和普通服務後，在很多業務場景下，服務間是相互呼叫的，這就存在服務之間可能是相互影響的。例如，我們在推送訊息（普通服務）之前，需要查詢使用者的資訊（核心服務），大量訊息下發，就會給核心業務系統產生較大的壓力。這種情況下我們可以通過將非核心服務停掉，以保證核心服務不受影響。

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

建立分層監控

建立監控分層的目的對應於我們的子目標2，就是將故障分析和定位時涉及的所有的相關資訊都要監控起來，共分為5層，具體各層和含義如下：

網路層

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

介面層

收集對外暴露的介面的訪問情況，包括介面執行時間、返回狀態碼、呼叫次數等，我們需要時刻關注我們訪問次數最多的API介面，根據介面的訪問情況，決定了是否需要服務擴容，並判斷是否有外部的不正常訪問，機刷等。如果存在某些介面有大量的錯誤碼返回，我們需要第一時間查明這些介面訪問失敗的原因。

業務層

收集和分析核心業務和普通服務的執行情況和相互呼叫情況，比方說，如果某個服務產生了大量的Exceptions或者dubbo服務呼叫超時。

中介軟體層

中介軟體層指服務依賴的各類中介軟體，例如容器、快取、訊息佇列。不同的中介軟體關注不一樣的資訊，例如資料庫Redis監控指標包括連線數、請求數, rdb&aof的執行情況, IO的頻率等，快取命中率等。

系統層

系統層指作業系統狀態、收集的資訊包括cpu使用率、記憶體使用率、網絡卡流量、連線數等。 

總結

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