Как моделировать связь между микросервисами в случае делегированной логики персистентности

Question

Я хотел бы спросить здесь о следующей ситуации.

Допустим, у нас есть 2 приложения или «(микро) услуги»:

• приложение А расположено сверхубольшого хранилища данных и предоставляет данные через REST, это типичное приложение Spring Boot, которому необходимо управлять разрешениями, выполнять некоторые преобразования, сопоставление и т. д., и оно инкапсулирует необходимые API данных низкого уровня, которые довольно сложны.

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

В моем понимании я бы сказал, что приложения A и B являются автономными приложениями / службами, каждое из которых специализируется наего задача.Однако имеет ли это какое-либо значение или нежелательные последствия, когда кто-то может подумать о том, что отношения AB в том смысле, как приложение A на самом деле является «постоянным слоем» приложения B, то есть вместе с его «локальной логикой постоянства» и, следовательно, тем же модулем.Это можно рассматривать как реализацию интерфейсов Dao или Repository с некоторыми реализациями REST, вызывающими приложение A под капотом на уровне данных / в модуле.

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

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

Большое спасибо за любые комментарии.

Answer 1

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

Для вашего сценария я бы рассмотрел три пути:

1. Если App AЕдиный репозиторий, который содержит данные для всех или большинства ваших сервисов, вероятно, его необходимо разбить, чтобы перенести постоянство в пределах домена каждой границы сервиса.
2. Если App B - это особый случай с оченьсвязанных данных с App A, и обе службы предоставляют необходимые функции (которые не перекрываются), рассмотрите возможность подключения App B непосредственно к базе данных и размещения обеих служб за фасадом, представляющим этот конкретный домен.
3. Есливсе, что делает App B, на самом деле предоставляет интерфейс к данным в App A, возможно, что границы ваших служб нарисованы неправильно, и эти два можно / нужно объединить.

Добавление дополнительного HTTP APIвызов в цепочке между клиентом и сохранением данных (использование App B в качестве «интерфейса» к данным в App A) станет большой проблемой для kEEP исполнитель и это то, что я бы избежать.Если после тщательной оценки текущие границы будут определены как наилучшие, вы можете использовать более быстрый или более синхронный способ связи с большим хранилищем данных в App A - например, gRPC или чем-то подобным.

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

Границы службы должны представлять границы бизнес-домена, а те редко (нони разу!) включают одно большое хранилище данных.Поэтому убедитесь, что App A и App B соответственно независимы в соответствии с их бизнес-функциями, и ваш ответ может стать более ясным.