簡介：報警是一個公司的日常需求，常見的形態除了滿足運維過程中的基礎設施監控報警（CPU/內存/磁盤等）之外，部分公司也會在應用指標（如 QPS、RT 等）及業務指標（如 GMV/日活 等）上有相應的報警需求。

作者 | 黃曉萌

01 問題背景

報警是一個公司的日常需求，常見的形態除了滿足運維過程中的基礎設施監控報警（CPU/內存/磁盤等）之外，部分公司也會在應用指標（如 QPS、RT 等）及業務指標（如 GMV/日活 等）上有相應的報警需求。

在業務發展初期，基礎設施較少，且應用形態單一，所以處理這一類需求往往會比較粗暴直接，但是隨著業務的增長，尤其發展到日活百萬甚至上億級的時候，監控指標也會呈指數級上漲，在這種情況下對于報警體系就提出了巨大的挑戰，如何解決這種體量下報警的有效性和時效性就成為了 IT 治理的重中之重。本篇文章，我們將從監控指標的體量出發，詳解各個階段報警體系中遇到的各個挑戰。

02 一次常規的報警流程示意圖

如下圖所示，一次常規意義上的報警流程，主要會包含并發檢查、齊全度檢查、數據追補、閾值判斷等核心環節。同時，為了保證報警的時效性，基本上整個流程會是一個秒級觸發的形態，具體如下：

其中，報警后臺任務處理系統是我們這次討論的重點，幾個核心流程的說明如下：

并發檢查：檢查當前告警規則是不是在其他進程或者節點中執行中，避免有些告警規則檢查耗時過長，被重復執行了或被其他的任務節點搶占執行。

齊全度檢查：獲取當前告警規則對應的數據源的齊全度時間，即最新數據上報到什么時間了。因為數據源數據采集和上報一定會有延時的，如果數據不齊就進行檢查，很容易漏報和誤報。

數據查詢：從監控數據中獲取該規則的數據，一般會從收集上來的日志服務（如：ElasticSearch 服務等）或者基礎監控指標存儲服務（如：Zabbix、Prometheus 等）中獲取。

數據追補：由某些報警任務設置的策略，沒有數據點的情況下怎么處理。有補0，補滿和不補三種。如在針對業務數據跌零報警的場景，我們會更傾向于補 0 ；但是針對 CPU 平均值超 80% 的場景，我們會傾向于不補。

閾值判斷：根據獲取的數據和報警條件，判斷是否需要觸發報警。

告警：將告警信息通過短信、釘釘、郵件等方式通知到配置的人，以便后續有人處理。

03 進程內調度方案

一開始的業務很少的時候，報警任務也趨于少數，這個時候一般的實現都會基于一個進程內的線程池執行相關的操作，架構圖如下：

把上圖的“后臺任務處理系統”放到一臺機器上運行，能很快速的滿足小規模的場景。但是等到業務量持續上漲的時候，一臺機器就出現了資源瓶頸，這個時候一個下意識的反應就是擴容上面的任務處理系統，讓不同的 Server 處理不同的報警規則。但是隨著報警規則在不斷增加，負載的持續上漲會引起 Server 也會重啟或者突然掛掉。于是高可用、任務冪等執行、failover 等分布式問題又是面臨的一個復雜的難題。

04 分布式調度解決方案

如果任務數達到萬級別，尋求一個輕量的分布式的方案是我們的目標。分布式調度方案的基本思路都是通過單獨的任務調度中心來調度任務，報警后臺只管執行任務，即任務調度和任務執行隔離的思路，使得兩層都能做很好的橫向擴容來達到容量上漲的目的。業務實現上，每個報警規則會生成一個定時任務，這樣可以保證每個報警規則負載均衡地執行。開源市場有挺多產品，比如：Quartz、xxl-job、elastic-job 等。以 quartz 為例，示意圖如下：

如上圖所示，quartz 的每個 Server，會加載全量的所有任務，每次任務時間到了，所有 Server 會通過數據庫搶鎖，搶到鎖的 Server 觸發該任務給報警中心。

這個架構解決了任務的分布式調度、冪等執行的問題，并且執行層可以水平擴展，在任務量低的情況下可以穩定運行。

可是從上面的架構圖可以看出，Quartz 的調度主要通過輪詢 DB 和通過 DB 加鎖的方式而實現，這個時候整個系統的吞吐基本上和 DB 的規格和性能息息相關。經測試，如果在任務量調度頻率 1 分鐘級別的觸發達到1萬，就會出現比較明顯的調度延時。

05 基于 SchedulerX 2.0 的超大規模任務調度方案

1、SchedulerX 2.0 優勢

SchedulerX 2.0 是阿里巴巴自研的一款商業化分布式任務調度平臺，相對于開源任務調度系統，它有幾大優勢：

• 支持海量任務
• 自研輕量級分布式跑批模型
• 可視化任務編排
• 商業化報警
• 可視化日志服務

SchedulerX2.0 基礎架構圖

與常見方案相比，SchedulerX2.0 會將任務分布式到不同的 Server 調度，每次任務調度也不需要搶鎖觸發，和數據庫無任何交互，沒有性能瓶頸。

2、高可用能力

在分布系統中最常見的就是高可用問題，如果 SchedulerX 2.0 的某個 Server 掛了會怎么辦？

如上圖所示，每個應用都會做三備份，通過 zk 搶鎖，一主兩備，如果某臺 Server 掛了，會進行 failover，由其他 Server 接管調度任務。

3、商業化報警

SchedulerX 2.0 當前支持釘釘、短信、郵件三種報警通道：

支持任務失敗、超時、無可用機器報警：

以釘釘告警為例，您可以實時收到報警：

06 總結

SchedulerX 2.0 在阿里巴巴集團內支撐了所有事業群的業務，經歷了多次雙十一的考驗，當前在公有云已接入1000+家企業，在海量任務和高可用方面有充足的經驗。顯然，在超大規模任務調度領域，SchedulerX 2.0 已經是目前最優解決方案之一。

原文鏈接
本文為阿里云原創內容，未經允許不得轉載。?

總結

以上是生活随笔為你收集整理的如何通过任务调度实现百万规则报警的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。