作为证券行业金融科技的积极探索者，面对微服务化带来的性能监控与产线排障挑战，兴业证券紧跟科技发展浪潮和行业数字化转型趋势，积极完善基础设施建设，探索APM（ApplicationPerformance Monitor）性能监控系统的架构设计与实践，全栈自研并成功上线企业级一站式APM监控系统Hibbert。本文主要介绍了兴业证券Hibbert总体架构设计、核心组成模块、重要技术风险点、落地实践以及总结展望。
一、概述
随着互联网时代的发展，证券行业为了快速响应业务的变化，开始使用微服务架构。微服务架构的系统常常被切分为多个独立的子系统，并以集群的方式部署在数十甚至成百上千的机器上。虽然微服务架构带来更大的灵活性、更高的开发效率等等一系列优点，但同样也面临着很多棘手问题。例如，系统对外表现性能下降、故障种类层出不穷，而用户请求涉及的服务和服务实例非常多，要定位瓶颈、故障就需要浏览多个服务和机器的日志，步骤非常繁琐，微服务架构下的跟踪定位变得异常困难，传统的ELK模式已无能为力。
为掌握系统的运行状态，确保系统正常对外提供服务，需要一些手段去监控系统，以了解系统行为，分析系统的性能，或在系统出现故障时，能发现问题、记录问题并发出告警，从而帮助运维人员及时发现、排查、定位并解决问题，也可以根据监控数据发现系统瓶颈，提前感知故障，预判系统负载能力等。在定位到相关问题之后，我们可能考虑要给服务集群进行扩容，计算扩容多少台机器、新增部署多少个实例，都是需要相应的数据做支撑的，而不是凭开发和运维人员的直觉。
为了应对微服务架构系统面临的上述挑战，兴业证券自研APM性能监控系统Hibbert，不仅使得公司在性能分析和产线排障方面更加高效，也将对证券行业APM监控系统建设起到积极的示范作用。
二、架构设计
2.1总体架构
图1: Hibbert总体架构图
Hibbert总体架构图如图1所示，包括以下几个部分：
1)客户端：满足部门内自研、厂商系统多样性场景的接入需求。
2) kafka集群：接收客户端消息，存储并提供多方实时消费功能。
3)实时计算引擎：多线程异步队列消费消息，并插件化协调多个模块。
4)存储模块：定义多种类型数据最优存储策略，满足高性能读写要求。
5)告警模块：通过时间桶算法产出告警事件，触发预置事件处理逻辑。
6)查询模块：组织并展示多维度报表视图。
2.2 客户端接入
客户端系统的异质性决定了APM接入方式的多样性，Hibbert接入方式的多样性主要取决于系统框架及其语言差异。c、nodejs采用日志扫描方式接入，nginx、lua采用接口上报方式接入，这两种方式目前只支持简单的耗时、返回值等指标的监控，无法实现系统内部调用链路的消息组织，只能实现简单的性能分析、产线排障功能。
Hibbert客户端接入的主要对象是部门内部广泛使用的Java技术栈系统，因历史原因，目前分为Client和Sniffer两个功能模块。
Client是手动配置接入方式，主要服务于自研系统，用户接入Hibbert需要改造自身业务系统代码，在代码中配置例如springmvc、mybatis、log4j等拦截器实现埋点功能。图2展示了Client处理http、rpc客户端消息过程中的组织模型。通过step阶梯模拟出入栈的功能，将整个调用过程中产生的消息体组织成一条与调用顺序完全相符的调用链路。
图2:Client消息组织模型
部门内部的很多厂商系统不便对源码进行改造，无法接入Hibbert一直困扰着相关开发运维人员。随着jdk版本的更新，当下主流系统的jdk版本都在jdk8以上，而市面开源的javassist、bytebuddy等字节码类库，依赖jdk8以上版本能实现可靠、稳定的动态扩展，于是Sniffer应运而生。
Sniffer采用bytebuddy字节码类库，在系统启动时自动感知相关框架的存在，并对框架源码植入消息组织逻辑。图3展示了Sniffer处理http、rpc客户端消息过程中的组织模型。
图3:Sniffer消息组织模型
Sniffer通过消息栈将调用过程中涉及的消息体组织成与Client一样的调用链结构，完美兼容部门内部已有的Hibbert整套APM解决方案，这也是部门内部决定自研的最主要原因。
值得一提的是，实现相关框架的代码植入是需要对框架源码执行主体流程有一定的了解的，因此Sniffer研发是有一定难度的，但优点是，它几乎可以实现所有框架的植入埋点，这是Client基于配置埋点方式无法比拟的，因为不是所有框架都考虑到了预置扩展性。
Hibbert客户端接入的最后一步是在当前线程消息组织结束时，异步将消息制品上送给kafka。
2.3 实时计算引擎
实时计算引擎是APM最为核心的模块，它决定了对客户端消息的处理逻辑。市面上开源的APM实时计算逻辑大抵相似，将从kafka拉取到的客户端消息制品分发，按照预设目标进行线程分片，特定线程处理特定逻辑。
图4:实时计算引擎架构
图4展示了Hibbert实时计算引擎的简化架构。Collector将反序列后的消息分发到不同预置目标的数据处理器。图中列举了最为重要的三个处理器。CountingManager负责产生聚合类报表数据，根据不同的消息体类型分片并交给不同类型的分析器异步队列暂存，分析器监听队列消息并进行特定的处理逻辑，聚合生成报表数据并存储于influxdb时序数据库中，处理调用链全文检索数据并存储于elasticsearch数据库中，将全量调用链数据存储于系统磁盘中。AlarmManager和SamplingManager分别是告警处理器和调用链存储处理器，将在后续章节中介绍。
2.4调用链存储模块
前文提到，存储模块根据实时计算引擎的存储策略，将报表数据存储在influxdb中，将全文检索数据存储于elasticsearch中，将调用链全量数据存储于系统磁盘，本节主要介绍磁盘存储。
图5:磁盘存储架构
调用链存储处理器负责将消息体全量存储于系统磁盘中，存储性能必须高效可靠。图5展示了存储处理器内部数据流转过程。存储一条消息体涉及索引和数据两个文件，首先获取消息体的流水号，根据流水号上的滚动ID确认写入索引文件的偏移地址，写入的索引数据为48字节，包含32字节的块地址和16字节的块内偏移地址，前者记录该消息体在数据文件中的偏移位置，后者记录实际数据在数据块中偏移位置。
值得一提的是，图中架构设计能准确运转的前提是流水号滚动ID不重复，否则会出现数据覆盖。这对客户端流水号的生成提出了较高的要求，如何确保滚动ID准确自增的同时兼顾性能是值得思考的课题。Hibbert采用的方案是将滚动ID预生成在内存队列中供线程消费，每次预生成一定数量ID的同时，还会在磁盘文件中持久化存储，以防系统断电或宕机导致自增ID重复。当然，这样设计的缺点也显而易见，宕机时刻的不确定性会导致图中索引文件出现不确定大小的空窗，可能会导致严重的磁盘资源浪费。
2.5告警触发
Hibbert告警采用时间桶模式设计，在随着时间推移过程中根据告警规则产出告警消息。时间桶模式设计可以准确描述在过去N分钟内发生了M次阈值超限，因而触发告警。
图6:时间桶模式告警示意图
图6展示了demo1工程某请求在18:30到18:35时间推移过程中的耗时计算过程。预置规则为过去5分钟出现2次耗时超过2s则触发告警。每个规则维度都会初始化长度为5的时间桶队列，消息接收线程会将分钟聚合平均耗时写入该分钟所对应的桶内，时间检测线程会在分钟切换后将队列去首增尾，并判断当前是否符合告警触发条件。如图，在18:35时刻，时间检测线程已经发现过去5分钟有2分钟耗时超过阈值，立即触发告警。
而传统的超过阈值即触发告警的方式并不适合APM场景，例如cpu超过80%即告警，偶发性的cpu超限并不能准确反映系统存在的故障，大量无效的告警只会对运维人员开展工作徒增干扰。
Hibbert在告警渠道中还增加了类似webhook的钩子程序，之所以没有直接采用webhook是出于生产环境网络可能无法通达的考虑。Hibbert变通地将告警消息写入kafka，关心告警数据的下游业务系统可以订阅到自身涉及的告警，并预置处理逻辑。
三、落地实践
3.1监控大屏
图7中监控大屏页面作为首页，概要性地展示了部门内部系统调用次数、异常数量、响应耗时等信息及其与上个交易日的对比。对一些重要的业务条线，会根据调用、响应、错误等指标生成周报、月报统计页面。监控大屏可以帮助开发运维人员了解部门系统运行的总体状况。
图7:监控大屏页面
3.2服务运行总览
图8展示了多条产品线的调用次数、最大响应时间、平均响应时间、错误次数的统计分析。可以选择多个时间维度以便展示不同时间区间的指标数据。产品线内部包含多个系统，开发人员可以选择相应系统查看相应的统计聚合指标。
图8:服务运行总览页面
3.3调用链全文检索
图9展示了调用链全文检索页面，数据存储于elasticsearch中，用户可以根据关键词进行全文检索，匹配出符合条件的流水。在日常运维中，经常需要使用客户唯一ID进行故障排查，找出故障并分析处理。
图9:调用链全文检索页面
3.4调用链详情展示
在通过以上页面或运维日志定位到流水号后，图10展示了某条流水号的调用链详情，用户可以看到此链路包含的每一步调用的详情，包括调用类型、入参、返回值、发生时刻、耗时、主机端口、线程等信息，直观重现当时调用链路的运行情况。
值得一提的是，一条调用链路可能包含多个主机的调用信息，如果主机之间的时间不同步，那么调用时刻分析就会毫无意义。
图10:调用链详情页面
3.5告警
在实时分析引擎后台配置告警后，可以在告警页面查看相应的告警信息，用户自定义的接收器也会收到告警请求，可以触发用户自定义的处置逻辑。图11展示了告警消息列表，包括告警的系统名、主机、告警时间及内容。用户可以实时查看系统触发的告警，及时进行相应的处理。
图11:告警页面
四、总结展望
APM作为业务系统产线排障和性能分析最强大、最高效的手段，对业务系统运行状况进行加工、分析、聚合、告警，最终创造价值。对于产品人员，用户体验可量化，并积极同业对比，发现自身差距并进行优化，提升客户满意度。对于运维人员，围绕系统运行状况开展运维工作，提高运维价值，对运维数据可视化，更快更准地做出应急决策。对于开发人员，对系统性能和故障的把握更加全面、准确、快速。
兴业证券面对数字化转型浪潮，积极完善基础设施建设，利用金融科技赋能业务跨越式发展。本文阐述的Hibbert架构设计以及落地实践的一站式解决方案是公司响应国家数字新基建和技术创新的重要举措，对证券行业的系统监控建设也有着积极的示范作用。公司通过此项目也加强了开发与运维团队的协作，培养了一批在实时计算、任务调度、存储引擎、智能运维等领域的人才。公司会持续加强科技创新、赋能业务发展和数字化转型，为行业金融科技贡献更多的力量。