本文源碼：GitHub·點這里 || GitEE·點這里

一、分布式故障

分布式系統(tǒng)的架構(gòu)，業(yè)務(wù)開發(fā)，這些在良好的思路和設(shè)計文檔規(guī)范之下，是相對來說好處理的，這里的相對是指比較分布式架構(gòu)下生產(chǎn)環(huán)境的突然故障。

在實際的開發(fā)中，有這樣一個很妖嬈的情況：越是核心復(fù)雜的業(yè)務(wù)，越是擔(dān)心出問題，越容易出問題。

所以當(dāng)核心服務(wù)的鏈路出現(xiàn)故障時，如何快速定位問題就是一件很頭疼的事情，尤其是一些特殊情況下，問題很模糊很難復(fù)現(xiàn)，外加客戶或者領(lǐng)導(dǎo)催促，這種場景心里陰影是大部分開發(fā)都有的。更有甚者，可能問題發(fā)生的切入點的開發(fā)是某人負(fù)責(zé)的，實際問題是發(fā)生在請求鏈路的其他服務(wù)上，這種情況遇多了，甩鍋水平會直線上升。

越是復(fù)雜的系統(tǒng)，越是經(jīng)驗豐富的開發(fā)或者運維，對監(jiān)控系統(tǒng)就越是有執(zhí)念，尤其是全鏈路的監(jiān)控，底層，網(wǎng)絡(luò)，中間件，服務(wù)鏈路，日志觀察預(yù)警等，用來快速定位問題，省時省心。

二、全鏈路監(jiān)控

1、監(jiān)控層次

在分布式系統(tǒng)中，需要監(jiān)控的體系和層次極其復(fù)雜，通常整體上劃分為三個層次：應(yīng)用服務(wù)，軟件服務(wù)，硬件服務(wù)。

通常情況，運維管理硬件服務(wù)，開發(fā)管理應(yīng)用和軟件服務(wù)。

2、應(yīng)用服務(wù)

應(yīng)用層為開發(fā)的業(yè)務(wù)邏輯服務(wù)，也是最容易突發(fā)問題的一個層面，當(dāng)在一家公司待久了，因為開發(fā)過多個業(yè)務(wù)線，就會感覺自己不是開發(fā)，是個打雜的，每天都要分出大量時間處理各種問題。應(yīng)用層監(jiān)控涉及下面幾個核心模塊：

請求流量

任何服務(wù)，高并發(fā)的流量都會暴露各種服務(wù)問題，尤其核心接口的流量更是監(jiān)控的重點。

服務(wù)鏈路

一次請求發(fā)生問題，快速判斷問題所在的服務(wù)，或者哪些服務(wù)之間，這對快速處理問題是至關(guān)重要的。

日志體系

核心接口日志記錄也是必備的功能，通常情況下基于日志體系的分析結(jié)果，可以明確系統(tǒng)的異常點，重點優(yōu)化。

3、軟件服務(wù)

為了解決分布式系統(tǒng)的各種復(fù)雜業(yè)務(wù)場景，通常會引入各種中間軟件來做支撐，例如必備的數(shù)據(jù)庫，緩存，消息MQ等，通常這些中間件都會有自帶的監(jiān)控管理端口。

數(shù)據(jù)庫：較多使用Druid監(jiān)控分析；

消息隊列：常用RocketMQ和控制臺；

Redis緩存：提供命令獲取相關(guān)監(jiān)控數(shù)據(jù)；

還有一些公司甚至直接在中間件層開發(fā)一套管理運維和監(jiān)控的聚合平臺，這樣更容易從整體上分析問題。

4、硬件服務(wù)

硬件層面，運維最關(guān)注的三大核心內(nèi)容：CPU、內(nèi)存、網(wǎng)絡(luò)。底層硬件資源爆發(fā)的故障，來自上層的應(yīng)用服務(wù)或者中間件服務(wù)觸發(fā)的可能性偏高。

硬件層面的監(jiān)控有許多成熟的框架，例如zabbix，grafana等，當(dāng)然這些組件功能很豐富，不僅僅在硬件層應(yīng)用。

5、雪崩效應(yīng)

有些故障導(dǎo)致大面積服務(wù)癱瘓，也稱為雪崩效應(yīng)，可能故障源沒有快速處理，也沒有熔斷機(jī)制，導(dǎo)致整個服務(wù)鏈路全部垮掉，這是常見的問題，所以在處理故障時，要學(xué)會基于全棧監(jiān)控信息，全局關(guān)聯(lián)分析核心故障點，快速切斷單點服務(wù)的故障，保證整個系統(tǒng)的可用性。

三、注意事項

監(jiān)控系統(tǒng)雖然作用很大，但是實際搭建的時候難度還是很大，需要有較好的意識，不是業(yè)務(wù)開發(fā)那種感覺，方方面面需求都需要處理，做監(jiān)控系統(tǒng)的基本策略如下。

1、選擇性

不是所有服務(wù)的所有環(huán)境，和所有接口都需要監(jiān)控，通常都是監(jiān)控核心鏈路，核心中間件，和服務(wù)所在環(huán)境。

例如：交易鏈路，交易庫，和部署的環(huán)境；或者大客戶高并發(fā)業(yè)務(wù)，一旦出問題需要及時響應(yīng)，立即處理。說的直接點，帶來收益的服務(wù)是需要重點關(guān)注的。

非關(guān)鍵服務(wù)即使出現(xiàn)問題，是有緩沖時間的，所以不需要花費精力添加監(jiān)控，在做監(jiān)控系統(tǒng)的時候存在這樣一句話：簡單的鏈路添加監(jiān)控，復(fù)雜了容易出錯；復(fù)雜鏈路添加監(jiān)控，更復(fù)雜更容易出錯，然而這樣卻是為了更好的解決故障。

2、獨立性

監(jiān)控系統(tǒng)的本身發(fā)生故障，不能影響正常業(yè)務(wù)流程，即使在一定情況下沒有監(jiān)控信息，也不能因為監(jiān)控服務(wù)影響正常業(yè)務(wù)服務(wù)。

3、整體性

聚合的監(jiān)控系統(tǒng)可以觀察監(jiān)控鏈路的全局狀態(tài)，這樣可以快速定位故障坐標(biāo)，可以關(guān)聯(lián)性分析問題原因。

4、預(yù)警性

例如CPU突然升高，某個中間件服務(wù)突然停止，內(nèi)存占用過高，這些可以基于監(jiān)控系統(tǒng)做預(yù)警通知，然后郵件或者消息通知到相關(guān)負(fù)責(zé)人，達(dá)到快速響應(yīng)的目的，這個場景大部分開發(fā)都熟悉，且有心理陰影。

四、源代碼地址

GitHub·地址 https://github.com/cicadasmile/data-manage-parent GitEE·地址 https://gitee.com/cicadasmile/data-manage-parent

推薦閱讀：架構(gòu)設(shè)計系列

標(biāo)題

架構(gòu)設(shè)計：單服務(wù).集群.分布式，基本區(qū)別和聯(lián)系

架構(gòu)設(shè)計：分布式業(yè)務(wù)系統(tǒng)中，全局ID生成策略

架構(gòu)設(shè)計：分布式系統(tǒng)調(diào)度，Zookeeper集群化管理

架構(gòu)設(shè)計：接口冪等性原則，防重復(fù)提交Token管理

架構(gòu)設(shè)計：緩存管理模式，監(jiān)控和內(nèi)存回收策略

架構(gòu)設(shè)計：異步處理流程，多種實現(xiàn)模式詳解

架構(gòu)設(shè)計：高并發(fā)流量削峰，共享資源加鎖機(jī)制

架構(gòu)設(shè)計：分布式服務(wù)，庫表拆分模式詳解

架構(gòu)設(shè)計：分布式事務(wù)①概念簡介和基礎(chǔ)理論

架構(gòu)設(shè)計：基于電商交易流程，圖解TCC事務(wù)分段提交

架構(gòu)設(shè)計：基于消息中間件，圖解柔性事務(wù)一致性

架構(gòu)設(shè)計：基于Seata中間件，微服務(wù)模式下事務(wù)管理

總結(jié)

以上是生活随笔為你收集整理的架构设计 | 分布式体系下，服务分层监控策略的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。