如何通過任務排程實現百萬規則報警
簡介：報警是一個公司的日常需求，常見的形態除了滿足運維過程中的基礎設施監控報警（CPU/記憶體/磁碟等）之外，部分公司也會在應用指標（如 QPS、RT 等）及業務指標（如 GMV/日活 等）上有相應的報警需求。
作者 | 黃曉萌
01 問題背景
報警是一個公司的日常需求，常見的形態除了滿足運維過程中的基礎設施監控報警（CPU/記憶體/磁碟等）之外，部分公司也會在應用指標（如 QPS、RT 等）及業務指標（如 GMV/日活 等）上有相應的報警需求。
在業務發展初期，基礎設施較少，且應用形態單一，所以處理這一類需求往往會比較粗暴直接，但是隨著業務的增長，尤其發展到日活百萬甚至上億級的時候，監控指標也會呈指數級上漲，在這種情況下對於報警體系就提出了巨大的挑戰，如何解決這種體量下報警的有效性和時效性就成為了 IT 治理的重中之重。本篇文章，我們將從監控指標的體量出發，詳解各個階段報警體系中遇到的各個挑戰。
02 一次常規的報警流程示意圖
如下圖所示，一次常規意義上的報警流程，主要會包含併發檢查、齊全度檢查、資料追補、閾值判斷等核心環節。同時，為了保證報警的時效性，基本上整個流程會是一個秒級觸發的形態，具體如下：
- 併發檢查：檢查當前告警規則是不是在其他程序或者節點中執行中，避免有些告警規則檢查耗時過長，被重複執行了或被其他的任務節點搶佔執行。
- 齊全度檢查：獲取當前告警規則對應的資料來源的齊全度時間，即最新資料上報到什麼時間了。因為資料來源資料採集和上報一定會有延時的，如果資料不齊就進行檢查，很容易漏報和誤報。
- 資料查詢：從監控資料中獲取該規則的資料，一般會從收集上來的日誌服務（如：ElasticSearch 服務等）或者基礎監控指標儲存服務（如：Zabbix、Prometheus 等）中獲取。
- 資料追補：由某些報警任務設定的策略，沒有資料點的情況下怎麼處理。有補0，補滿和不補三種。如在針對業務資料跌零報警的場景，我們會更傾向於補 0 ；但是針對 CPU 平均值超 80% 的場景，我們會傾向於不補。
- 閾值判斷：根據獲取的資料和報警條件，判斷是否需要觸發報警。
- 告警：將告警資訊通過簡訊、釘釘、郵件等方式通知到配置的人，以便後續有人處理。
03 程序內排程方案
一開始的業務很少的時候，報警任務也趨於少數，這個時候一般的實現都會基於一個程序內的執行緒池執行相關的操作，架構圖如下：
04 分散式排程解決方案
如果任務數達到萬級別，尋求一個輕量的分散式的方案是我們的目標。分散式排程方案的基本思路都是通過單獨的任務排程中心來排程任務，報警後臺只管執行任務，即任務排程和任務執行隔離的思路，使得兩層都能做很好的橫向擴容來達到容量上漲的目的。業務實現上，每個報警規則會生成一個定時任務，這樣可以保證每個報警規則負載均衡地執行。開源市場有挺多產品，比如：Quartz、xxl-job、elastic-job 等。以 quartz 為例，示意圖如下：
這個架構解決了任務的分散式排程、冪等執行的問題，並且執行層可以水平擴充套件，在任務量低的情況下可以穩定執行。
可是從上面的架構圖可以看出，Quartz 的排程主要通過輪詢 DB 和通過 DB 加鎖的方式而實現，這個時候整個系統的吞吐基本上和 DB 的規格和效能息息相關。經測試，如果在任務量排程頻率 1 分鐘級別的觸發達到1萬，就會出現比較明顯的排程延時。
05 基於 SchedulerX 2.0 的超大規模任務排程方案
1、SchedulerX 2.0 優勢
SchedulerX 2.0 是阿里巴巴自研的一款商業化分散式任務排程平臺，相對於開源任務排程系統，它有幾大優勢：
- 支援海量任務
- 自研輕量級分散式跑批模型
- 視覺化任務編排
- 商業化報警
- 視覺化日誌服務
與常見方案相比，SchedulerX2.0 會將任務分散式到不同的 Server 排程，每次任務排程也不需要搶鎖觸發，和資料庫無任何互動，沒有效能瓶頸。
2、高可用能力
在分佈系統中最常見的就是高可用問題，如果 SchedulerX 2.0 的某個 Server 掛了會怎麼辦？
3、商業化報警
SchedulerX 2.0 當前支援釘釘、簡訊、郵件三種報警通道：
06 總結
SchedulerX 2.0 在阿里巴巴集團內支撐了所有事業群的業務，經歷了多次雙十一的考驗，當前在公有云已接入1000+家企業，在海量任務和高可用方面有充足的經驗。顯然，在超大規模任務排程領域，SchedulerX 2.0 已經是目前最優解決方案之一。
原文連結
本文為阿里雲原創內容，未經允許不得轉載。