架構設計 | 分布式體系下，服務分層監控策略

2020-09-19 西行妖

一、分布式故障

分布式系統的架構，業務開發，這些在良好的思路和設計文檔規範之下，是相對來說好處理的，這裡的相對是指比較分布式架構下生產環境的突然故障。

在實際的開發中，有這樣一個很妖嬈的情況：越是核心複雜的業務，越是擔心出問題，越容易出問題。

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

越是複雜的系統，越是經驗豐富的開發或者運維，對監控系統就越是有執念，尤其是全鏈路的監控，底層，網絡，中間件，服務鏈路，日誌觀察預警等，用來快速定位問題，省時省心。

二、全鏈路監控

1、監控層次

在分布式系統中，需要監控的體系和層次極其複雜，通常整體上劃分為三個層次：應用服務，軟體服務，硬體服務。

通常情況，運維管理硬體服務，開發管理應用和軟體服務。

2、應用服務

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

請求流量

任何服務，高並發的流量都會暴露各種服務問題，尤其核心接口的流量更是監控的重點。

服務鏈路

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

日誌體系

核心接口日誌記錄也是必備的功能，通常情況下基於日誌體系的分析結果，可以明確係統的異常點，重點優化。

3、軟體服務

為了解決分布式系統的各種複雜業務場景，通常會引入各種中間軟體來做支撐，例如必備的資料庫，緩存，消息MQ等，通常這些中間件都會有自帶的監控管理埠。

資料庫：較多使用Druid監控分析；

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

Redis緩存：提供命令獲取相關監控數據；

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

4、硬體服務

硬體層面，運維最關注的三大核心內容：CPU、內存、網絡。底層硬體資源爆發的故障，來自上層的應用服務或者中間件服務觸發的可能性偏高。

硬體層面的監控有許多成熟的框架，例如zabbix，grafana等，當然這些組件功能很豐富，不僅僅在硬體層應用。

5、雪崩效應

有些故障導致大面積服務癱瘓，也稱為雪崩效應，可能故障源沒有快速處理，也沒有熔斷機制，導致整個服務鏈路全部垮掉，這是常見的問題，所以在處理故障時，要學會基於全棧監控信息，全局關聯分析核心故障點，快速切斷單點服務的故障，保證整個系統的可用性。

三、注意事項

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

1、選擇性

不是所有服務的所有環境，和所有接口都需要監控，通常都是監控核心鏈路，核心中間件，和服務所在環境。

例如：交易鏈路，交易庫，和部署的環境；或者大客戶高並發業務，一旦出問題需要及時響應，立即處理。說的直接點，帶來收益的服務是需要重點關注的。

非關鍵服務即使出現問題，是有緩衝時間的，所以不需要花費精力添加監控，在做監控系統的時候存在這樣一句話：簡單的鏈路添加監控，複雜了容易出錯；複雜鏈路添加監控，更複雜更容易出錯，然而這樣卻是為了更好的解決故障。

2、獨立性

監控系統的本身發生故障，不能影響正常業務流程，即使在一定情況下沒有監控信息，也不能因為監控服務影響正常業務服務。

3、整體性

聚合的監控系統可以觀察監控鏈路的全局狀態，這樣可以快速定位故障坐標，可以關聯性分析問題原因。

4、預警性

例如CPU突然升高，某個中間件服務突然停止，內存佔用過高，這些可以基於監控系統做預警通知，然後郵件或者消息通知到相關負責人，達到快速響應的目的，這個場景大部分開發都熟悉，且有心理陰影。

四、原始碼地址

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

來自：https://www.cnblogs.com/cicada-smile/p/13683840.html

相關焦點

  • 編程體系結構：分布式系統架構
    它利用SpringBoot的開發便利性巧妙地簡化了分布式系統基礎設施的開發，如服務發現註冊、配置中心、消息總線、負載均衡、斷路器、數據監控等，都可以用SpringBoot的開發風格做到一鍵啟動和部署。服務網關：在整個架構體系上也是一個服務，作為請求的唯一入口，與外觀模式十分類似，在網關層處理所有的非業務功能，為客戶端提供定製的API。常用組件Zuul、Tyk、Kong。
  • 分布式架構知識體系必讀
    計算機以集群的方式存在，按照分布式理論的指導構建出龐大複雜的應用服務，也已經深入人心。本文力求從分布式基礎理論，架構設計模式，工程應用，部署運維，業界方案這幾大方面，介紹基於MSA(微服務架構)的分布式的知識體系大綱。從而對SOA到MSA進化有個立體的認識，從概念上和工具應用上更進一步了解微服務分布式的本質，身臨其境的感受如何搭建全套微服務架構的過程。
  • 架構設計向：分布式服務，庫表拆分模式詳解
    2、隔離思想分布式的架構體系中，涉及一個根本思想邏輯：隔離；服務和資料庫根據業務拆分，進而隔離開來，整個架構中某個服務掛掉，不會影響其他的服務繼續執行。例如上述1中：如果物流服務掛掉，影響的是用戶無法實時追蹤物流狀態，但是不會影響訂單的持續產生。
  • 什麼是分布式系統！以及分布式系統架構的優缺點
    現在的架構很多，各種各樣的，如高並發架構、異地多活架構、容器化架構、微服務架構、高可用架構、彈性化架構等，還有和這些架構相關的管理型的技術方法，如 DevOps、應用監控、自動化運維、SOA 服務治理、去 IOE 等等，還有很多。　　那什麼是分布式系統?海威恆泰分布式系統是支持分布式處理的軟體系統，是由通信網絡互聯的多處理機體系結構上執行任務的系統。
  • 架構設計：分布式事務概述、服務以及庫表拆分模式詳解
    2、隔離思想分布式的架構體系中，涉及一個根本思想邏輯：隔離；服務和資料庫根據業務拆分，進而隔離開來，整個架構中某個服務掛掉，不會影響其他的服務繼續執行。不管是基於什麼策略拆分隔離，首先都必須面對資料庫設計的問題。
  • 微服務架構：介紹、分布式集群、架構四要素、設計模式、架構說明
    分布式與集群分布式分布式就是把一個系統拆分成多個服務節點，每個節點部署在不同的伺服器上，可以理解為串聯模式（多個電池串聯起來電壓增加電池容量不變）先分布式：例如12306，會把分成登錄、查票、訂單、支付等多個服務。
  • 工行「去O」資料庫選型與分布式架構設計
    基於MySQL選型，還應考慮一系列的分布式架構技術棧，包括分布式服務、分布式事務框架、分布式批量框架、分布式緩存、交易數據核對及補償、分布式消息、配置中心、開發及運維管理。並且實現了多種高可用策略配置，包括自動、人工一鍵式切換。為什麼要有自動化和人工的兩種切換方式?這裡我要解釋下，一種新的事務上線之前，都會面臨一些挑戰和懷疑的，都是一個循序漸進的過程，特別是是在金融行業，自動真的好麼？萬一搞錯了怎麼辦？決策因素和模型是否設計正確？設計正確了是否編碼正確？
  • Github標星67.9k的微服務架構以及架構設計模式筆記我粉了
    設計原則之分層架構設計原則之統一通信協議設計原則之單一職責設計原則之服務拆分設計原則之前後端分離設計原則之版本控制設計原則之圍繞業務構建設計原則之並發流量控制設計原則之CAP設計原則之EDA事件驅動、負載均衡、容錯、分布式配置、網關和消息總線，能夠完成開發層面的微服務架構。
  • 分布式架構知識梳理
    計算機以集群的方式存在，按照分布式理論的指導構建出龐大複雜的應用服務，也已經深入人心。本文力求從分布式基礎理論，架構設計模式，工程應用，部署運維，業界方案這幾大方面，介紹基於MSA(微服務架構)的分布式的知識體系大綱。從而對SOA到MSA進化有個立體的認識，從概念上和工具應用上更近一步了解微服務分布式的本質，身臨其境的感受如何搭建全套微服務架構的過程。
  • 民生銀行大數據體系架構設計與演進
    ： 　　銀行有很多面向客戶的數據，數據積累非常快也非常多，以流水數據為例，為了保證系統服務質量，通常是縮短可查詢的周期，依託大數據的海量數據存儲能力，基於分布式體系構建了歷史數據管理平臺來滿足業務場景中海量數據的存儲和查詢服務需求。
  • CPS概念下基於事件觸發且考慮通信丟包及擾動的微網分層控制策略
    在考慮通信丟包和擾動的情況下，為了提高微網中各分布式電源輸出電壓和頻率的控制效果，提出了一種基於事件觸發的分層控制策略，該控制策略的結構分為網絡層和物理層。因此，通常需要改進下垂控制或者添加二次控制而形成分層控制來校正頻率和電壓。本文主要研究二次控制。傳統的二次控制採用基於中央控制器的集中式控制結構，需要收集每個DER的全部信息，然後向每個DER發送控制指令。通信網絡複雜，通信量巨大，降低了系統的穩定性。近些年來，分布式協調控制策略被廣泛應用到微電網的二次控制中。
  • 領域驅動分層架構與對象模型
    領域驅動分層架構：如果採用對象範式，那麼，分層架構每一層的對象模型應該如何設計呢？由於分層架構屬於解決方案域中的設計方案，故而邏輯分層中的對象模型對應於設計模型。其中，位於應用層和領域層中對象模型表達了領域知識，屬於領域設計模型中的一部分。對於基礎設施層，它們的對象模型又該怎樣與領域設計模型中的對象協作呢？
  • Apache Dubbo分布式服務架構全鏈路追蹤
    在開發或線上運維基本上會遇到如下情況:A系統開發同學:我查了日誌,客戶端的請求過程一共用了X秒,請求是從幾點幾分幾秒發起的,另外一個服務耗時比較長 XXX你們查下服務端的日誌呢B系統開發人員：我這邊是幾點幾分幾秒收到的請求，我們系統一共花了X秒多一些，其中調用C系統花了將近秒，XXX你們查下服務端的日誌呢C系統開發人員
  • 阿里P8技術官總結698頁：分布式服務架構 原理+設計+實戰
    本文以高可用服務架構為主題，側重於講解高可用架構設計的核心要點:可伸縮和可擴展，從應用層、資料庫、緩存、消息隊列、大數據查詢系統、分布式定時任務調度系統、微服務等層面詳細講解如何設計可伸縮、可擴展的框架，並給出在各個領域解決特定問題的方法論和實踐總結。
  • 什麼才是真正的架構設計？
    技術架構技術架構：確定組成應用系統的實際運行組件（lvs，nginx，tomcat，php-fpm等），這些運行組件之間的關係，以及部署到硬體的策略。技術架構主要考慮系統的非功能性特徵，對系統的高可用、高性能、擴展、安全、伸縮性、簡潔等做系統級的把握。系統架構的設計要求架構師具備軟體和硬體的功能和性能的過硬知識，這也是架構設計工作中最為困難的工作。
  • ...模塊化、集中式、分布式、服務化、面向服務的架構、微服務架構
    為了解決上面這些問題，我們一般採用拆分、解耦、分層、獨立等方式來解決。有了服務化架構，我們就可以在很大程度上解決這些問題。 　　服務化是一種粗粒度、鬆耦合的以服務為中心的架構，服務之間通過定義明確的協議和接口進行通信。 　　這裡說到的「服務」，本質上來說，就是指「RPC」。
  • Golang面向包的設計和架構分層建議
    這樣的項目架構分層只是一種通用的模式，他不會給go的面向包的設計強加什麼東西。面向包設計的理念讓開發者在一個 go 項目中確定包的組織和必須要遵守的設計準則。它定義了一個 go 項目應該是什麼樣的及怎麼架構和分層一個 go 項目。它最終的目的是為了提高項目的可讀性、代碼整潔性和可交流性，便於團隊成員溝通。
  • 一文詳解:如何設計出高可用的分布式架構?
    本文作者將與大家分享目前主流的分布式架構、分布式架構中常見理論以及如何才能設計出高可用的分布式架構。SOA 架構解析SOA 全稱是：Service Oriented Architecture，中文釋義為 「面向服務的架構」。它是一種設計理念，其中包含多個服務，服務之間通過相互依賴最終提供一系列完整的功能。各個服務通常以獨立的形式部署運行，服務之間通過網絡進行調用，架構圖如下：
  • Istio分層架構？80%的人有誤解
    Istio是ServiceMesh的產品化落地：它幫助微服務之間建立連接，幫助研發團隊更好的管理與監控微服務，並使得系統架構更加安全 它幫助微服務分層解耦（3）故障恢復(failure recovery)（4）服務度量(metrics)（5）服務監控(monitoring)（6）
  • 簡析分布式存儲的架構體系
    而作為區塊鏈領域最有可能落地的分布式存儲的概念，在5G海量數據存儲需求的「逼迫」下，逐漸成為各大企業追逐的「未來」。前文我們詳細的解析過「什麼是分布式存儲」，我們來簡單回顧下：分布式存儲是將數據分散存儲在多臺獨立的設備上。