使用 nServiceBus 和 REST API 进行 API 版本控制和长时间运行的进程答案

【问题标题】：API Versioning and long running processes with nServiceBus and REST API使用 nServiceBus 和 REST API 进行 API 版本控制和长时间运行的进程
【发布时间】：2012-08-24 05:04:48
【问题描述】：

我们正在构建一个 Web API 并使用 nServiceBus 为所有异步和长时间运行的进程在后台进行消息传递。

问题是当我们推出新版本的 API 时，是否应该使用一组新的队列？

例如，对于 API 版本 1，

blobstore.v1.inbound
blobstore.v1.outbound
blobstore.v1.timeout
blobstore.v1.audit

对于 API 版本 2，

blobstore.v2.inbound
blobstore.v2.outbound
blobstore.v2.timeout
blobstore.v2.audit

或者我们应该努力使用具有多种消息格式和处理程序的同一组队列（假设需求变化和不断发展的消息格式）？

我试图从架构的角度了解长期的利弊。拥有一组单独的队列可以灵活地单独构建、部署和管理不同的 API 版本，而无需担心兼容性和社交性。

我个人倾向于后者，但围绕兼容性和升级的挑战尚不清楚。

如果您过去曾处理过类似的情况，请分享您的经验、想法、建议和建议。

非常感谢您的宝贵时间！

【问题讨论】：

标签： api architecture versioning nservicebus

【解决方案1】：

您的发布越频繁，每个版本的队列策略就越不合适，向后兼容性变得越重要（无论是在结构上还是在行为上）。

【讨论】：

同意，在同一版本的 API 中会有多个版本，并且这些版本之间的消息兼容性将保持不变。根据我们当前的 API 策略，只有在发生重大更改时才会发生主要版本更改。但关键是，这种重大变化可能根本与消息传递无关，它可能与身份验证、存储等有关。因此，无论是否有消息修订，围绕主要 API 版本修订的队列版本化都存在争议。跨度>

【解决方案2】：

是使用一组不同的队列还是使用单个队列来支持不同版本的消息取决于消息之间差异的程度。在versioning sample 中，V2 消息是 V1 消息的纯扩展，可以通过接口继承来表示。 V1 消息的订阅者可以接收 V2 消息，它们是 V1 消息的适当超集。在这种情况下，保持相同的队列并仅根据需要更新订阅者是有意义的。如果消息完全不同，则部署第二组队列可能更容易。这具有您描述的好处，即隔离。您不必担心会弄乱依赖组件。但是，这将对您的系统产生更大的影响，因为您必须考虑可能依赖于队列的所有内容。您可能必须同时部署多个端点和服务才能完成 V2 的推出。

【讨论】：

是的，但与此同时，如果我们使用多个队列，操作开销是我们引入的主要内容之一。使用最少设置的一大好处是减少了生产监控工作。这绝对是优势。