掐指一算,从 OneAPM 离职也快一个月了,在 OneAPM 工作的种种,仿佛还像是在昨天。细数两年的工作经历,我很庆幸在恰当的时间点和这么一群有激情有活力的人共事。那么,是时候总结一下我在 OneAPM 做的牛(cai)逼(ji)事情了。
大家好,今天由我来分享一下,我在上家公司做的 Ai 和 告警 相关的一些内容。
首先,我先简单介绍一下,今天我要分享的两个项目:
- Ai 是 OneAPM 服务器端应用性能监控分析程序,它主要是能收集Java、CSharp、Python等偏后端语言的系统的一些指标数据。然后分析出调用 Trace 和完整的调用拓扑图,还有一些其他图表数据的展示。
- 告警系统原先作为一个 Ai 系统的子模块,用的是流式计算框架 Flink,后面不能满足对外交付和业务功能需求。我们就重新设计开发了纯粹的CEP计算引擎,依托于此在Ai上构建了新的告警系统,然后服务化拆分成独立的告警系统,并接入了其他类似Ai的业务线。
这次分享,一是我对以前2年工作的整理和思考,二也是和大家交流学习。
对于 Ai,我不属于它的主要研发,我只是在上面剥离开发了现有的告警系统。所以我就讲讲我接触过的架构部分的演进。本身,就功能部分,其实没有东西。
我在说告警的时候会说的比较细一些。
我是15年年底入职OneAPM,17年9月初离职加入咱们这个团队。这期间Ai伴随着业务的需求,也进行了三次大的技术架构演进。最明显的,就是每次演进中,Ai对应的存储在不断变化。同时,比较巧的是,每次架构变化的同时,我们的数据结构也略有不同,并且学习的国外竞品也不大一样。
说老实话,我们每次改变的步子都迈的略大,这中间也走了不少弯路。很多技术、框架,一开始看十分好,但是却不一定契合我们的需求。项目在变革初期就拆分出SaaS和企业级两套代码,并且各自都有比较多的开发分支,这些东西的维护,也让我们的代码管理一度崩溃。
但是,我这里主要想分享的,就是我们在业务和数据量不断增长的同时的架构设计变化,以及最后如何实现灵活部署,一套代码适配各种环境。
OneAPM 在 2013 年开始涉足 APM 市场,当时在13年做了我们的第一代产品 Si ,它是那种庞大的单体应用,功能也十分单一。
在 2014 年初 OneAPM 基于用户需求和学习国外同类产品 NewRelic 开发了第一版 Ai 3.0。它的架构非常简单,就是一个收集端收集探针的数据写入Kafka,然后落到HBase里,还有一个数据展示端直接查询HBase的数据做展示。
在 2015 年初的时候,企业版开始做架构演进,首先是在存储这块,对于之前用 HBase 的聚合查询部分改用 Druid,对于 Trace 和 Transaction 数据转而使用 MySQL,同时,我们学习国外竞品 dynaTrace 完善了我们的分析模型。
2016 年的时候,我们发现存储是比较大的问题,无论是交付上,还是未来按照数据量扩容上。且 Druid 的部署、查询等都存在一些问题。在SaaS上线Druid版本之后,我们调研各类存储系统结合业务特点选用ClickHouse,并基于它开发了代号为金字塔的查询和存储模块。
2017 年的时候,我们开始梳理各个业务系统、组件,将它们全部拆分,公共组件服务化、Boot化,打通了各个系统。
感谢博主,收获很多,个人觉得整个架构重点在关注数据流式处理和存储,为什么不考虑用类似influxdb等时序数据库引擎实现呢?
雨帆大佬,这篇文章写的是非常好啦。小弟还有些不懂的地方,可以求个认识么?邮箱是QQ也是微信。