Связь между двумя микросервисами

Я создаю проект с архитектурой микросервисов. И я создал два микросервиса.

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

Счет-мс должен иметь доступ к списку продуктов. Мне интересно, как я могу общаться между этими двумя мс. У меня есть три подхода в моем уме:

Отправьте запрос от bill-ms в очередь - например rabbitMQ, чтобы получить эти продукты с этими идентификаторами из product-ms (я не знаю, что является узким местом этого)
Отправить запрос на шлюз для обслуживания продукта и получить оттуда продукт (я беспокоюсь о задержке из-за размера данных между ними и таким образом я не касаюсь базы данных напрямую, поэтому я всегда зависят от шлюза)
Я могу дублировать репозитории, службы и объекты в bill-ms (это уродливый способ, и я думаю, что это нарушает правило ms-архитектуры, а обслуживание очень сложно)

Если у вас есть другие подходы, я ценю, что вы поделитесь им со мной.

Edit

Теперь я знаю, что такое узкое место: скажите, что есть 3 экземпляра bill-ms и как rabbitMQ решает, какой экземпляр отвечает? или как мне сказать ленте " дать мне бесплатный экземпляр bill-ms для подписки на запрос от rabbitMQ" для балансировки нагрузки.

Ответ 1

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

Сначала я начал с HTTP коммуникационных микросервисов с помощью этого блога. Это прекрасно работает, но проблема в том, что вы создаете зависимости между вашими службами. Служба A должна знать о службе B и должна называть ее напрямую (через сервисное открытие и т.д., конечно). Это то, чего вы обычно избегаете при разработке микросервисов.

Другой подход, который я начал с недавнего времени, использует message bus. Это фактически третий вариант, который вы затронули в своем вопросе.

У меня есть служба A, в которой хранятся люди (только пример). То, что делает служба при создании нового человека, это: он отправляет event на шину RabbitMQ: personCreatedEvent. Если есть какие-либо другие услуги, заинтересованные в таких событиях, они могут подписаться на них. Эти заинтересованные службы содержат релевантную информацию, которую они интересуют, в своих собственных хранилищах данных.

При таком последнем подходе между вашими службами не существует зависимости, потому что они не общаются напрямую друг с другом. Служба A не знает о службе B, поскольку B просто отправляет события в RabbitMQ в зависимости от того, какая услуга заинтересована этими событиями и наоборот.

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

Ответ 2

Вы посмотрели http://stytex.de/blog/2016/03/25/jhipster3-microservice-tutorial/ Часть 2: раздел межсервисной связи. Он исследует конкретный пример того, как это достигается.

Ответ 3

Позвольте мне попытаться добавить еще несколько подробностей к этому сценарию, чтобы подчеркнуть, что может или не может квалифицироваться как событие в контексте продукта и билингва. Billing-MS необходимо будет поговорить с Product-Ms только в том случае, если размещен заказ. Размещение заказа будет в основном для отдельной MS, скажем, Order-MS. Когда заказ создается или размещается, он будет содержать информацию о продуктах как позиции.

Создание ордера может рассматриваться как событие. Когда происходит событие создания заказа, его можно перенаправить в очередь для службы биллинга. Очередь должна быть реализована как рабочая очередь в RabbitMQ. Таким образом, несколько экземпляров Billing-MS могут подписаться на одну и ту же очередь, но будут обрабатываться одним и только одним Рабочим. Нет роли RIBBON в регистрации службы в качестве Работника в RabbitMQ. Каждый экземпляр регистрируется в очереди, а RabbitMQ решает RoundRobin, какой экземпляр службы биллинга получает для обработки этого события.

Получение информации о продуктах в заказе для биллинга-Ms должно быть балансировкой нагрузки Service-to-Service, сбалансированной через ленту (если это то, что вы используете). Получение информации о продукте не является событием, поэтому размещение заказа - это, следовательно, разница.

Кроме того, Gateway должен использоваться для отображения ваших служб Edge. Для вызовов Service-to-Service не было бы идеальным переходить через службу шлюза.