作者 | 黄晓萌
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 的超大规模任务调度方案
SchedulerX 2.0 是阿里巴巴自研的一款商业化分布式任务调度平台，相对于开源任务调度系统，它有几大优势：
- 支持海量任务
- 自研轻量级分布式跑批模型
- 可视化任务编排
- 丰富的可视化
- 权限隔离
SchedulerX2.0 基础架构图
与常见方案相比，SchedulerX2.0 会将任务分布式到不同的Server调度，每次任务调度也不需要抢锁触发，和数据库无任何交互，没有性能瓶颈。
优势
除了支持超大规模能力，SchedulerX2.0还有如下优势
安全防护
- 多层次安全防护：支持 HTTPS 和 VPC 访问，同时还有阿里云的多层安全防护，防止恶意攻击。
- 多租户隔离机制：支持多地域、命名空间和应用级别的隔离。
- 权限管控：支持控制台读写的权限管理，客户端接入的鉴权。
高可用
SchedulerX2.0采用高可用架构，任务多备份机制，经历阿里集团多年双十一、容灾演练，可以做到任意一个机房挂了，任务调度都不会收到影响。
商业级报警运维
- 报警：支持邮件、钉钉、短信、电话、企业微信、飞书。支持任务失败、超时、无可用机器报警。报警内容可以直接看出任务失败的原因，以钉钉机器人为例
- 运维操作：原地重跑、重刷数据、标记成功、查看堆栈、停止任务、指定机器等
丰富的可视化
schedulerx拥有丰富的可视化能力，比如
- 用户大盘
- 查看任务历史执行记录
- 查看任务运行日志
- 查看任务运行堆栈
- 查看任务操作记录
兼容开源
Schedulerx兼容开源XXL-JOB、ElasticJob、Quartz（规划中），业务不需要改一行代码，即可以将任务托管在SchedulerX调度平台，享有企业级可视化和报警的能力。
分布式跑批
SchedulerX提供了丰富的分布式模型，可以处理各种各样的分布式业务场景。包括单机、广播、分片、MapReduce等，架构如下：
SchedulerX的MapReduce模型，简单几行代码，就可以将海量任务分布式到多台机器跑批，相对于大数据跑批来说，具有速度快、数据安全、成本低、简单易学等特点。
任务编排
SchedulerX通过工作流进行任务编排，并且提供了一个可视化的界面，操作简单，拖拖拽拽即可配置一个工作流。详细的任务状态图能一目了然看到下游任务为什么没跑，方便定位问题
可抢占的任务优先级队列
常见场景是夜间离线报表业务，比如很多报表任务是晚上1、2点开始跑，要控制应用最大并发的任务数量（否则业务扛不住），达到并发上限的任务会在队列中等待。同时要求早上9点前必须把KPI报表跑出来，可以设置KPI任务高优先级，会抢占低优先级任务优先调度。
SchedulerX支持可抢占的任务优先级队列，可以在控制台动态配置：
总结
SchedulerX 2.0在阿里巴巴集团内支撑了所有事业群的业务，经历了多次双十一的考验，当前在公有云已接入1000+家企业，在海量任务和高可用方面有充分的经验，还有企业级的报警监控和可观测能力。显然，在超大规模任务调度领域，SchedulerX 2.0已经是目前最优解决方案之一。
想了解更多分布式调度平台SchedulerX 2.0的特色，可前往：https://www.aliyun.com/aliware/schedulerx
产品控制台：
