Java 如何保证两个微服务之间的接口不被破坏？

假设我们有两个微服务：客户端和服务器。微服务体系结构最基本的特征之一是能够为每个微服务提供单独的管道，这意味着我们必须能够独立地将它们部署到生产环境中

这意味着不同的团队可以开发不同的微服务，并且在一个微服务上开发的某些功能比在另一个微服务上开发的更快。这通常会导致客户机和服务器之间的契约（接口）被破坏，因此客户机发送给服务器的JSON不再有效

---

问题是如何防止两个微服务之间的通信因其之间的合同破裂而中断的情况？处理此类问题的最佳策略是什么？

一种解决方案是端点版本控制。假设您的微服务是RESTAPI，您可以指示您的团队增加API端点的版本，如果他们对该端点所做的任何更改都会破坏它。遵循一个弃用周期，6个月后删除对旧端点的支持。它让您有时间切换到较新的版本，而不会破坏任何依赖旧版本的功能

---

另一个解决方案是，使用编排层，而不是微服务与微服务对话。也就是说，一些微服务的管理者将任何微服务到微服务的通信抽象出来。作为微服务消费者的应用程序随后成为编排层的消费者，编排层决定需要调用哪个微服务api。如果API契约发生更改，这仍然会导致契约中断问题，但您可以在业务流程层进行修复，在该层中，它是集中的，而不是协调跨团队的微服务更改。

客户端微服务团队应该为合同编写测试套件，并让它们在服务器微服务的构建管道中运行。这可以作为CI-CD的一部分实现自动化。因此，服务器微服务团队将立即知道他们的更改对其他客户机团队的影响

问题是如何防止两人之间的交流 微服务是因为它们之间的合同破裂而破裂的吗

合同设计：当您设计合同时，服务器[也称为服务提供商或生产商]不能指定合同，只能说这是我提供的合同，现在就去消费服务。如果服务器有多个客户机（通常是这种情况），那么多个客户机将给出他们对合同的“需求”，然后服务器将实现最小的公共聚合服务

合同变更：服务提供商应在大多数情况下努力使合同与背景词兼容。然而，若合同需要重大变更，那个么可以通过旋转端点的新版本来处理。在这种情况下，不会立即停用旧的服务端点（例如v1）。服务消费者将收到此更改的通知，并有时间切换到更新版本的合同。（比如说v2）

您可以获得有关Martin Fowler的bliki的更多信息：

处理此类问题的最佳策略是什么

我想，我已经回答了上述策略。然而，在工具方面，以下是一些有助于实现场景的工具：

契约：

领事：这是一个服务发现工具，但是，如果你采用微服务，那么它对于处理大量的服务将非常有用

---

合同测试？雇佣懂得如何测试合同的QA人员？编写一个正确定义JSON的契约规范？