Микросервисные модели входных и выходных доменов - PullRequest
0 голосов
/ 05 октября 2018

Я использую Kafka для развязки своих сервисов, но несколько секунд думаю о том, как сервисы потребляют и производят входы и выходы.

Если у меня есть сервис A, который получает данные от некоторого внешнегоиз-за неконтролируемого обслуживания я вынужден адаптироваться к формату данных (домену), предоставляемому внешней системой.Следуя такой практике, мой сервис A отправляет свои результаты в тему в своем собственном формате (домен).

Кстати, у меня есть сервис B, который делает то же самое, что сервис A, но использует какой-то другой внешний сервис,и имеет свой собственный формат данных (домен), который он выдвигает в отдельную тему.

Теперь семантика данных, создаваемых A и B, похожа, но не одинакова.Но следующим шагом в конвейере является служба C, которая должна потреблять как то, что производят A, так и B, что-то делать с ней и выплевывать результаты.

Если C знает, как использовать данные только из одного места,что подразумевало бы, что A & B (и любые другие в будущем) должны производить свои выходные данные в специфической для C области?Это означало бы, что если потребитель C когда-либо изменит свой домен, то A, B и любые другие производители должны будут измениться, что мне не нравится.Кроме того, если я добавлю другого потребителя, например, D, это означает, что A и B, используя эту аналогию, должны знать, что D также является их потребителем, что для меня ужасно.

Я думал, что Cдолжен нести ответственность за свои входные данные, то есть он зависит от моделей A и B (и любых других, которые могут создавать свои собственные данные).Это также подразумевает, что при добавлении нового источника C необходимо также изменить на эти данные.

По сути, я склоняюсь к компоненту ManySources-OneSink, а не к OneSource-ManySinks.

Есть ли предпочтительные практики?

Ответы [ 4 ]

0 голосов
/ 09 октября 2018

То, о чем вы говорите - это контекстное отображение.Отношения между БК.Стороны вверх и вниз по течению.Во взаимоотношениях между двумя BC не стоит выбирать, какой из двух является восходящим и нисходящим.Они как таковые.Вы можете выбрать способ интеграции (использовать REST API, использовать события, синхронизировать, асинхронно, ...).Вы должны нарисовать контекстную карту, определить, какой стратегический шаблон применяется к каждому отношению между БК, и решить, как его реализовать.

0 голосов
/ 08 октября 2018

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

Я бы порекомендовал взглянуть на раздел «Отображение контекста» книги DDD , а затем Шаблоны корпоративной интеграции Хоупа и Вульфа для конкретной реализации.

0 голосов
/ 08 октября 2018

Существуют ли какие-либо предпочтительные практики?

Спецификации сообщений.

То есть вместо того, чтобы соединять A, B и C друг с другом, вы могли бы ихформаты сообщений mA, mB и mC.Пока (мА, мБ, мК) совместимы, службы смогут обмениваться данными друг с другом.

Один из способов добиться этого - ограничить использование мА, мБ и мК различными «версиями».той же схемы, где эволюция схемы ограничена

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

Книга Грега Янга Управление версиями в системе источников событий посвящает эту идею главе.Вы увидите похожие идеи, если взгляните на различные стандартизированные сериализации сообщений (Avro, Protocol Buffers и т. Д.).

Если один сервис генерирует выходные данные по своей теме и создает зависимые сервисы для их использованияили наоборот, или какой-то третий вариант?

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

Концептуально кажется, что вы хотите, чтобы C потреблял логический внешнее объединение сообщений, созданных A и B. Поэтому я полагаю, что непосредственный вопрос заключается в том, есть ли у вас в настоящее время потребители тех же сообщений из A, которые не хотят получать сообщения от B, или наоборот.Если это единственный вариант использования, о котором вы знаете, может быть полезно свести все к одной теме.

0 голосов
/ 05 октября 2018

Каждый из ваших сервисов должен использовать формат данных, наиболее подходящий для его конкретной бизнес-логики.

Для целей интеграции:

  • Inbound channel adapters - преобразует данные в желаемый формат при поступлении в службы.
  • Outbound channel adapters - преобразует данные в формат желаний при их выходе из службы.

Для получения дополнительной информации: https://www.enterpriseintegrationpatterns.com/patterns/messaging/ChannelAdapter.html

...