云原生应用链路分析实践，你学会了吗？

​一、云上应用现状与挑战

G行为深化“123+N”数字化发展体系，建设自主可控的全栈云平台，全面支持云原生、微服务和分布式等技术。然而由于在全栈云环境中因容器漂移、自动扩缩容使得应用故障现场难以还原，同时微服务技术的应用也使得云上应用服务调用关系复杂，链路难以准确梳理，故障发生时难以快速定位根因，给云上应用系统运维及故障排查带来了挑战，为此如何有效实现云上应用的可管理性和可观测性是一个较为急迫的问题。

面对上述问题，G行构建了云原生体系下链路分析体系（见图1），基于Trace（调用链）、Metric（指标）、Log（日志），实现了从基础架构监控（ITIM）、到网络性能监控（NPM）、应用性能分析（APM）以及数字体验监控（DEM）的全链路分析体系，提升云原生环境下的可观测性，为数字化转型保驾护航。

图1 云原生体系下链路分析体系示意图

二、云原生应用性能全链路分析系统架构

G行通过渠道应用性能分析系统（CAPAS）对接全栈云上互联网应用，通过APM全栈探针的能力和平台的数据分析能力，实现应用性能评分、调用链路追踪、代码级故障定位以及关联分析等能力，其主要技术架构如下图所示：

图2 云原生应用性能全链路分析平台架构

主要核心技术能力包括以下几点：

应用评分

通过对应用的Apdex评价、响应速度及错误率等关键性能指标作为量化要素计算出应用性能体验指标的综合评分，直观展示当前应用系统的总体运行态势。

智能探针技术（Smart Agent）

全面兼容K8S同时支持Image等多种方式安装，通过守护进程对容器的调度情况进行监控，当发现运行环境中有需要被纳管的容器对象生成时，将自动根据该容器环境适配对应类型的探针，然后将匹配好的探针进行自动装载和同步配置调整，实现探针的自动发现、自动注入、统一调度，实现了容器漂移或重启时自适应管控的能力。

自动发现应用调用链技术

利用字节码注入，即当调用了多个应用组件时，在调用第一个组件时会在第一个调用头中加入TraceID，当继续调用其他组件时此TraceID会向下传递，通过传递的TraceID能够自动发现应用组件调用的逻辑关系，基于有向无环图（DAG）的原理，能够自动识别应用在执行的过程中涉及的软硬件架构和组件，并且可以描绘出应用交互链中交易通讯的各个组件的访问路径，最终形成应用调用链，以实现对各复杂业务调用拓扑自动发现，解析应用运行状态。

端到端全链路分析

客户侧通过主动模拟监控方式和JS/SDK注入方式，获取用户使用业务过程中的网络请求性能数据、页面加载性能数据及使用中遇到的慢卡顿崩溃等各类问题，掌握用户真实业务使用过程中的性能体验及问题，实现业务系统用户体验监控（DEM）。同时在容器云上进行应用服务性能采集和数据分析，前后端通过TraceID关联分析的能力可以快速了解当前系统的整体运行状态，实现端到端打通，构建从用户到代码的全链路分析能力（见图3）。

图3 应用全链路分析

三、应用实践

目前G行渠道应用性能分析系统已经对接多个互联网移动移动包括手机银行、企业手机银行，同时也对接企业网上银行、个人网上银行、微信银行等WEB类系统，在全栈云环境对接缴费客户端服务（见图4），从开发测试环境到生产运行全方位服务相关系统，实现相关业务系统的实时状态展示以及问题根因分析，提升业务系统非功能优化能力，助力完善电子渠道应用产品。

图4 容器环境应用运行态势

四、回顾与展望

通过体系建设构建了应用系统前后端的性能监测与分析能力，全面兼容全栈云平台，实现对云原生应用的Trace、Metric和Log数据的收集分析，并通过前后端关联的方式，初步实现根因分析，掌握系统的运行状态。后续将在现有基础上，进一步实现以下目标：

基于G行全局跟踪码技术，将进一步将现有的TraceID作为衔接行内行外系统的纽带，实现从客户侧，服务侧乃至后台业务系统的全链路跟踪，实现从用户操作到产品响应的精细体验管理。

基于现有应用指标数据，实现业务的商业洞察，了解用户的使用流程和轨迹，从性能和收入角度综合分析IT服务支撑效果和用户使用习惯，真正从运维入手，来促进和提升业务运营；

实现多维度数据的不断积累，为全面的自动化运维奠定良好的数据基础和实践基础，构建不同维度的AIOps落地场景，在奠定基础的同时提升运维及业务收益。