Микросервисные модели входных и выходных доменов
Я использую 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 ответа
Есть ли предпочтительные практики?
Спецификации сообщений.
То есть вместо того, чтобы связывать A, B и C друг с другом, вы можете перевести их в форматы сообщений mA, mB и mC. Пока (мА, мБ, мК) совместимы, сервисы смогут обмениваться данными друг с другом.
Один из способов добиться этого - ограничить использование mA, mB и mC разными "версиями" одной и той же схемы, где развитие схемы ограничено.
- После начальной версии новые поля не могут быть добавлены
- Необязательные поля должны иметь значения по умолчанию
- Потребитель должен игнорировать нераспознанное поле
- Поля могут быть устаревшими, но они никогда не используются повторно (например, см. Код состояния HTTP 306).
Книга Грега Янга " Управление версиями в системе источников событий" посвящает эту идею главе. Вы увидите похожие идеи, если посмотрите на различные стандартизированные сериализации сообщений (Avro, Protocol Buffers и т. Д.).
Должен ли один сервис производить вывод по своей теме и делать зависимые сервисы для их использования, или наоборот, или какой-то третий вариант?
В основном это сантехника - как мы можем получить копию сообщения из одной системы в другую?
Концептуально кажется, что вы хотите, чтобы C использовал логическое внешнее объединение сообщений, созданных A и B. Поэтому я полагаю, что непосредственный вопрос заключается в том, есть ли у вас в настоящее время потребители тех же сообщений из A, которые не хотят сообщений из Б или наоборот. Если это единственный вариант использования, о котором вы знаете, может быть полезно свести все к одной теме.
То, о чем вы говорите - это контекстное отображение. Отношения между БК. Стороны вверх и вниз по течению. Во взаимоотношениях между двумя BC не стоит выбирать, какой из двух является восходящим и нисходящим. Они как таковые. Вы можете выбрать, как интегрировать (использовать REST API, использовать события, синхронизировать, асинхронно, ...). Вы должны нарисовать контекстную карту, определить, какой стратегический шаблон применяется к каждому отношению между БК, и решить, как его реализовать.
Прежде чем выбрать режим интеграции, необходимо провести анализ на стратегическом уровне в отношении бизнес-поддоменов, групп, которые будут обслуживать эти службы, кому что принадлежит, как вы ожидаете, что модели будут развиваться, и т. Д.
Я бы порекомендовал взглянуть на часть "Сопоставление контекста" книги DDD, а затем на шаблоны корпоративной интеграции Hohpe и Woolf для конкретной реализации.
Каждый из ваших сервисов должен использовать формат данных, наиболее подходящий для его конкретной бизнес-логики.
Для целей интеграции:
Inbound channel adapters- преобразует данные в нужный формат при поступлении в сервис.Outbound channel adapters- преобразует данные в формат желаний при выходе из службы.
Для получения дополнительной информации: https://www.enterpriseintegrationpatterns.com/patterns/messaging/ChannelAdapter.html