Выберите микро сервисы против библиотеки в качестве зависимости?

Question

У меня есть два модуля (mod1 с DB1 и mod2 с DB2), размещенные как микросервисы.Оба модуля имеют некоторые общие функциональные возможности, которые могут взаимодействовать как с DB1, так и с DB2.

Approach_1: - Создайте еще один mod3 в качестве jar совместно используемой библиотеки для общего компонента и вставьте его в оба модуля, чтобы избежать дублирования кода

* 1004.* Approach_2: - Создайте еще один микро-сервис для общего компонента вместо jar совместно используемой библиотеки.

Не уверен, какой подход лучше с точки зрения дизайна и какие критерии мне нужно учитывать здесь?

По моемупонимание, это должна быть общая библиотека вместо микросервиса, так как она будет взаимодействовать с несколькими БД.Если это общий jar, то этот модуль логически связан с модулем вызывающего абонента с экономической точки зрения.

Answer 1

Если у вас есть общие функциональные возможности, которые используют БД двух разных микросервисов, выполните следующие два шага:

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

Обратите внимание, что небольшая задержка (возможно, несколько секунд) для обновления второй микросервисной БД может небыть настолько плохим, насколько это может показаться изначально.«Извинение» играет здесь важную роль.Многие сайты электронной коммерции посылают извинения клиенту за неспособность выполнить их заказы, даже если заказ успешно отправлен.С этой точки зрения шаблон Saga может быть полезен, когда он выполняет компенсирующую транзакцию в первом микросервисе, если он не может применить изменения во втором микросервисе, поскольку бизнес-логика больше не сохраняется к тому времени, когда потоковое событие достигает второго микросервиса.

Короче говоря, два упомянутых вами подхода идут вразрез с архитектурой микросервисов

Answer 2

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

Подумайте, что произойдет, если вы измените схему одной из баз данных.Вам придется обновить оба микросервиса, чтобы иметь дело с изменением.Если у вас есть библиотека, вам нужно обновить библиотеку, а затем собрать и выпустить обе микросервисы.Что вы получаете, поддерживая два микросервиса вместо одного?Кажется, это просто дополнительная работа.

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