微服务学习

整体框架

NACO

每个项目模块一启动就会自动注册到注册中心

保存每一个微服务所有可访问的IP和端口号列表

服务发现

服务发现会被封装成自动化的过程，无需我们手动调用

注解式负载均衡实现

有了@LoadBalanced注解，restTemplate就能自发实现负载均衡

service-product是注册在nacos的服务名

NACOs总结

第三方API

4. Sentinel

服务保护(限流、熔断降级)

异常处理

探测请求

5.Gateway 网关

6.Seata

分布式事务

Seata (Simple Extensible Autonomous Transaction Architecture) 是阿里巴巴开源的，专门用于解决分布式事务问题的组件。

在微服务架构中，Seata 被称为"数据一致性的守护者"。

1. 为什么要用 Seata？（痛点）

在单体应用（一个项目连一个数据库）时代，Spring 的 @Transactional 注解就能完美解决事务问题：要么全成功，要么全失败（回滚）。

但是在微服务架构下，业务逻辑跨越了多个服务，每个服务连着自己的数据库：

• 订单服务 -> 连 订单数据库

• 库存服务 -> 连 库存数据库

场景： 用户下单。

1. 订单服务 创建了一条订单（事务提交了）。

2. 调用 库存服务 扣减库存，但是报错了/超时了。

结果： 订单生成了（钱扣了），但库存没减。数据不一致了！

传统的 @Transactional 管不了跨服务、跨数据库的操作。这时候就需要 Seata 出场了。

---

2. 餐厅比喻：旅行团套餐

为了让你理解 Seata 的工作原理，我们继续用餐厅的比喻。

这次是预订全套宴席，需要同时协调：

• 后厨（负责做菜）

• 酒水吧台（负责备酒）

• 包间管理（负责留房间）

这三个部门就像三个微服务。

没有 Seata 时：

你告诉后厨做菜（后厨做好了），告诉吧台备酒（吧台做好了），告诉包间留房（包间说满了）。

结果：菜和酒都浪费了，因为没有房间，客人根本吃不了。你想退菜，后厨说"我都做熟了，退不了"。

有了 Seata (分布式事务协调者)：

有一个专门的 "宴席总管" (TC - Transaction Coordinator)。

1. 第一阶段 (准备/尝试)：

   • 总管对所有部门说："大家注意，现在开启一个'宴席A'的事务。"

   • 总管 -> 后厨："菜切好，准备下锅（别急着盛出来）。" -> 后厨回应：OK。

   • 总管 -> 吧台："酒拿出来，放桌上。" -> 吧台回应：OK。

   • 总管 -> 包间："留个房间。" -> 包间回应：不行，满了！

2. 第二阶段 (决断)：

   • 总管收到一个"不行"，立马通过对讲机大喊："全体回滚 (Rollback)！"

   • 后厨：把切好的菜放回冰箱（恢复原状）。

   • 吧台：把酒放回酒柜（恢复原状）。

   • 结果： 就像什么都没发生过一样，保证了数据的一致性。

---

3. Seata 的核心角色

Seata 定义了三个核心角色（缩写很重要，面试常考）：

1. TC (Transaction Coordinator - 事务协调者)：

   • 就是上面的"宴席总管"。它是一个独立的服务器（Seata Server），维护全局事务的状态，决定是提交还是回滚。

2. TM (Transaction Manager - 事务管理器)：

   • 事务的发起者（比如"订单服务"中的下单方法）。它告诉 TC："我要开启一个全局事务"。

3. RM (Resource Manager - 资源管理器)：

   • 各个微服务（库存服务、余额服务）。它们负责执行具体的 SQL，并向 TC 汇报状态。

4. Seata 是怎么做到的？(最常用的 AT 模式)

Seata 最强大的地方在于它的 AT 模式 （Automatic Transaction），它是对代码无侵入的。你几乎不需要改代码，只需要加一个注解。

它的"黑科技"在于 undo_log (回滚日志表)。

详细流程举例：

假设库存表 stock，商品 ID=1 目前有 100 个。要减 1 个。

第一阶段 (执行并记录)：

1. 库存服务 (RM) 收到扣减请求。

2. Seata 拦截 SQL。

3. 查询前镜像 (Before Image)： 查一下现在是多少？(100)。

4. 执行 SQL： update stock set count = 99 where id = 1。

5. 查询后镜像 (After Image)： 查一下改完是多少？(99)。

6. 生成回滚日志： 把"本来是100，改成了99"这条记录，存入数据库的一张特殊表 undo_log 中。

7. 提交本地事务： 真的把数据库改了（释放锁，提高效率）。

8. 报告 TC： 我这边搞定了！

第二阶段 (提交或回滚)：

• 如果一切顺利 (Commit)：

  • TC 通知 RM："提交！"

  • RM 只需要异步 删除掉 undo_log 里那条记录即可（因为已经改对了，不需要留后路了）。

• 如果出事了 (Rollback)：

  • TC 通知 RM："回滚！"

  • RM 拿出 undo_log 里的记录，根据"前镜像"生成反向 SQL。

  • 执行：update stock set count = 100 where id = 1。

  • 数据神奇地恢复了！

5. 代码怎么写？

在 Spring Cloud 中使用 Seata 非常简单，核心就是一个注解：@GlobalTransactional。

在发起事务的服务（比如订单服务）中：

Java

@Service
public class OrderService {

    @Autowired
    private StockClient stockClient; // Feign客户端
    @Autowired
    private AccountClient accountClient; // Feign客户端

    // 只需要加上这个注解，Seata 就会自动接管
    // 如果下面任何一步报错，所有涉及的服务都会回滚
    @GlobalTransactional(name = "create-order-tx", rollbackFor = Exception.class)
    public void createOrder(String userId, String commodityCode, int count) {
        
        // 1. 本地操作：创建订单
        orderMapper.insert(new Order(userId, commodityCode, count));
        
        // 2. 远程调用：扣减库存 (如果这里报错，上面的订单会消失)
        stockClient.deduct(commodityCode, count);
        
        // 3. 远程调用：扣减余额 (如果这里余额不足报错，库存会加回去，订单会消失)
        accountClient.debit(userId, count * 10);
    }
}

6. Seata 的四种模式（了解即可）

1. AT 模式 (最推荐)： 自动化，强一致性，代码无侵入。适合绝大多数业务（类似上面的例子）。

2. TCC 模式 (高性能)： 需要自己写代码实现 Try (尝试), Confirm (确认), Cancel (取消) 三个方法。性能高但开发极其麻烦。

3. Saga 模式： 长事务解决方案，适用于业务流程很长的情况。

4. XA 模式： 数据库原生支持的协议，最安全但性能最差。

总结

• Seata 的作用： 保证微服务之间操作数据库时，要么一起成功，要么一起失败。

• Seata 的核心： TC (指挥官), TM (发起者), RM (参与者)。

• Seata 的神器： undo_log 表，用来记录数据修改前后的样子，方便出错时"时光倒流"。

• 对应关系： 如果说 Nacos 是微服务的"电话本"，OpenFeign 是"对讲机"，那 Seata 就是微服务世界的"公证处/仲裁庭"。

你之前的项目中有遇到过数据不一致的问题吗？或者需要在你的 Spring Cloud 项目中集成 Seata 吗？我可以发给你对应的配置参考。

ES

什么是RestClient

ES官方提供了各种不同语言的客户端，用来操作ES。这些客户端的本质就是组装DSL语句，通过http请求发送给ES。