整体框架

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。