本篇內(nèi)容介紹了“怎么做web高可用的架構(gòu)設計”的有關知識，在實際案例的操作過程中，不少人都會遇到這樣的困境，接下來就讓小編帶領大家學習一下如何處理這些情況吧！希望大家仔細閱讀，能夠?qū)W有所成！
定義目標
既然我們的目標是做到高可用，那么我們就有必要先明確清楚高可用的含義，并通過拆解目標，讓目標可以被量化。按照我的理解，可以將目標按照以下三條進行拆解：
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è)務跑起來。很多同學在處理生產(chǎn)故障的時候有一個思維慣性：先努力找到問題的起因，然后改代碼解決問題，測試，發(fā)布上線，最后業(yè)務功能才能正常工作。實際上，一個流程走下來，時間成本是很高的，業(yè)務因為本次故障受到較大的影響。比如說某臺機器上的服務響應很慢，導致請求超時，可能的原因有：網(wǎng)絡帶寬出現(xiàn)問題、機器磁盤有問題、機器的CPU或者Memory不夠用了、應用程序有死循環(huán)、jvm垃圾回收時間變長......要在短短幾分鐘內(nèi)排查這么多可能的原因是很難的，但我們不知道真正的原因也可以恢復業(yè)務，比如說最簡單的方法就是直接把這臺機器立刻下線，讓流量分配到其它的機器或者新添加的機器上。
現(xiàn)在我們有了這三條分拆后的目標，那么接下來的架構(gòu)方案就會圍繞著這三個目標來執(zhí)行。
服務分級 + 服務降級
服務分級：根據(jù)業(yè)務的需求，將服務進行分類，劃分核心服務和普通服務，核心服務與普通服務不會相互影響，服務背后的資源，緩存，數(shù)據(jù)庫，MQ相互分離。服務分級，對應于我們的子目標1。
這里有兩個關鍵點：
1. 抽取核心服務，例如我們互金業(yè)務中，用戶，訂單，支付這三個服務是核心業(yè)務，消息推送、營銷券積分等是普通服務，核心服務的穩(wěn)定與否也關乎業(yè)務的KPI。核心服務是客戶必須要使用的，核心服務一旦有問題，客戶就不能購買產(chǎn)品了；而普通服務即使有問題，暫時也不會對交易產(chǎn)生影響。從另外一個角度看，普通服務的代碼在我們?nèi)粘５墓ぷ髦蟹炊儎宇l繁。因此，優(yōu)先保證核心服務正常使用，是我們首要目標。
2. 不同級別的服務資源分離，包括服務器, 緩存,MQ, DB等建議都分離出來，因為只要不同服務共享資源，就有可能因為普通服務影響核心服務。舉個最簡單的例子，如果服務間共用一套redis，那么如果大量的消息請求占用了redis的連接數(shù)，那么核心服務的質(zhì)量就會因此受到很大的影響。
服務降級：當出現(xiàn)故障的時候，可以將普通服務直接降級，保護核心服務不受影響。服務降級，對應于我們的子目標3。
拆分為核心服務和普通服務后，在很多業(yè)務場景下，服務間是相互調(diào)用的，這就存在服務之間可能是相互影響的。例如，我們在推送消息（普通服務）之前，需要查詢用戶的信息（核心服務），大量消息下發(fā)，就會給核心業(yè)務系統(tǒng)產(chǎn)生較大的壓力。這種情況下我們可以通過將非核心服務停掉，以保證核心服務不受影響。
另外，在做服務降級的時候，最佳的方式，是通過修改動態(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)碼、調(diào)用次數(shù)等，我們需要時刻關注我們訪問次數(shù)最多的API接口，根據(jù)接口的訪問情況，決定了是否需要服務擴容，并判斷是否有外部的不正常訪問，機刷等。如果存在某些接口有大量的錯誤碼返回，我們需要第一時間查明這些接口訪問失敗的原因。
業(yè)務層
收集和分析核心業(yè)務和普通服務的運行情況和相互調(diào)用情況，比方說，如果某個服務產(chǎn)生了大量的Exceptions或者dubbo服務調(diào)用超時。
中間件層
中間件層指服務依賴的各類中間件，例如容器、緩存、消息隊列。不同的中間件關注不一樣的信息，例如數(shù)據(jù)庫Redis監(jiān)控指標包括連接數(shù)、請求數(shù), rdb&aof的執(zhí)行情況, IO的頻率等，緩存命中率等。
系統(tǒng)層
系統(tǒng)層指操作系統(tǒng)狀態(tài)、收集的信息包括cpu使用率、內(nèi)存使用率、網(wǎng)卡流量、連接數(shù)等。
“怎么做web高可用的架構(gòu)設計”的內(nèi)容就介紹到這里了，感謝大家的閱讀。如果想了解更多行業(yè)相關的知識可以關注創(chuàng)新互聯(lián)-成都網(wǎng)站建設公司網(wǎng)站，小編將為大家輸出更多高質(zhì)量的實用文章！
重慶分公司
重慶分公司
