2

假设我们使用基于接口的消息契约，例如为 MassTransit 推荐的。

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

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

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

或者我们应该有一个升级窗口，所有应用程序同时更新？

如果您正在查看相同的内容，请查看答案和评论。
真的在这里得到了一些质量反馈：D

4

2 回答 2

3

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

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

看起来工作量很大，但如果你从一开始就设计成那样工作，那还不错，而且确实有回报。

于 2019-10-15T09:34:39.693 回答
3

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

有很多关于合同版本控制的很好的指导方针，那里没有任何特定于 MassTransit 的内容。

另一方面，MassTransit 在文档中提供了一些关于如何处理消息版本的建议。特别是，如果您遵循弱模式方法并添加可以为空且对消费者不重要的属性，我们建议不要创建新版本。此外，您可以使用接口组合，例如文档中的这个示例：

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，您需要考虑向后兼容性并在一段时间内同时使用旧消息和新消息。给人们一些时间从一个版本更改为另一个版本，并在需要时终止旧版本。

于 2019-10-15T11:47:58.507 回答