微服务版本最佳实践

Question

我读过Susan Fowler的书＆＃34;生产就绪的微服务＆＃34;在两个地方（直到现在）我找到了

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

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

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

Answer 1

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

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

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

您的业务流程功能必须能够找到符合客户端版本要求的正确服务版本（客户端版本2.6.2＆＃34;输入新订单＆＃34;应用需要服务＆＃ 34; OrderProcessing＆＃34;至少是版本2.4.0以支持NATO产品分类）。

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

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

Answer 2

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

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

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