微服务版本最佳实践

Posted 2021-05-01

我读到Susan Fowler的书“生产就绪微服务”并且在两个地方（直到现在）我找到了

• （第26页）“避免版本控制微服务和端点”，
• “版本化微服务很容易成为组织的噩梦”（第27页），
• 在微服务生态系统中，不鼓励对微服务进行版本控制（第58页）

无论如何，我使用所有类型的版本控制所有类型的不同项目：git标签，deb软件包版本控制，python软件包版本控制，http api版本，我从来没有遇到过很大的问题来管理项目的版本。除此之外，我确切地知道在出现一些故障或客户错误的情况下推出的版本。

任何人都有任何线索为什么在本书中微服务版本控制如此受到指责，你对这个主题有什么建议？

答案

您确定她不是在谈论将版本合并到服务名称或端点名称中吗？名为OrderProcessing_2_4_1且版本化端点为get_order_2_4_1的服务是一个非常糟糕的主意。具有版本化端点get_order_2_4的OrderProcessing_2_4稍微不那么邪恶，但仍然存在问题。

如果您对微服务的调用必须解决名称中具有版本号的端点，那么每次更改服务时都会遇到维护（和生产）噩梦。必须检查每个其他服务和客户端以更改对更新服务的任何引用。

这与您的API，代码pr服务的版本不同。如果您要实际获得微服务的许多好处，那么这些是必需的。

您的业​​务流程功能必须能够找到符合客户端版本要求的正确服务版本（客户端“输入新订单”版本2.6.2应用程序需要至少版本为2.4.0的服务“OrderProcessing”才能支持北约产品分类）。

您可能同时在生产中使用多个版本的服务（2.4.0已被弃用但仍在为某些客户端提供服务，2.4.1正在推出，3.0.0版测试版用于测试最新UI和之前的功能的客户GA）。

如果您全天候运行并且必须动态更新服务，则尤其如此。业务流程功能是服务和端点匹配的位置，当您引入新版本的服务时，您更新业务流程数据库以描述所需的其他服务的版本。 （我的OrderProcessing的新版本2.4.1需要ProductManager的2.2.0或更高版本，因为这是将NATO产品分类添加到产品数据中的时候）。

另一答案

本书的作者是正确的，因为很难更新API的版本，特别是如果它很受欢迎。这是因为您必须要么追捕旧版本的所有用户并让他们升级，要么您必须同时支持生产中的两个版本的软件。

但你仍然应该修改你的API，恕我直言。永远不要更改API版本。您应该支持API中的版本的原因是因为您永远不知道何时可能需要更改它。所以添加版本，但你应该避免每一次更改它。在许多情况下，以不破坏当前版本合同的方式更容易启动新API或扩展现有API。

顺便说一句，在未来你永远不会知道新技术或设计模式何时会实现，这将允许一个API的两个版本以非常优雅的方式在生产中的同一软件实例上轻松存在。如果出现类似的内容，那么您可能会在API中看到更多版本更改。