在本地快速构建微服务集群(秒杀抢购和订单功能)来验证测试，个人感觉使用 dtm 来解决分布式事务还是挺优雅的，而且使用也比较简单。
gvison 2024-10-13 23:17:51 +08:00 1566 次点击这是一个创建于 370 天前的主题，其中的信息可能已经有所发展或是发生改变。
这是验证秒杀抢购和订单功能的 8 个服务框架图：
| 服务 | 协议 | HTTP 端口 | gRPC 端口 |
|---|---|---|---|
| eshop_gw 内聚 api 网关服务 | HTTP | 8080 | - |
| user 用户服务 | HTTP, gRPC | 30080 | 30082 |
| product 产品服务 | HTTP, gRPC | 30180 | 30182 |
| order 订单服务 | HTTP, gRPC | 30280 | 30282 |
| stock 库存服务 | HTTP, gRPC | 30380 | 30382 |
| coupon 优惠券服务 | HTTP, gRPC | 30480 | 30482 |
| pay 支付服务 | HTTP, gRPC | 30580 | 30582 |
| flashSale 秒杀抢购服务 | HTTP, gRPC | 30680 | 30682 |
使用负载测试工具 k6 分别对秒杀抢购 api和提交订单 api进行压测，验证最终的数据一致性正确。压测结果与机器配置、网络环境、数据库配置等因素有关，这里不展示压测数据了。
注：源码的 2 个目录下代码基本一样，只是代码组织结构稍有不同，一个是微服务多仓库(multi-repo)代码组织结构，另一个是微服务单仓库(mono-repo)代码组织结构，8 个服务代码是生成的，然后按照生成的示例模板编写具体的业务逻辑代码。
目前尚无回复
Select Language