服务越多,出问题的方式越多
改变一个服务的 API 响应,破坏 5 个消费者。没人知道他们依赖那个字段。
服务绕过 API 直接访问彼此的数据库。'这样更快' 变成技术债务。
API 文档说的是一回事。代码做的是另一回事。消费者依赖未记录的行为。
缺少错误处理、没有熔断器、重试风暴。一个服务宕机,所有服务宕机。
AI 在每个 PR 上执行您的架构决策
AI 分析 OpenAPI 规范、GraphQL 模式和 protobuf。捕获删除、类型更改和破坏性修改。
"从 UserResponse 中删除 'email' 将破坏 OrderService 和 NotificationService。"
定义哪些服务可以通信以及如何通信。标记直接数据库访问和不适当的耦合。
"PaymentService 不应从 UserService 内部导入。请使用公共 API。"
确保服务间调用中有适当的错误处理、超时、重试和熔断器。
"此 HTTP 调用没有超时。添加超时以防止级联故障。"
执行您的 API 版本策略。确保更改遵守向后兼容规则。
"检测到破坏性更改。要么增加 API 版本,要么使此更改具有增量性。"
在发布前就知道