Как интегрировать различные «микросервисы» в транзакцию?

Question

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

Я использую микросервисы с небольшим количеством соли, потому что мы не полностью охватываем концепции для определения реальных микросервисов. Одно (и я думаю, самое большое) различие заключается в том, что мы используем одну и ту же общую базу данных в разных модулях (которые я называю «микросервисами»). Некий логический взгляд на нашу систему можно нарисовать так:

                  ╔══════════════╗
                  ║    Client    ║ ══╗
                  ╚══════════════╝   ║ (2)
                                     ║
                                     ▼        
        ╔══════════════╗  (1) ╔══════════════╗
        ║  Serv. Reg.  ║ <==> ║  API Gatew.  ║
        ╚══════════════╝      ╚══════════════╝
            █       █   █████████████     (4)
           █         █              ████
╔══════════════╗  ╔══════════════╗  ╔══════════════╗
║   Module A   ║  ║   Module B   ║  ║   Module C   ║  <===== "Microservices"
╚══════════════╝  ╚══════════════╝  ╚══════════════╝
        ║║ (3)           ║║ (3)            ║║ (3)
        ║║               ║║                ║║
╔══════════════════════════════════════════════════╗
║                Database Server                   ║
╚══════════════════════════════════════════════════╝

Некоторые вещи, которые мы уже выяснили:

• Клиенты (внешние системы, внешние приложения) будут получать доступ к различным внутренним модулям, используя шаблон обнаружения / маршрутизации. Мы рассматриваем сочетание Netflix OSS Eureka и Zuul, чтобы обеспечить это. Службы (модули A, B, C) сами регистрируются (4) в модуле регистрации служб и координируют действия шлюза API (1) с регистром, чтобы найти экземпляры служб для полного выполнения запросов (2).
• Все разные модули используют одну и ту же базу данных. (3) Это скорее запрос клиента, чем решение архитектуры.

Дело в том, что мы (или я лично) застряли в том, как установить связь между различными модулями. Я прочитал множество различных шаблонов и анти-шаблонов, чтобы сделать это, и почти каждый из них скажет, что API-интеграция через RestTemplate или какой-то специализированный клиент, такой как Feign или Ribbon.

Мне не нравится этот подход по ряду причин, в основном из-за синхронного характера и отсутствия запросов HTTP. Природа HTTP без учета состояния является моей самой большой проблемой, поскольку уровень обслуживания различных модулей может иметь некоторые сильные привязки. Например, действие, которое запускается в модуле A, может иметь последствия для модулей B и C, и все должно координироваться с точки зрения «транзакции». Я действительно не думаю, что HTTP был бы лучшим способом контролировать это!

Часть Java EE внутри меня кричит о том, чтобы использовать какую-то интеграцию служб, такую ​​как EJB или RMI, или что-то, что не использует HTTP в конце. Для меня было бы гораздо более «естественно» подключить определенную Службу к модулю B внутри модуля A и быть уверенным, что они участвуют вместе в транзакции.

Еще одна вещь, которую необходимо подчеркнуть, заключается в том, что для нашего клиента недостаточно таких парадигм, как возможные несоответствия в базе данных, поскольку они имеют дело с некоторыми серьезными данными. ТАК, «Я обещаю приложить все усилия с данными» не очень хорошо здесь.

Время вопроса:

Является ли эта «интеграция услуг» действительно полезной при работе с «Микросервисами»? Или «Интеграция ресурсов» выигрывает?

Кажется, что Spring, например, предоставляет Spring Integration для обмена сообщениями между сервисами, как это делает технология, подобная EJB. Это лучший способ интегрировать эти услуги? Я что-то упустил?

PS: Вы можете называть мои «Микросервисы» «Микролитами», как мы обычно называем их здесь. :)

Answer 1

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

Чтобы подумать о связи между службами, вы можете попытаться определить Events и использовать их в качестве координаты изменений вашего состояния в нескольких службах. Если вам действительно нужно много данных из нескольких внешних сервисов для выполнения транзакции, вы можете сохранить копию внешних данных в сервисе, нуждающемся в данных. Projections они обычно вызываются и могут обновляться событиями, опубликованными внешними службами.

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

Answer 2

Микросервисы подход, подходящий к картине, когда вы создаете дизайн, управляемый доменом. Прежде всего, вы должны иметь глубокие знания о доменной адресации в вашем приложении. И должен иметь возможность идентифицировать ограниченный контекст модулей ваших приложений. Если вы определили такие гранулированные модули, вы можете легко преобразовать их в микросервис. Каждый ограниченный контекст должен быть в высшей степени независимым, это означает, что отдельная транзакция должна обрабатываться в микросервисе. Поскольку вы используете общую базу данных, я предполагаю, что это СУБД, строго соблюдающая свойство ACID . Если вам необходимо получить свойство ACID в транзакциях с БД, то каждый микросервис, который вы собираетесь создать, должен независимо обрабатывать управление транзакциями. Другими словами, если вы можете концептуализировать транзакции как порядок событий, и каждое событие само поддерживает его состояние, вы можете развивать свои микросервисы в качестве движков для обработки этих событий. Если вы в конечном итоге разработали схему, в которой микросервисы должны сильно зависеть друг от друга, и они не способны самостоятельно обрабатывать состояния / события / транзакции в большинстве случаев, вам придется переосмыслить свой подход. То, что вы пытаетесь достичь, называется шаблон общей базы данных . Некоторые люди считают это анти-паттерном .

Answer 3

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

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

В противном случае многие из преимуществ микросервисной архитектуры исчезают:

1. Независимость. Что ж, мы можем развертывать новые версии микросервиса в своем собственном темпе, не разделяя даже технологический стек, и так далее, и тому подобное. Теперь, если я изменю схему (даже немного), скажем, добавив или, в более крайних случаях, изменив или удалив столбец, например, как другие микросервисы узнают, что это произошло. Могу ли я на самом деле развернуть каждый сервер по отдельности? Теперь мне нужно развернуть их все сразу? К сожалению, второй вариант - единственный жизнеспособный путь. Так что нет реальной независимости

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

Вы видите, куда это идет ...

Теперь вопрос о транзакциях или, в более общем смысле, целостности данных, действительно является одной из самых больших проблем, которые необходимо решить при переходе на микросервисный подход.

Обычно (опять же из моего опыта) люди корректируют свои варианты использования таким образом, чтобы конечная согласованность также была достаточно хорошей, и тогда проблем не возникало. Так или иначе, лучше избегать таких вещей, как распределенные транзакции, потому что они чрезвычайно усложняют код и создают настоящий кошмар.

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