Seata整合后的基础检验

在验证前，需要启动 Nacos Server 和 Seata Server。成功启动这两个中间件后，依次启动 goods-service-demo、order-service-demo 和 shopcart-service-demo 这三个项目。上述的两个中间件和三个 Spring Boot 项目，如果未能成功启动，则开发人员需要查看控制台中的日志是否报错，并及时确认问题和修复。启动成功后进入 Nacos 控制台，单击 “服务管理” 中的服务列表，可以看到服务列表中已经存在三个服务和 Seata Server 的服务信息，如图 10-21 所示。

三个微服务实例和 Seata Server 都启动成功，并且成功注册到 Nacos Server 中，验证通过。

接下来验证数据源是否被 Seata 成功接管。

直接查看 goods-service-demo、order-service-demo 和 shopcart-service-demo 这三个项目的控制台即可，如图 10-22 所示。

相较于整合 Seata 组件前，整合后的启动日志代码明显增多，也能够明显看到 DataSourceProxy 相关的日志。

开启 Seata 对数据源的代理，验证通过。

如果没有看到类似的日志，就需要检查一下哪个步骤出了问题，而且三个微服务实例都需要有上述的这些日志输出才行。

最后需要验证微服务实例与 Seata Server 是否通信成功。验证时不需要开发人员做额外的操作，微服务实例启动成功后，只需要耐心等待半分钟左右，观察 IDEA 编辑器的控制台以及 Seata Server 的最新日志即可。

以 goods-service-demo 项目为例，如果成功与 Seata Server 建立通信连接，就能够在 IDEA 编辑器的控制台中看到如图 10-23 所示的日志信息。

可以看到在项目启动成功后的一段时间，出现了 goods-server 已经成功注册到 Seata Server 中的相关日志输出。

同样地，在 Seata Server 的启动界面也可以看到如下的日志信息。

这属于完完全全地 “双向奔赴” 了。

服务实例与 Seata Server 之间的通信建立成功，验证通过。

读者需要注意，本节的示例中有三个微服务实例项目，除本节提到的 goods-service-demo 外，另外两个项目的日志信息也与笔者提供的日志信息类似。读者在练习时一定要认真观察这些日志信息，如果某个项目中没有类似的日志输出，那就是未能成功与 Seata Server 建立通信，需要检查代码是否有问题。以上是微服务实例与 Seata Server 通信成功的日志输出，如果未能通信成功，在控制台上看到的日志就是与 “failure”、“error” 相关的日志了。

在微服务架构的项目中整合 Seata 中间件的编码和配置已经完成。接下来将测试整合 Seata 组件后的微服务实例，在同样的业务逻辑和代码下，验证 10.1.3 节中出现的分布式问题是否继续存在。之后笔者会结合代码讲解并分析 Seata 处理分布式事务的步骤和原理，让读者更加深入和全面地了解 Seata 中间件。