Seata 的可观测实践

Posted 2023-05-22 阿里系统软件技术

Seata 的前身是阿里巴巴集团内大规模使用保证分布式事务一致性的中间件，Seata 是其开源产品，由社区维护。在介绍 Seata 前，先与大家讨论下我们业务发展过程中经常遇到的一些问题场景。

作者：察溯

Seata 简介

Seata 的前身是阿里巴巴集团内大规模使用保证分布式事务一致性的中间件，Seata 是其开源产品，由社区维护。在介绍 Seata 前，先与大家讨论下我们业务发展过程中经常遇到的一些问题场景。

业务场景

我们业务在发展的过程中，基本上都是从一个简单的应用，逐渐过渡到规模庞大、业务复杂的应用。这些复杂的场景难免遇到分布式事务管理问题，Seata 的出现正是解决这些分布式场景下的事务管理问题。介绍下其中几个经典的场景：

场景一：分库分表场景下的分布式事务

起初我们的业务规模小、轻量化，单一数据库就能保障我们的数据链路。但随着业务规模不断扩大、业务不断复杂化，通常单一数据库在容量、性能上会遭遇瓶颈。通常的解决方案是向分库、分表的架构演进。此时，即引入了分库分表场景下的分布式事务场景。

场景二：跨服务场景下的分布式事务

降低单体应用复杂度的方案：应用微服务化拆分。拆分后，我们的产品由多个功能各异的微服务组件构成，每个微服务都使用独立的数据库资源。在涉及到跨服务调用的数据一致性场景时，就引入了跨服务场景下的分布式事务。

Seata 架构

• Transaction Coordinator（TC） 事务协调器，维护全局事务的运行状态，负责协调并驱动全局事务的提交或回滚。
• Transaction Manager（TM） 控制全局事务的边界，负责开启一个全局事务，并最终发起全局提交或全局回滚的决议，TM 定义全局事务的边界。
• Resource Manager（RM） 控制分支事务，负责分支注册、状态汇报，并接收事务协调器的指令，驱动分支（本地）事务的提交和回滚。RM 负责定义分支事务的边界和行为。

Seata 的可观测实践

为什么需要可观测？

• 分布式事务消息链路较复杂Seata 在解决了用户易用性和分布式事务一致性这些问题的同时，需要多次 TC 与 TM、RM 之间的交互，尤其当微服务的链路变复杂时，Seata 的交互链路也会呈正相关性增加。这种情况下，其实我们就需要引入可观测的能力来观察、分析事物链路。
• 异常链路、故障排查难定位，性能优化无从下手在排查 Seata 的异常事务链路时，传统的方法需要看日志，这样检索起来比较麻烦。在引入可观测能力后，帮助我们直观的分析链路，快速定位问题；为优化耗时的事务链路提供依据。
• 可视化、数据可量化可视化能力可让用户对事务执行情况有直观的感受；借助可量化的数据，可帮助用户评估资源消耗、规划预算。

可观测能力概览

Metrics 维度

设计思路

1. Seata 作为一个被集成的数据一致性框架，Metrics 模块将尽可能少的使用第三方依赖以降低发生冲突的风险
2. Metrics 模块将竭力争取更高的度量性能和更低的资源开销，尽可能降低开启后带来的副作用
3. 配置时，Metrics 是否激活、数据如何发布，取决于对应的配置；开启配置则自动启用，并默认将度量数据通过 prometheusexporter 的形式发布
4. 不使用 Spring，使用 SPI(Service Provider Interface) 加载扩展

模块设计

• seata-metrics-core：Metrics 核心模块，根据配置组织（加载）1 个 Registry 和 N 个 Exporter
• seata-metrics-api：定义了 Meter 指标接口，Registry 指标注册中心接口
• seata-metrics-exporter-prometheus：内置的 prometheus-exporter 实现
• seata-metrics-registry-compact：内置的 Registry 实现，并轻量级实现了 Gauge、Counter、Summay、Timer 指标

metrics 模块工作流

上图是 metrics 模块的工作流，其工作流程如下：

1. 利用 SPI 机制，根据配置加载 Exporter 和 Registry 的实现类
2. 基于消息订阅与通知机制，监听所有全局事务的状态变更事件，并 publish 到EventBus
3. 事件订阅者消费事件，并将生成的 metrics 写入 Registry
4. 监控系统（如 prometheus）从 Exporter 中拉取数据

TC 核心指标

TM 核心指标

RM 核心指标

大盘展示

Tracing维度

Seata 为什么需要 tracing？

1. 对业务侧而言，引入 Seata 后，对业务性能会带来多大损耗？主要时间消耗在什么地方？如何针对性的优化业务逻辑？这些都是未知的。
2. Seata 的所有消息记录都通过日志持久化落盘，但对不了解 Seata 的用户而言，日志非常不友好。能否通过接入 Tracing，提升事务链路排查效率？
3. 对于新手用户，可通过 Tracing 记录，快速了解 Seata 的工作原理，降低 Seata 使用门槛。

Seata 的 tracing 解决方案

• Seata 在自定义的 RPC 消息协议中定义了 Header 信息
• SkyWalking 拦截指定的 RPC 消息，并注入 tracing 相关的 span 信息
• 以 RPC 消息的发出&接收为临界点，定义了 span 的生命周期范围

基于上述的方式，Seata 实现了事务全链路的 tracing，具体接入可参考为[Seata 应用 | Seata-server]接入 Skywalking [ 1] 。

tracing 效果

• 基于的 demo 场景：

1. 用户请求交易服务
2. 交易服务锁定库存
3. 交易服务创建账单
4. 账单服务进行扣款

• GlobalCommit 成功的事务链路（事例）

Logging 维度

设计思路

Logging 这一块其实承担的是可观测这几个维度当中的兜底角色。放在最底层的，其实就是我们日志格式的设计，只有好日志格式，我们才能对它进行更好的采集、模块化的存储和展示。在其之上，是日志的采集、存储、监控、告警、数据可视化，这些模块更多的是有现成的工具，比如阿里的 SLS 日志服务、还有 ELK 的一套技术栈，我们更多是将开销成本、接入复杂度、生态繁荣度等作为考量。

日志格式设计

这里拿 Seata-Server 的一个日志格式作为案例：

• 线程池规范命名：当线程池、线程比较多时，规范的线程命名能将无序执行的线程执行次序清晰展示
• 方法全类名可追溯：快速定位到具体的代码块
• 重点运行时信息透出：重点突出关键日志，不关键的日志不打印，减少日志冗余
• 消息格式可扩展：通过扩展消息类的输出格式，减少日志的代码修改量

总结&展望

Metrics

总结：基本实现分布式事务的可量化、可观测。展望：更细粒度的指标、更广阔的生态兼容。

Tracing

总结：分布式事务全链路的可追溯。展望：根据 xid 追溯事务链路，异常链路根因快速定位。

Logging

总结：结构化的日志格式。展望：日志可观测体系演进。Seata-go 是 Seata 的多语言规划的重要一环，目前处在高速发展时期，欢迎大家一起加入建设。如果你对 Seata 有任何问题，欢迎通过钉钉搜索群号加入我们。（钉钉群号：33069364）

相关链接：

[1] 为[Seata 应用 | Seata-server]接入 Skywalking

https://seata.io/zh-cn/docs/user/apm/skywalking.html

UGeek大咖说 | 顺丰科技：全链路压测中的可观测性实践

导语

UGeek大咖说是优维科技为技术爱好者研讨云原生技术演进趋势而创办的系列活动，邀请一线互联网大厂的核心骨干主讲，分享原厂实践。本年度主题为可观测，我们希望通过一场场有趣、有料、有深度的活动，让运维圈的小伙伴聚集在一起，深度交流与学习。

一月一期，不见不散！

---

9月27日，UGeek大咖说第九期圆满结束，此次活动特邀到顺丰科技应用架构高级工程师——李卓做客直播间，为我们讲解全链路压测中的可观测性实践。

李老师为我们分享了全链路压测在大型复杂系统中的落地实践案例，也让我们从多个角度，更深地了解到可观测性在全链路压测等级演进中的探索及后续应用，也给我们讲解了顺丰科技的高峰压测变革，介绍了全链路压测在顺丰落地过程中所遇到的挑战，以及他们的应对方式，最后又逐一讲解了可观测性为压测全链路保驾护航三部曲，以及大规模分布式系统下的应用无侵入性能监控的实现。

什么是压测

压测，是保障系统稳定性的一种重要的方法，而链路追踪等可观测技术是压测的关键能力。

那么，可观测在压测领域的落地，会产生什么样的化学反应？我们在面对复杂的系统环境下，又该如何通过获取全链路的追踪数据和指标数据，去实现整个压测过程的可观测性呢？

李老师将会用实际案例带我们一起剖析大型复杂系统下，可观测性在全链路压测中的落地实践。

精华摘录

一技术痛点

随着互联网架构越来越复杂，传统的压测的方式在大规模的分布式系统下变得越来越不可行。主要面临以下几个痛点：

>>01 成本高

多个系统性能测试环境占用的硬件资源较大。性能环境的搭建链路复杂耗时长，人力成本投入巨大。

>>02 容量评估难

容量评估没有统一好执行标准，评估的机器资源到活动时经常发现不准(设备配置差异；设备规模差异),易导致容量瓶颈。

>>03 问题定位难

越来越复杂的应用拓扑，节点之间的调用关系变化比较频繁，系统问题定位越来越难。

>>04 效果验证难

分布式系统的性能指标在测试与真实环境差距较大，参考意义有限。

二高峰保障挑战

系统容量：如何评估大规模分布式系统容量，防止高峰容量评估不准造成的雪崩效应。

系统稳定：线下性能环境与生产环境存在差异性，导致线下压测结果会存在一定的偏差，部分问题无法复现，导致高峰存在风险隐患

保障效率：每年高峰压测，搭建压测环境需要耗时1-2周，压测结束后，环境资源被回收，如此重复，耗费大量人力。

硬件成本：耗费大量资源塔建线下性能测试环境，比如2020年的一次性硬件成本就达到干万以上。

沟通协同：缺少标准化分析定位工具平台通协调多个团队线下分析。

三行业压测性能的演进：从线下到线上

目前整个物流行业基本上已经抛弃了线下做这性能测试，这种方案已经基本上全面的来转到了线上来做生产的全联动压测，从这个线下到线上，大致可以分成以下七个步骤：

四业务侧与技术侧用户痛点

>>用户痛点：业务侧

每年双十一高峰压测面临三个主要问题：压测真实性偏差、成本高、无固定压测环境。

>>用户痛点：技术侧

中间件不统一：中间件框架系统不一样，数百个版本应用组件；

时间成本高：改造时间周期太长；

人才储备少：缺少技术专家来做中间件优化。

五解决方案

适应科技现状，基于JavaAgent全链路压测方案，业务无需改造，JVM层实现压测数据识别和转发。

而在全链路压测阶段会有两个关键特性：

「应用无侵入」的特性避免了业务系统的改造，尤其是涉及到数百应用的改造，不仅成本高，风险也大。

「可观测性」的特性在压测前链路梳理配置，压测中监控告警熔断，压测后性能瓶颈诊断中至关重要。

六全链路压测铁三角

全链路压测是一个非常庞大的体系，这里面涉及到非常多的技术能力，大规模流量仿真，对顺丰和一些双11的流量非常大的互联网企业来讲，要有流量录制和流量回放。流量录制一般是基于脚本去做流量的仿真，但脚本的复杂度有限，很多的链路除了对量有要求，对场景也有很高的要求，通过脚本很难去模拟出真实场景的复杂度的，所以要把生产的流量先录制下来，做相应的脱敏和偏移，然后再通过平台做大规模的这种流量回放。

第二是基于JavaAgent所做的数据安全隔离，包括应用的隔离，以及数据的隔离。全链路压测要常态化、安全。

可观测性在整个压测中有非常重要的地位，包括压测前的内容快速梳理；自动的告警熔断；压测后的性能瓶颈分析，可观测性能够帮助研发快速找到性能瓶颈所在，是一个非常核心的应用。

课堂问答

网友提问：压测过程中，哪些指标是更需要重视的？

讲师解答：压测过程中指标是多方面的，整个的监控体系从基础监控到应用监控、链路监控。都要看平台本身能够提供的类似于apm链路监控，但是在压测过程中间还会看一些基础指标，例如压测时链路正常，但CPU已达到80%-90%的负载，此时已不能继续再压，否则会出现后续问题，数据库同理，有些硬盘容量会在压测过程中持续写入数据，所以压测过程中还需要关注它的容量。

监控是个庞大的体系，单独的apm、应用、基础监控，每一个都是大体系，作为全链路来说，需要关注的是整个链路的综合情况。

网友提问：可观测性在压测中做了什么角色？

讲师解答：压测前是用通过可观测性的半自动化链路配置；压测中是结合监控告警指标，能够做到自动告警和熔断；那压测后的话就是通过agent能够采集到的指标放在压测报告里面，若能够通过apm的指标直接分析，就可以大大加速问题定位的分析效率了。