作者：察溯
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 维度
设计思路
- Seata 作为一个被集成的数据一致性框架，Metrics 模块将尽可能少的使用第三方依赖以降低发生冲突的风险
- Metrics 模块将竭力争取更高的度量性能和更低的资源开销，尽可能降低开启后带来的副作用
- 配置时，Metrics 是否激活、数据如何发布，取决于对应的配置；开启配置则自动启用，并默认将度量数据通过 prometheusexporter 的形式发布
- 不使用 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 模块的工作流，其工作流程如下：
- 利用 SPI 机制，根据配置加载 Exporter 和 Registry 的实现类
- 基于消息订阅与通知机制，监听所有全局事务的状态变更事件，并 publish 到EventBus
- 事件订阅者消费事件，并将生成的 metrics 写入 Registry
- 监控系统（如 prometheus）从 Exporter 中拉取数据
TC 核心指标
TM 核心指标
RM 核心指标
大盘展示
Tracing维度
Seata 为什么需要 tracing？
- 对业务侧而言，引入 Seata 后，对业务性能会带来多大损耗？主要时间消耗在什么地方？如何针对性的优化业务逻辑？这些都是未知的。
- Seata 的所有消息记录都通过日志持久化落盘，但对不了解 Seata 的用户而言，日志非常不友好。能否通过接入 Tracing，提升事务链路排查效率？
- 对于新手用户，可通过 Tracing 记录，快速了解 Seata 的工作原理，降低 Seata 使用门槛。
Seata 的 tracing 解决方案
- Seata 在自定义的 RPC 消息协议中定义了 Header 信息
- SkyWalking 拦截指定的 RPC 消息，并注入 tracing 相关的 span 信息
- 以 RPC 消息的发出&接收为临界点，定义了 span 的生命周期范围
基于上述的方式，Seata 实现了事务全链路的 tracing，具体接入可参考为[Seata 应用 | Seata-server]接入 Skywalking[1]。
tracing 效果
- 基于的 demo 场景：
- 用户请求交易服务
- 交易服务锁定库存
- 交易服务创建账单
- 账单服务进行扣款
- GlobalCommit 成功的事务链路（事例）
Logging 维度
设计思路
Logging 这一块其实承担的是可观测这几个维度当中的兜底角色。放在最底层的，其实就是我们日志格式的设计，只有好日志格式，我们才能对它进行更好的采集、模块化的存储和展示。在其之上，是日志的采集、存储、监控、告警、数据可视化，这些模块更多的是有现成的工具，比如阿里的 SLS 日志服务、还有 ELK 的一套技术栈，我们更多是将开销成本、接入复杂度、生态繁荣度等作为考量。
日志格式设计
这里拿 Seata-Server 的一个日志格式作为案例：
- 线程池规范命名：当线程池、线程比较多时，规范的线程命名能将无序执行的线程执行次序清晰展示
- 方法全类名可追溯：快速定位到具体的代码块
- 重点运行时信息透出：重点突出关键日志，不关键的日志不打印，减少日志冗余
- 消息格式可扩展：通过扩展消息类的输出格式，减少日志的代码修改量
总结&展望
Metrics
总结：基本实现分布式事务的可量化、可观测。展望：更细粒度的指标、更广阔的生态兼容。
Tracing
总结：分布式事务全链路的可追溯。展望：根据 xid 追溯事务链路，异常链路根因快速定位。
Logging
总结：结构化的日志格式。展望：日志可观测体系演进。Seata-go 是 Seata 的多语言规划的重要一环，目前处在高速发展时期，欢迎大家一起加入建设。如果你对 Seata 有任何问题，欢迎通过钉钉扫码或搜索群号加入我们。（钉钉群号：33069364）
相关链接：
[1] 为[Seata 应用 | Seata-server]接入 Skywalking
