假设我们有两个微服务：客户端和服务器。微服务架构最基本的特性之一是能够为每个微服务拥有单独的管道，这意味着我们必须能够独立地将它们部署到生产中。
这意味着不同的微服务可能由不同的团队开发，并且某些功能在一个微服务上的开发速度要快于在另一个微服务上的开发速度。这通常会导致客户端和服务器之间的合同（接口）被破坏，因此客户端发送到服务器的 JSON 不再有效。
问题是如何防止两个微服务之间的通信由于它们之间的合同损坏而中断的情况？处理此类问题的最佳策略是什么？
【问题讨论】：
标签： java microservices
一种解决方案是端点版本控制。假设您的微服务是 REST API，您可以指示您的团队增加 API 端点的版本，如果他们对该端点所做的任何更改都会破坏它。遵循一个弃用周期，并在 6 个月后删除对旧端点的支持。它让您有时间切换到较新的版本，并且不会破坏依赖旧版本的任何内容。
另一个解决方案是使用编排层，而不是微服务与微服务通信。也就是说，一些微服务管理器将任何微服务抽象为微服务通信。将成为微服务消费者的应用程序然后成为编排层的消费者，编排层决定需要调用哪个微服务 api。如果 API 合同发生更改，这最终仍会导致合同中断问题，但您可以在所有集中的编排层修复它，而不是协调跨团队微服务更改。
【讨论】：
客户端微服务团队应该为合同编写测试套件，并让它们在服务器微服务的构建管道中运行。这可以作为 CI-CD 的一部分自动化。因此，服务器微服务团队将立即知道他们的更改对其他客户端团队的影响。
【讨论】：
问题是如何防止两个人之间发生通信的情况 微服务由于它们之间的合同破裂而被破坏？
合同设计：在您设计合同时，服务器 [也称为服务提供者或生产者] 无法指定合同，而只是说这是我提供的合同和现在去消费服务。如果服务器有多个客户端（通常是这种情况），那么多个客户端将给出他们对合约的“需求”，然后服务器将实现最小的公共聚合作为服务提供。
合同变更：在大多数情况下，服务提供商应努力使合同保持与后缀兼容。但是，如果合同需要重大更改，则可以通过启动新版本的端点来处理。在这种情况下，旧服务端点（例如 v1）的退役不会立即完成。服务消费者会收到此更改的通知，并有时间切换到更新版本的合同。 （例如 v2）
您可以获取有关 Martin Fowler bliki 的更多信息：https://martinfowler.com/articles/consumerDrivenContracts.html
处理此类问题的最佳策略是什么？
我想，我已经回答了上面的策略。但是，在工具方面，以下是一些有助于该场景的工具：
【讨论】：