Question

假设我们使用基于接口的消息协定，例如对于MassTransit的建议。

首先，这些接口如何在所有应用程序之间共享？假设我们以nuget包的形式提供它们。（这是要走的路吗？）

第二，我们现在如何确保所有应用程序使用相同版本？

我们是否应该每次都使用新接口（例如messageV1，messageV2）向后兼容？这将要求我们一次发送多个消息，而不是1 ...

还是我们应该有一个升级窗口，其中所有应用程序都在同一时间更新？

如果要查找答案和注释，请同时查看答案和注释。
真的在这里得到了一些质量反馈：D

Answer 1

消息合同与任何其他类型的API合同都没有不同，您可以相应地对待它们。将任何公共API视为已流行的东西，您无法控制使用该API的每个人。

关于合同版本控制的指南很多，那里对于MassTransit而言并没有什么特别的。

另一方面，

MassTransit提供了有关如何处理the documentation中的消息版本的一些建议。特别是，如果您遵循“弱模式”方法并添加可以为空且对使用者不重要的属性，则建议不要创建新版本。此外，您可以使用界面组合，例如来自文档的以下示例：

class RemoteImageCachedEvent :
    RemoteImageCached,
    RemoteImageCachedV2
{
    Guid EventId { get; set; }
    DateTime Timestamp { get; set; }
    Guid InitiatingCommandId { get; set; }
    Uri ImageSource { get; set; }
    string LocalCacheKey { get; set; }
    Uri LocalImageAddress { get; set; }
}

因此，当您发布RemoteImageCachedEvent的实例时，它将被传递到两个接口的消息交换。

如果您完全改变了API的外观（是消息，Grpc或REST），则需要考虑向后兼容性，并在一段时间内同时使用新旧消息。给人们一些时间从一个版本转换到另一个版本，并在需要时终止旧版本。

Answer 2

MassTransit不明确支持任何类型的版本控制，因此您可以自由选择执行自己认为最佳的版本。您在问题中所做的假设或多或少完全是我做事的方式：

合同在各个子系统之间作为nuget包共享
当需要进行更改时会创建新的接口，接口只能进行扩展且具有可为空/向后兼容的更改
如有必要，将发布/发送多条消息以保持向后兼容性
当不再需要时，旧版本可以被废弃/删除

这似乎是一项艰巨的工作，但是如果您从一开始就设计出能够以这种方式工作的东西，那还不算太糟，而且确实会有所收获。

服务总线的消息合同如何版本化？

2 个答案: