Как версии контрактов сообщений для сервисных автобусов?

Question

Допустим, мы используем контракты сообщений на основе интерфейсов, как рекомендуется, например, для MassTransit.

Во-первых, как эти интерфейсы используются всеми приложениями? Допустим, мы предоставляем их в пакете nuget. (Это путь?)

Итак, во-вторых, как нам теперь убедиться, что все приложения используют одну и ту же версию?

Должны ли мы каждый раз использовать новые интерфейсы (например, messageV1, messageV2) быть обратно совместимым? Это потребовало бы от нас отправки нескольких сообщений одновременно вместо 1 ...

Или у нас должно быть окно обновления, где все приложения обновляются одновременно?

---

ПожалуйстаПроверьте и ответы, и комментарии, если вы смотрите в одно и то же.
Действительно получил здесь несколько качественных отзывов: D

Answer 1

Контракты с сообщениями не отличаются от любых других контрактов API, и вы относитесь к ним соответственно. Рассматривайте любой общедоступный API как нечто, что появилось в мире, и вы не можете контролировать всех, кто использует API.

Существует довольно много хороших рекомендаций по версионированию контрактов, и там нет ничего специфического для MassTransit.

MassTransit, с другой стороны, предлагает несколько советов о том, как работать с версиями сообщений в документация . В частности, мы предлагаем не создавать новую версию, если вы следуете подходу Weak Schema и добавляете свойства, которые могут быть пустыми и не важными для потребителя. Кроме того, вы можете использовать состав интерфейса, как в этом примере из документов:

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 между подсистемами
• Новые интерфейсы создаются при измененияхнеобходимо сделать, интерфейсы только когда-либо расширены с изменяемыми значениями обратно / обратно совместимы
• При необходимости, несколько сообщений публикуются / отправляются для сохранения обратной совместимости
• Когда больше нетЕсли нужно, более старые версии могут быть устаревшими / удалены

Это может показаться большой работой, но если вы с самого начала разрабатываете вещи таким образом, это не так уж плохо и действительно окупается.