服务治理治什么

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

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

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

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

1 监控告警

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

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

 批处理效率

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

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

• 域名系统要通过dns信息和数据库记录来找出脏数据进行交易补偿，这期间客户查询域名信息可能是脏数据
• 银行日终跑批期间是不允许实时交易的，这个「7 * 24」小时不间断服务相违背

这些场景下批处理效率是非常重要的一个监控指

• 的系统，使用的监控指标是不同的，比如redis，可以用QPS指标，对于交易系统，可以用TPS
• 通过测试和业务量的预估来配置合适的监控阈值
• 监控阈值需要考虑突发情况，比如秒杀、抢券等场景

1.3 异常监控

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

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

• 客户端read timeout,这时要尽快从服务端找出原因
• 对客户端收到响应的时间设置一个阈值，比如1秒，超出后触发告警
• 对业务异常一定要监控，比如失败响应码

1.4 资源使用率

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

系统资源需要设置一个阈值，比如70%，超过这个限制就要触发告警。因为资源使用快要饱和时，处理效率也会严重下降。

配置资源使用率的阈值时，一定要考虑突增流量和突发业务的情况，提前预留额外的资源来应对。

对核心服务要做好限流措施，防止突增流量把系统压垮。

1.5 请求延迟

请求延迟并不是一个很容易统计的指标，下图是一个电商购物系统

（编辑：宿州站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!