Микросервисы: как обращаться с внешними ключевыми отношениями

Архитектура микросервисов предполагает, что каждая служба должна обрабатывать свои собственные данные. Следовательно, любая услуга (услуга A), зависящая от данных, принадлежащих другой службе (услуга B), должна обращаться к таким данным не посредством прямых вызовов БД, а через api, предоставляемую второй услугой (услугой B).

Итак, что предлагает лучшие методы микросервисов для проверки ограничений внешнего ключа.

Пример: Я разрабатываю функцию доставки (микросервис 1) для продуктов, а некоторые продукты поставляются только в определенных местах, как указано в таблице продуктов, доступной только для микросервиса продуктов (mircoservice 2).

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

Ответы

Ответ 1

Можно использовать общую базу данных для нескольких микросервисов. Вы можете найти шаблоны для управления данными микросервисов по этой ссылке: http://microservices.io/patterns/data/database-per-service.html. Кстати, это очень полезный блог для архитектуры микросервисов.

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

В вашем примере служба доставки может дублировать адреса доставки и информацию о продукте. Служба продуктов управляет продуктами и местоположениями. Затем необходимые данные копируются в базу данных службы доставки с асинхронными сообщениями (например, вы можете использовать кролик mq или apache kafka). Служба доставки не изменяет данные продукта и местоположения, но использует данные, когда выполняет свою работу. Если часть данных продукта, используемая службой доставки, часто меняется, дублирование данных с асинхронным обменом сообщениями будет очень дорогостоящим. В этом случае вы должны совершать вызовы api между продуктом и службой доставки. Служба доставки спрашивает службу продукта, чтобы проверить, поставляется ли продукт в определенном месте или нет. Служба доставки запрашивает сервисную службу с идентификатором (имя, идентификатор и т.д.) Продукта и местоположения. Эти идентификаторы могут быть взяты у конечного пользователя или совместно используются микросервисами. Поскольку базы данных микросервисов здесь разные, мы не можем определять внешние ключи между данными этих микросервисов.

Api-звонки, возможно, проще реализовать, но стоимость сети выше в этой опции. Кроме того, ваши услуги менее автономны, когда вы выполняете вызовы api. Поскольку в вашем примере, когда служба "Сервис" недоступна, служба доставки не может выполнять свою работу. Если вы дублируете данные с помощью асинхронного обмена сообщениями, необходимые данные для доставки будут размещены в базе данных "Микросервис доставки". Когда Служба продукта не работает, вы сможете сделать доставку.

Ответ 2

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

Другим моментом является то, что только один компонент в вашей системе владеет данными (для операций изменения состояния), другие компоненты могут ПРОЧИТАТЬ, но НЕ ПИСАТЬ, у них могут быть копии данных или вы можете поделиться имитационной моделью, которую они могут использовать для получения последнее состояние объекта.

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

Взгляните на Udi Dahan поговорите в NDC Oslo для более подробной информации

Надеюсь, что это поможет