告警系统的开发，我们和 Ai 一样，经历了几个阶段，版本迭代的时间点也基本一致。整个开发过程中，我们最核心的问题其实不在于告警功能本身，而是其衍生的产品设计和开发设计。

和 Ai 一样，初期的告警实现特别简单。当时来自 IBM 研究院的吴海珊加入 OneAPM 团队，带来了 Cassandra 存储，我们当时用的比较早，是 2014 年 2.0 版本的 Cassandra，我们在充分压测之后，对它的数据存储和读写性能十分满意，基于它开发了初版告警（草案）。

初版告警的实现原理极其简单，我们从 Kafka 接收要计算的告警指标数据，每接收到一条指标数据，都会按照配置的规则从 Cassandra 中查询对应时间窗口的历史指标数据，然后进行计算，产生警告严重或者是严重事件。然后将执行的告警指标写入 Cassandra，将告警事件写入 Kafka。（看下一页）

所以你会发现初版的告警，从设计上就存在严重的 Cassandra 读写压力和高可用问题。

你会发现，每从业务线推送一条指标数据，我们至少要读写两次 Cassandra。和同时期的 Ai 架构相比，Ai 对 HBase 只有写入瓶颈，但读取，因为量不高，反而没有瓶颈。（回上页）

这里是我们和 Ai HBase的对比总结。我们初版的设计和 Ai 一样都需要全量地存储指标数据，而且 Cassandra 的存储分片本身是基于 Partition Key 的方式，数据必须基于 Partition Key 去查询，我们对于计算指标，按照 业务系统、应用 ID、时间 作为 Partition Key 去存储。很意外的是几乎和 HBase 同时出现了读写瓶颈。而且比较尴尬的地方也和 Ai 类似，因为 Partition Key 的定义，完全无法解决写入热点问题。

所以我们首先想到的是，对于当前的告警架构进行优化，我们有了上述的新架构设计。但是在评审的时候，我们发现，我们做的正是一个典型的分布式流式处理框架都会做的事情，这些与业务逻辑关系不大的完全可以借助现有技术实现。

由于这个时期（15年）公司整体投产大数据，我们自然把眼光也投入了当时流行的大数据计算平台。

首先，对于初版的架构，我们需要保留的是原有的计算数据结构和 Kafka 的写入方式，对于核心的告警计算应用需要去改造。

我们需要实现的是基于单条数据的实时流式计算。需要能分布式水平扩展。能按照规则分组路由，避免热点问题。需要有比较好的编程接口。