我读到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产品分类添加到产品数据中的时候).