共计 3367 个字符，预计需要花费 9 分钟才能阅读完成。
导读：作为凤睛晚期的接入方、前期的核心成员，笔者经验了整个我的项目前后四年的变迁，看过我的项目的艰巨开始、中期的默默积攒以及前期的蓬勃发展。每一次架构的变迁都带着技术浪潮的烙印，也看到我的项目成员利用无限资源来解决理论问题而继续一直的翻新。
凤睛是百度商业业务零碎的性能监控零碎（APM），它侧重于对 Java 利用的监控，根本接入了百度绝大部分 Java 利用（笼罩数千个业务利用，数万个容器）。它可能对支流中间件框架（Spring Web、RPC、数据库、缓存等）进行主动埋点，实现全栈式性能监控和全链路追踪诊断，为百度各业务线提供微服务零碎性能指标、业务黄金指标、健康状况、监控告警等。
△凤睛产品流程图
- 数据采集：凤睛探针技术可能主动植入到业务过程中去，采集相干性能信息，业务过程齐全无感知。
- 数据计算和剖析：依照类型，时序数据存储在百度 SIA 智能监控平台的时序数据库 TSDB，用来生成可视化报表和异样报警。调用链数据会被存入 Palo（开源名为 Doris）大数据仓库，用来拓扑剖析和调用链检索。
- 利用场景：如上所述，凤睛提供稳定性报表、异样报警、谬误堆栈剖析、服务耗时剖析、调用拓扑剖析、业务日志关联剖析等。
△凤睛的架构变迁工夫线
01 凤睛立项
我的项目发动在 2016 年，百度凤巢广告业务零碎中间件 (分布式 RPC 框架 Stargate 等、配置核心、数据库中间件等)曾经欠缺。随着单体服务拆分的深刻，整体 Java 在线上部署规模逐步变多，同时，裸露的问题也越来越多。
典型的问题有：
- 外围服务问题定位周期长。多个模块大量报错后，破费了很长时间才定位问题。
- 集群日志获取代价十分高，不足日志调用链关系等起因导致定位代价很高，甚至有些问题无奈定位。
- 异样日志须要登录具体的线上实例查看。而线上部署实例数目多，排错工夫长。
凤巢业务端急需一个分布式追踪零碎来实现整个业务端日志的“大串联”。所以百度商业平台基础架构组发动了凤睛的我的项目，名曰“凤巢之眼”。
02 凤睛 1.0
在分布式链路追踪畛域，探针采集这个环节次要存在侵入式和无侵入式。1.0 探针走的侵入形式。业务开发人员首先引入探针相干的依赖 jar 包，通过拦截器主动收集调用关系以及性能数据；而后，增加硬编码补充业务数据。
△编码示例
探针采集的数据会被打印到磁盘，通过 kafka 收集走。底层的数据处理和数据存储采纳了 Storm、Hbase 等过后风行的数据处理系统。后端架构比较复杂。
△凤睛 1.0 架构示意图
03 凤睛 2.0
凤睛 2.0 版本中，首先是升高探针接入老本。2.0 版本中，探针改用 java agent 技术联合 cglib 做 AOP 注解，把依赖引入的 jar 包从 N 个升高到 1 个。从编写大段的调用链填充代码改为尽量走 AOP。探针端传输层采纳了更高效的传输协定（protobuffer+gzip）, 间接通过 HTTP 协定发送到 kafka，大大了升高磁盘 IO 开销。
2.0 探针较 1.0 接入不便，传输也更快。然而仍需业务方增加 AOP 代码。对于业务端数以百计的利用来说，接入依然是大工程，推广仍然艰难。
04 凤睛 3.0
凤睛 3.0 架构设计中，我的项目组成员始终在思考两个问题：
- 如何让业务方疾速接入，尽量少改变，甚至“无感知接入”？
- 如何升高架构运维难度，既能解决海量数据，又能低成本运维？
为了解决问题 1，探针 3.0 决定齐全放弃侵入式形式，改为无侵入即字节码加强形式。
对过后几种风行的监控诊断工具进行了调研：
△Newrelic，pinpoint，greys 监控探针调研
3.0 探针参考了 Greys 反对运行时加强的特点以及 pinpoint、Newrelic 基于插件扩大开发的设计理念。最终成果是探针可能主动对业务过程植入监控代码，监控具体工作交由插件体系实现，齐全面向切面监控。
△探针被动加载示意图
后端存储系统转而依靠 Doris。Doris 是百度自研的基于 MPP 的交互式 SQL 数据仓库，兼容 mysql 协定，学习成本低。既能够做存储又能够做剖析计算，初期防止引入 spark，storm 等技术，升高零碎复杂度。
△架构设计如图所示
架构降级后，作为小团队，也能疾速批量部署探针，计算存储能力也能满足需要。截止 2017 年，凤睛 3.0 上线了 100 多个利用，跑在 1000 多个容器下面。
05 凤睛 4.0
2018 年，微服务和虚拟化浪潮席卷而来。随着部署平台的一直降级和 springboot 体系的成熟欠缺，单体可能被疾速拆分成了数目泛滥的微服务，依靠平台进行高效的运维部署。凤睛作为根底组件被微服务托管平台集成，并失去公司级的推广应用，整体部署利用规模从百级别激增到了千级别，部署容器从千级别变成了万级别。
这个阶段暴发了很多问题，技术外围问题次要有两点：
- 探针降级须要重启业务利用失效，而线上利用重启流量有损。导致难以频繁降级探针版本，疾速引入新性能。
- 每天实时写入 150 亿条，峰值流量 300w 条 /s。数据导入容易失落；检索单条调用链性能查，大略须要 100 多秒。
2019 年，凤睛进行了进一步的革新降级，针对 1、2 两个问题，进行了技术攻坚。
探针层面钻研如何反对热插拔，也就是探针在业务过程运行的状况下主动实现降级。起初为了保障业务类对探针插件类的可见性，探针类对立放到了 System Classloader 里。然而 System Classloader 作为零碎默认的，不反对卸载。反之，如果把探针类全副放到自定义类加载器中。探针类则对业务类齐全不可见，也就无奈实现字节码加强。
△探针热插拔 classloader 体系
为了解决可见性问题，探针引入了桥接类，通过桥接类提供的代码桩和插件类库投影，用户类能够拜访理论应用的探针类，实现监控革新的目标。对于不同插件，则放在不同的自定义 Classloader 外面。这样来插件之间互不可见。单个插件也能够实现热插拔。具体的设计细节前面会有文章具体解读。
毋庸置疑，凤睛探针是业界惟一可能热插拔的监控探针技术，咱们也申请了专利。它的性能正确性和性能是经验过大规模线上流量验证的。
持续推动优化调用链检索的性能。
首先剖析下咱们的底层存储构造：
通过对慢查问的剖析，发现检索慢次要是两个起因：一是大量查问没有走任何索引，全表扫描海量数据十分慢。二是，导入碎片过多，导致文件 Compaction 特地慢，典型的 LSM-Tree 的读放大。为了解决这些问题，调用链存储层重构表构造，通过大量 Rollup 配合根本表，优化查问工夫。Doris 此时曾经具备流式导入的能力，也借机从小批量导入切换到流式导入。
△调用链解决架构
△上图是凤睛实时构建的微服务全景拓扑图。截止 2020 年 1 月，大略涵盖了数十条产品线的线上流量拓扑，最细粒度的节点为接口，即 Java 利用中的函数。从图中能够剖析出，托管全平台非孤岛接口节点大略有 50w+，接口节点连线 200w+ 条。
06 数据处理架构拆散
架构持续演进，凤睛采集的数据量越来越多，业务方需要也越来越多。
次要面临两个问题：
- 数据可视化能力依赖于前端开发，大量多维可视化剖析需要难以满足。
- 调用链做了采样，导致统计数据不精确，无奈满足统计报表的需要。
这两个问题归根结底是时序数据如何存储和展示。这波及到分布式追踪畛域两个很根底的概念，时序工夫和调用链数据。所谓的时序数据是基于工夫的一系列的数据，用于查看一些指标数据和指标趋势。调用链数据是指记录一个申请的全副流程，用于查看申请在哪个环节出了故障，零碎的瓶颈在哪儿。
时序数据不须要保留细节，只存工夫、维度和指标的数据点, 能够存储在专门的工夫序列数据库（Time Series Database）。理论场景中，凤睛没有专门去保护一个时序数据库。而是对接百度 SIA 智能监控平台的分布式时序数据库 TSDB。同时，利用百度 SIA 平台提供丰盛的多维可视化剖析报表，用以解决用户各种可视化多维度数据分析的需要。
△以后整体的架构
07 结语
凤睛整个我的项目前后继续了 4 年，两头经验过有数的艰难和崎岖，通过积攒了我的项目成员们继续的付出，最终获得里程碑式的成绩。本文简要介绍了凤睛产品的业务背景、技术架构和产品状态，后续会持续发文介绍技术相干的实现细节，欢送继续关注。
浏览原文
百度商业大规模微服务分布式监控零碎——凤睛
举荐浏览
|百度搜寻与举荐引擎的云原生革新
最初欢送各位关注咱们的同名公众号「百度 Geek 说」～