服务治理到底治什么，10张图告诉你答案

凌晨四点被公司的监控告警叫醒了，告警的原因是生产环境跑批任务发生故障。即刻起床处理故障，但还是花了不少时间才解决。

这次故障是一次数据校验的跑批任务，校验前面跑批任务的数据是否正确。幸运的是，之前的核心任务已经完成，并没有影响到生产上的交易系统工作。

为什么我这里提到了交易工作呢？因为交易系统是整个系统业务流量的入口，如果交易系统发生故障，那会给公司带来直接的收入损失。

今天我们聊的话题是服务治理，服务治理最终达到的结果就是系统 「7 * 24」 小时不间断服务。

1. 监控告警

公司的这次生产告警很准确，找到系统的直接维护人，并且通知到是哪个跑批任务出了故障。这次告警是通过监控跑批任务中间件的任务执行结果来触发的。

一般情况下，告警有哪些类型呢？我们看下图：

1.1 批处理效率

多数情况下批处理任务是不阻碍业务入口的，所以不需要监控。

在阻碍业务入口的情况下，批处理任务必须要监控。我举两个业务场景：

• 域名系统要通过dns信息和数据库记录来找出脏数据进行交易补偿，这期间客户查询域名信息可能是脏数据

• 银行日终跑批期间是不允许实时交易的，这个「7 * 24」小时不间断服务相违背

这些场景下批处理效率是非常重要的一个监控指标，必须配置超时阈值并进行监控。

1.2 流量监控

常用的限流的指标如下图:

流量监控我们需要注意几点：

• 不同的系统，使用的监控指标是不同的，比如redis，可以用QPS指标，对于交易系统，可以用TPS

• 通过测试和业务量的预估来配置合适的监控阈值

• 监控阈值需要考虑突发情况，比如秒杀、抢券等场景

1.3 异常监控

异常监控对于系统来说非常重要。在生产环境中很难保证程序不发生异常，配置合理的异常报警对快速定位和解决问题至关重要。比如开篇提到的跑批告警，告警信息中带着异常，让我很快就定位到了问题。

异常监控需要注意下面几个方面：

• 客户端read timeout,这时要尽快从服务端找出原因

• 对客户端收到响应的时间设置一个阈值，比如1秒，超出后触发告警

• 对业务异常一定要监控，比如失败响应码

1.4 资源使用率

生产环境配置系统资源时，一般要对系统资源的使用率有一个预测。比如redis在当前的内存增长速率下，多久会耗尽内存，数据库在当前的增长速率下多久会用光磁盘。

系统资源需要设置一个阈值，比如70%，超过这个限制就要触发告