Monitor

量级：承载了 100w 左右的服务器和 2w多个视图的监控

二、工作经历

数据量：Monitor系统注册了100w 左右的服务器和 2w 多个视图

1. API模块的设计与开发

使用缓存作为数据库的中介，提高系统的性能和吞吐量；采用Cache-Aside Pattern的缓存更新策略，尽可能的保证缓存中的数据是最新的，同时也尽可能的解决缓存与数据库的数据不一致问题。针对写接口的限频，参考类似滑动时间窗口的限流算法，对于同一用户调用同一写接口的时间间隔必须大于一秒，做到最省成本且最大可能的保护系统的数据库负载不会太高。
查询接口的QPS：5w/s，资源占用：2C

缓存更新策略：【架构框架/release/缓存.md】（包括增删查改）。为什么不用 redis？用不起，成本高。

限流算法：滑动时间窗。两个统计周期部分重叠，从而避免短时间内的两个统计点分属不同的时间窗的情况。比如 0.00 - 1.00 分钟统计，0.30 - 1.30 分钟做统计，1.00 - 2.00 做统计 【架构框架/极客-架构/高可用架构模式/应对接口级故障.md】

缺点：写接口限频非分布式，限频不准。不过这个服务的写请求不是很多，部署 API 模块也就 3 个即满足了需求，因为这点不足为虑。

2. 告警模块的重构与开发

针对之前的告警服务存在消息未聚合、不同时间间隔存在重复的消息导致每次待发送的消息数量多，使下游发送消息接口经常性的触发限频，最终可能导致告警消息丢失，严重影响用户的使用。后续对相同时间间隔（1分钟）的告警消息进行聚合（合并相同接收人的消息），过滤掉不同时间间隔的重复消息，优化了发送告警的策略。
原来的平均发送告警消息总量约为30w/d，优化后约为19w/d。过滤：字符串告警。 tof接口每天最多发送25w。

告警通道：邮件、企业微信、微信、电话；还有 monitor 页面展示告警。设置告警级别（普通、重要）。

  • 普通告警是邮件、企业微信、微信这三个业务可选；重要 告警加上电话这个选项
  • 普通告警只会发一次。重要告警需要等到业务确认为止，每一个告警周期都会发送，三轮告警若未处理，会上升到上一级 leader 三轮。

这个告警策略，我们技术人员要保证这个告警消息不丢失，而告警策略可配置。交给产品和用户谈使用习惯。

一天 30w 条消息，一小时 12k 条消息，一分钟 208 条。

有大量的这种场景，一个服务出现问题，可能集群中会有多台机器告警，因为 monitor 是基于机器 IP 的，以及每条策略生成一条告警消息，分别发给同一个负责或运维同学。现在我对这些消息做了收敛，一个周期内相同接收人的消息收敛到一条消息中。

对于普通告警，只报告一次，下一周期就不报告了，因此对于往后的一个周期的告警就不发送了。以一天的告警量为基础，每一条消息都会对应一个告警规则 ID，用于区分是否为重复告警。 针对那种一直没理睬告警的情况。这些数据会存储于 MySQL 中。