Микросервисы - роль кафки, API шлюза, лямбды - PullRequest
0 голосов
/ 21 февраля 2020

При следовании архитектуре микросервисов, где и как используется kafka (для межсервисной передачи сообщений?) Правильно ли мое понимание, как показано ниже?

Клиенты (веб-страница) -> через шлюз API -> Lamdba -> запрос информации о клиенте (CRUD). Теперь я должен обновить информацию о потребителе в Lambda напрямую с помощью Dynamo DB или отправить событие в kafka, которое должно обновить данные? Должна ли служба поддержки отправлять событие, например customer_updated, для уведомления других служб об обновлениях?

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

В основном два q, но они были взаимосвязаны.

1 Ответ

0 голосов
/ 21 февраля 2020

Примечание: вы можете заменить Kafka на Kinesis, и у вас возникнет тот же вопрос ...

Lamdba также может быть заменен любым сервером API за шлюзом, и шлюз может быть просто загружен балансир.

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

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

...