Как поделиться кодом событий в микросервисной архитектуре - PullRequest
Новая
       44

Как поделиться кодом событий в микросервисной архитектуре

0 голосов
/ 08 марта 2019

Я работаю над «микросервисной» архитектурой. Каждый микросервис может запускать некоторые события в RabbitMQ. События идентифицируются кодом события. На данный момент код инициируемого события является жестко закодированной константной строкой, объявленной внутри микросервиса, который запускает событие. Моя проблема в том, что каждый микросервис, который хочет подписаться на это событие, должен дублировать эту строку кода события. Это подвержено ошибкам, особенно когда код события переименован, потому что все микросервисы, которые подписались на этот код события, должны быть изменены соответствующим образом ... что очень плохо.

Я вижу возможные альтернативы:

  • Объявите код события только в микросервисе, который инициирует событие. Предоставьте потребителям микросервисы прямой доступ к коду, объявленному в микросервисе, который инициирует событие. В этом случае событие объявляется один раз, но оно создает зависимость исходного кода между микросервисами ... что плохо.

  • Создайте исходный файл (вне всех микросервисов), который содержит весь код событий всего приложения. Этот исходный файл является общим для всех микросервисов. В этом случае каждое событие объявляется один раз, но оно создает глобальную зависимость для всех микросервисов, что противоречит принципу единой ответственности ... что плохо.

Как вы решаете эту проблему?

1 Ответ

1 голос
/ 08 марта 2019

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

События сообщения . Все ограничения, которые мы используем для управления развитием сообщений, применимы и к событиям.

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

На практике это означает что-то вроде

  • Мы никогда не вводим новое обязательное поле, только дополнительные поля (с задокументированными значениями по умолчанию).
  • Нераспознанные поля игнорируются (но пересылаются)
  • Потребители необязательных полей знают, как использовать значение по умолчанию, используемое при отсутствии ожидаемого поля.
  • Когда эти ограничения не могут быть выполнены, вы вводите новое сообщение.

Если у вас есть контракты с сообщениями, то вы не ограничиваете себя реализациями микросервисов, которые используют одну и ту же платформу времени выполнения (поскольку две разные реализации одного и того же контракта эквивалентны).

Рекомендуем прочитать:

...