总结

代码只是做了最基本的微服务下单流程模拟，没有涉及 RocketMQ、API网关等。后续有机会再补充。

性能的进一步提升

依据 微服务性能测试 来看，性能瓶颈大概率来自基础组件。

例如分布式事务。其它可以横向拓展，分布式事务目前还无法如此搞。

分布式事务需要通过硬件提升负载能力，或者依据事务类型+全局锁打散到多个Seata服务中去（将 useTCCFence 逻辑实现再 redis 上，也能提升性能）。

Seata 也提供了 Raft 版本，理论上性能会有更大提升，但 TiDB 等分布式数据库也是基于 Raft协议来做的，是否考虑直接切换至分布式数据库去解决单机瓶颈会更省力些？

至于其它基础组件瓶颈，则要依据各组件的benchmark来看。例如 Redis 单实例set指令benchmark性能在15w/s，考虑到下单会涉及多个redis指令和lua，要以10w/s的库存增减操作来容错考量。若10w/s都无法满足，就必须引入 Redis Cluster 或其它更快的内存计算组件，例如VoltDB，逻辑层可将库存拆分成多个小库存，再或者从业务逻辑上减少碰撞（下单只有一件商品）。库存数据库落盘也需要走合并变更一次改动的套路，尤其是 PG 这种每次变动都会生成快照的数据库，通过减少写次数而提升吞吐。

基本上每一块业务逻辑都需要改写，大致会走 使用队重构 RPC 的路数。

线程池数量、Linux 网络参数、Http2/Http3 等配置，都需要调教。

更底层技术：JVM、Linux 内核、服务器硬件、路由器等都需要做适应性改造。

...

以上所有优化的前提是 Metric 跟踪平台搭建到位