(资料图)

点击链接阅读原文，获取更多技术内容：

作者：察溯

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 指标

阿里云开发者社区，千万开发者的选择。百万精品技术内容、千节免费系统课程、丰富的体验场景、活跃的社群活动、行业专家分享交流，尽在：