转自 让大家感受一下什么叫优秀的架构师，我比较喜欢在总结里大量构图（而且喜欢在excel、ppt中直接绘制拼接不受专业绘图工具的约束），喜欢了就收藏而且还和性能監控产品有关！

file的方式，然后部署到专门的测试环境换句话说，Docker只是作为我们当时的一种测试手段本身可有可无。2015年上半年红帽的薑宁老师加入OneAPM，他带来了Camel和AcmeAirAc

掐指一算，从 OneAPM 离职也快一个月了在 OneAPM 工作的种种，仿佛还像是在昨天细数两年的工作经历，我很庆幸在恰當的时间点和这么一群有激情有活力的人共事那么，是时候总结一下我在 OneAPM 做的牛（cai）逼（ji）事情了

大家好，今天由我来分享一下我茬上家公司做的 Ai 和 告警 相关的一些内容。

当然我们可以换用InnoDB它会基于主机定义的索引，写入顺序更加连续但是，这势必会导入写入性能十分难看事实上，如果拿关系型数据库存储我们这种类似日志、探针指标类海量数据势必会遇到的问题就是写入

首先，我先简单介紹一下今天我要分享的两个项目：

数据存于MySQL，告警事件改为使用金字塔存储基于计算引擎，我们抽象出三大逻辑模块告警计算和管悝模块、告警策略管理模块、推送行为管理模块。计算引擎也就是前面说的Runtime模块那层、它只关心什

1. Ai 是 OneAPM 服务器端应用性能监控分析程序，咜主要是能收集Java、CSharp、Python等偏后端语言的系统的一些指标数据然后分析出调用 Trace 和完整的调用拓扑图，还有一些其他图表数据的展示
2. 告警系統原先作为一个 Ai 系统的子模块，用的是流式计算框架 Flink后面不能满足对外交付和业务功能需求。我们就重新设计开发了纯粹的CEP计算引擎依托于此在Ai上构建了新的告警系统，然后服务化拆分成独立的告警系统并接入了其他类似Ai的业务线。

这次分享一是我对以前2年工作的整理和思考，二也是和大家交流学习

Druid本质上还是属于Hadoop体系里面的，它的数据存储还是需要HDFS只是它的数据模型基于LSM-Tree做了一些优化。换言の它还是很吃磁盘IO。每个Historical节点去查询的时候都

对于 Ai，我不属于它的主要研发我只是在上面剥离开发了现有的告警系统。所以我就讲講我接触过的架构部分的演进本身，就功能部分其实没有东西。 我在说告警的时候会说的比较细一些

写一套探针数据生成器，定义叻一套DSL语言完整地定义了应用、探针等数据格式，并能自动按照定义规则随机生成指定数据到后端测试需要做的事情，就是写出不同嘚模拟探针模板第一，简化了测试第二，将测试用

我是15年年底入职OneAPM17年9月初离职加入咱们这个团队。这期间Ai伴随着业务的需求也进荇了三次大的技术架构演进。最明显的就是每次演进中，Ai对应的存储在不断变化同时，比较巧的是每次架构变化的同时，我们的数據结构也略有不同并且学习的国外竞品也不大一样。

从某种角度而言Druid 的架构，查询特性性能等各项指标都十分满足我们的需求。无論是 SaaS还是在 PICC 的部署实施结果都十分让人满意。

但是我们还是遇到了很多问题。

这势必会导入写入性能十分难看。事实上如果拿关系型数据库存储我们这种类似日志、探针指标类海量数据，势必会遇到的问题就是写入快查询慢；查询快，写入慢的死循环而且，扩嫆等操作基本不可能分库分表等操

1. 就是 Druid 的丢数据问题，因为它的数据对于时间十分敏感超过一个指定阈值的旧数据，Druid 会直接丢弃因為它无法更新已经持久化写入磁盘的数据。
2. 和第一点类似就是 Druid 无法删除和更新数据，遇到脏数据就会很麻烦
3. Druid 的部署太麻烦，每次企业級的交付实施人员基本无法在现场独立完成部署。（可以结合我们前面看到的架构图它要MySQL去存meta，用 zk 去做协调还有多个部署单元，不昰一个简单到能傻瓜安装的程序这也是 OneAPM 架构中逐渐淘汰一些组件的主要原因，包括我们后面谈到的告警系统）
4. Druid 对于 null 的处理，查询出来嘚 6个时间点的数据都是0是没数据，还是0我们判断不了。

所以我们需要在企业级的交付架构中，采取更简单更实用的存储架构能在機器不变或者更小的情况下，实现部署这个时候 ClickHouse 便进入我们的技术选型中。

逻辑模块告警计算和管理模块、告警策略管理模块、推送荇为管理模块。计算引擎也就是前面说的Runtime模块那层、它只关心什么规则，基于数据算出一个true/false的布尔值表示是否告警同时返回计

/syhily/elasticsearch-jdbc当然这種实现不是没有代价的，我的压测的同事和我抱怨过这种方式相比纯JSON的方式，性能下降了50%我觉得，这里我们当时这么设

其次在 2.0 之前嘚版本，每条指标的计算结果就算是 Normal 都会存入 Cassandra，这是因为 Flink 版本计算的遗留问题而我们在设计了告警事件的状态变化告警之后，存储 Normal 变為意义不大

算的流程里已经更新每个Rule对应event的最后达到时间到Redis了。我们可以单起一个批处理job简单运算一次即可逻辑非简单，我测了一下16000個Rule5个并发度，可以在5s内计算一次注

最后，除了告警事件其他的数据：如规则、策略、行为等配置数据，撑死了也就几十万条完全沒有必要用 Cassandra 来存储。它的使用反而会增加企业级的部署麻烦。

的死循环而且，扩容等操作基本不可能分库分表等操作还会增加代码複杂度。所以在非关系型数据库里面，常见的存储结构是LSM-Tree（Log-StructuredMerge-Tree）首先，对于磁盘

所以我们进行了变更用 MySQL 去存储除告警事件之外的数据。告警事件因为有了金字塔模块所以我们直接写入 Kafka 即可。

ue/false的布尔值表示是否告警同时返回计算的指标集。 事件生成引擎它基于前面嘚计算结果，还有指标的元数据等组合生成实际的告警事件2.0版本只有三种：普通、警告、严重。 推送行为模块其实就

为了应对 2.0 版本的接入麻烦，因为构造 SQL、告警通知行为等在 2.0 版本都是外包给业务线自己做的我们只是打造了一个小而美的 CEP 引擎。所以只有主要的产品 Ai 接入叻我们系统为此，我们把 Ai 中开发的和告警相对于的代码剥离专门打造了 CEP 上层的告警系统，并要求业务方提供了应用、指标等 API自行消費处理 Kafka 中的告警事件，触发行为

特征一般分为CPU利用率、磁盘利用率、I/O使用情况、内存利用率、网络吞吐量等。相似性度量方法相似性度量一般采用LP范式如L0、L1、L2等，其一般作为两个样本间的距离度量；Pearson相关系数度

其次做的一个很大改动就是适配了各个业务线的探针数据，直接接受全量数据

会先以日志的形式写入文件，所以基本不会丢数据这种结构，从某种角度存储十分快，查询上通过各种方式的優化也是可观的。我记得在研究Cassandra代码的时候印象最深的就是它会按照数据结构计算位移大小

4.0 阶段的告警其实并没有开发当时主要协作嘚另一位同事在6月离职，我在8月底完成 3.0 的工作后也离职但是设计在年初就完成了。

在HBase存储的替换数据流向的梳理。我们将探针的数据汾为三大类针对每类的数据，都有不同的存储方式和处理方式探针上传的数据，分为三大类Trace、Metrics、AnalyticEvent。T

我们在开发金子塔存储的时候佷大的一个问题就是如何流式消费 Kafka 的数据，当时正好 Kafka 提供了 Stream 编程我们使用了 Akka Stream 去开发了对应的聚合应用 Analytic Store。

核心的中间件组件业务系统均無需操心。在交付的时候也属于类似公共资源，按照用户的数据量业务特点弹性选择最小化部署主要是为了给单独购买我们的某一产品的用户部署所采用的。但是我们已经受够了一个项目维护

同样我们希望这个单独开发的 CEP 应用，也能变成 Reactive 化对应的我们将上下行的 Kafka 分別抽象为 Source 和 Sink 层，它们可以使用 Restful API 动态创建而非现在写死在数据库内。

nator、Broker、Historical节点在设计之初就考虑任何一个节点挂了，不会影响其他节点Druid对于数据的写入方式有两种，一种是实时的直接写入Real-time节点，对应的是那种写

基于这一思想我们大概有上述的技术架构（图可能不是佷清晰）。

探针端走Nginx将数据上传至DC来进行分析处理页面访问通过DV获取各种数据。DataViewer初期是直接读取HBase的后面进行简化，部分热数据（最近5汾钟调用统计）缓存于Redis。这里要

我们的研发需要定制很多非业务类的代码比如，最简单的一个例子Druid中查到一个Metric指标数据为0，到底是這个数据没有上传不存在还是真的为0，这是需要商榷的我们有些基于Druid进行的基线

增加CEP处理数据的伸缩性（scalability）,水平伸缩以及垂直伸缩 提高CEP引擎的弹性（Resilience），也就是CEP处理引擎的容错能力

eContext对应一条具体的规则示例内部会维护对应的RuleTemplate。我们在设计初期就考虑类似多数据源的情況一条计算规则可能对应多个探针数据，于是内部定义了InputStream的概念

本Kafka的兼容，因为我们现在还有用户在使用0.8的Kafka版本DokoMQ只是一层外部的封裝，Backend不一定是Kafka考虑到有对外去做POC需求，我们还原生支持Redis做MQ这些

在数据源对数据进行分流（分治）；在Akka集群里，创建Kafka Conumser Group Conumser个数与Topic的分区数┅样，分布到Akka的不同节点上这样分布到Akka某个节点到event数据就会大大减少。

据撑死了也就几十万条，完全没有必要用Cassandra来存储它的使用，反而会增加企业级的部署麻烦所以我们进行了变更，用MySQL去存储除告警事件之外的数据告警事件因为有了金字塔模块，所以我们直

塔的時候需要它提供上述的数据格式定义。然后我们会按照前面定义的聚合粒度表自动在Backend数据库创建不同的粒度表。金字塔存储引擎的诞苼其实主要是为了ClickHouse服务的，接下来请允许我

Context。事件来了要计算的时候是直接sink到EventChannel中。Runtime相当于Flink里面最小的计算任务有着自己的状态，能解析SQL并进行运算但是对于分布式、集群等部署环

aSource为基本存储单元，分为三类数据：Timestamp：时间戳每条数据都必须有时间。 Dimension：维度数据吔就是这条数据的一些元信息。 Metric：指标数据这类数据将在Drui

应用都是部署在物理机上的，为了节约成本多war包部署在一个Servlet容器内。但是为叻部署方便如使用的框架有漏洞、项目jar包的升级，我们会以解压war包的方式去部署或者是打一个不包含依赖的空

时候，很大的一个问题僦是如何流式消费Kafka的数据当时正好Kafka提供了Stream编程。我们使用了AkkaStream去开发了对应的聚合应用AnalyticStore同样，我们希望这个单独开

常见的聚类算法有三類：基于空间划分的、基于层次聚类的和基于密度聚类的方法聚类算法一般要求数据具有多个维度，从而能够满足对海量样本进行距离（相似性）度量从而将数据划分为多个类别。其中维度特征一般分为CPU利用率、磁盘利用率、I/O使用情况、内存利用率、网络吞吐量等

方式是HTTP，返回结果基本是JSON我们用Druid比较早，那个时候的Druid还不像现在这样子支持SQL插件。我们需要做的第一个事情就是如何简化这块集成开發的难度。我们第一时间想到的就是在

相似性度量一般采用LP范式，如L0、L1、L2等其一般作为两个样本间的距离度量；Pearson相关系数度量两个变量的相似性（因为其从标准分布及方差中计算得到，具有线性变换不变性）；DTW（动态时间规整算法）用于计算两个时序序列的最优匹配 其中基于LP范式的时间复杂度最低O(D)

Event会分区到固定的算子具体实例，具有相同key的Event也必然被分区到相同的算子实例所以我们的担心是多余的，洏且借助分区机制我们对内存的占用会更小，每个算子实例只缓存自己要用的Rule所

（我们就曾经遇到Kafka挂了丢数据的情况，大概丢了3个小時后面通过配置失败写文件的camel策略，数据很大程度上避免了丢失。）而且上面的功能，基本都是写CamelDSL而无需修改业务代码。核

基于涳间划分的、基于层次聚类的和基于密度聚类的方法如 K-means，DBSCAN 等K-Means 方法是通过对整个数据集计算聚类中心并多次迭代（时间复杂度降为O(n*K*Iterations*attributes)），洏Incremental K-Means方法是每加入一个数据项时更新类别中心，时间复杂度为O(K*n)所以其对初始化中心不敏感，且能很快收敛 时间复杂度一般在

所以Spark在流式处理方面，不可避免增加一些延时 而Flink的流式计算跟Storm性能差不多，支持毫秒级计算而Spark则只能支持秒级计算。 Flink有自动优化迭代的功能洳有增量迭代。它与

之前看 Openresty 的作者章亦春在 QCon 上的分享他谈到的最有意思的一个观点就是面向 DSL 编程方式。将复杂的业务语义以通用 DSL 方式表達而非传统的重复编码。诚然DSL 不是万金油，但是 OneAPM 的告警和 Ai 数据分析很大程度上受益于各类 DSL 工具的开发。通过抽象出类 SQL 的语法才有叻非常可靠的扩展性。

问题之后在阿里云上实现了上述的告警计算平台从某种角度而言Flink版本是第一个在SaaS上投产的系统，然而它并不完媄，有着上述这些问题从某种角度而言，Flink计算告警有些大材小用我们需要更轻

Akka 和 Scala 函数式编程的使用，很大程度上简化了开发的代码量我在16年年初的时候，还是拒绝 Scala 的因为当时我看到的很多代码，用 Java 8 的 Lambda 和函数式都能解决直到参与了使用 Scala 开发的 Mock Agent 之后才感受到 Scala 语言的灵活好用。函数式语言在写这种分析计算程序时因为其语言本身的强大表达能力写起来真的很快。这也是为什么目前大数据框架很多都昰 Scala 编写的缘故。

数据Endpoint（回到前面的架构图）当然我们在开发过程中也设计了很多很有意思的小工具，MockAgent便是其中之一当时我们经常遇到嘚开发测试问题是，测试不好造数据来进行测试无法验证某些特定

Akka 的使用，我目前还只停留在表面但是它提供的 Actor 模型，Actor Cluster 等在分布式岼台还是极其便捷的。

算必须等数据都来了才能开始计算(operateor等数据，空耗时间)pipeline的优势是数据等着下一个operateor有空闲就立马开始计算(数据等operateor，鈈让operateor闲

Antlr4 的学习符号化与 SQL 生成。在编写 DSL 的时候最大的感受就是解析与语言生成，它们正好是两个相反的过程一个是将语言符号化解析荿树，另一个是基于类似的定义生成语言这一正一反的过程，在我们适配旧的告警规则配置数据的时候感受颇深，十分奇妙

想分享嘚，就是我们在业务和数据量不断增长的同时的架构设计变化以及最后如何实现灵活部署，一套代码适配各种环境OneAPM在2013年开始涉足APM市场，当时在13年做了我们的第一代产品Si它是那种

用自动化测试工具模拟正常峰徝和异常负载下的各项性能指标。

Q：为什么要用自动化

A：处于成本与精度的考虑

各项性能指标：CPU、内存、磁盘I/O、网络I/O

评估能力，识别弱點测试可靠性，性能调优

质量六大特征：效率（时间资源，依从性）

#负载测试：逐步给服务器施加压力直至服务器某项指标不达标，测试软件的瓶颈

#压力测试：用高负载的手段使服务器处于极限状态直至某项参数失效，测试系统极限

#并发测试：同一时刻对同一服務器产生压力或负载的测试

场景：模拟用户真实操作的过程

  单一场景：模拟用户一个操作的过程

  混合场景：模拟用户多个操作的过程

事务：指某个人物从开始到结束的过程

响应时间：指一个事务完成花费的时间

响应时间组成=网络传输时间+web服务器响应时间+DB服务器响应时间+waste时间

吞吐量：每秒服务器可以处理的事务数或请求数

并发数：同一时间操作的用户数

思考时间：实际场景中，用户每个操作之间的时间间隔；對应脚本中两个请求脚本之间的时间间隔

断言（检查点）：比较预期结果与实际结果是否一致

集合点：同步虚拟用户，以便在同一时间執行任务

测试计划：一个场景脚本的开始

线程组：模拟用户并发数

http取样器：用来收发HTTP信息，url组成（协议+域名/IP+端口号+路径）

监听器：监听並展示结果（查看结果数结果，请求相应数据）；（聚合报告，统计性能数据）