#aws-lambda #microservices #aws-api-gateway #amazon-sqs #amazon-sns
Вопрос:
Предположим, у меня есть api POST /order
, который вызывает PlaceOrder
лямбду и ожидает ответа от этого. PlaceOrder
лямбда выполняет некоторые работы, вызывает другую лямбда ProcessPayment
-лямбду и ожидает ответа. Кроме того, ProcessPayment
вызывает CreateInvoice
лямбду, ожидающую ответа. Вся архитектура похожа на RequestResponse
цикл. Я хотел бы добиться этого без использования лямбды, вызывающей другую лямбду, поскольку она рассматривается как анти-шаблон. Мой вопрос заключается в том, каков наилучший шаблон проектирования для достижения такого поведения в течение 29 секунд с помощью архитектуры, управляемой событиями.
Что предлагает AWS: Согласно этой официальной документации, они предлагают использовать SQS. Но что касается использования SQS, у меня есть некоторые мысли.
Мои мысли:
- В архитектуре источников событий я могу организовать эти лямбды с помощью SQS, SNS и других источников событий, но в этом случае природа не будет синхронной, и, следовательно, я не получу ответа от api.
Мое другое решение:
- Использование функции шага: Я могу организовать этот рабочий процесс с помощью функции шага, и я думаю, что это более элегантное решение в данном случае синхронного вызова. Но я хотел бы добиться этого с помощью источников событий.
Как я могу спроектировать этот сценарий с учетом лучших практик, используя архитектуру на основе событий?
Ответ №1:
В архитектуре, управляемой событиями, связь между производителями и потребителями асинхронна по замыслу, именно так масштабируется архитектура.
Вы можете получить почти синхронную связь между 2 службами в EDA, создав выделенные очереди / каналы для связи между ними, убедитесь, что они масштабированы до уровня, при котором задержка приемлема (близка к синхронным значениям).
Это добавляет некоторую сложность, потому что службы, которым нужны ответы, должны ждать в режиме «горячей линии», чтобы получить их как можно скорее, а также, если сообщения потеряны, вам необходимо иметь политики повторных попыток и т. Д.
Ответ №2:
Я думаю, вам нужно больше сосредоточиться на механике вашей программы и немного меньше на шаблонах проектирования. Вам нужно использовать шаблоны проектирования, соответствующие вашему варианту использования, иначе не получится. В конце концов, вы создаете программу для выполнения определенной задачи или набора задач, так что это должно быть вашей конечной целью.
Вы утверждаете, что у вас есть лямбда-код заказа процесса, лямбда-код создания счета-фактуры и лямбда-код оплаты процесса. Я бы сказал, что самый интересный вопрос-это то, что вам нужно сделать, прежде чем вы вернете ответ пользователю. Возможно, вы сможете обработать заказ, ответить пользователю, что это сделано, и обработать выставление счетов и платежи позже. Обычно это означает, что вы помещаете сообщение в очередь SQS или в тему SNS.
Возможно, вам нужно, чтобы ваш платеж был обработан до того, как вы ответите пользователю, потому что они должны быть проинформированы о статусе платежа. Затем вы можете объединить оба действия в одной Лямбде, потому что невозможно отделить две задачи друг от друга. Имейте в виду, что часто существует другой вариант, когда вы сначала обрабатываете заказ, помещаете сообщение в очередь для оплаты процесса (как правило, это процесс, в котором участвует третья сторона), и интерфейс запрашивает обновление статуса платежа. Таким образом, вы можете быстро вернуть ответ и при этом как можно скорее сообщить обновленную информацию об оплате.
Процесс создания счета-фактуры, как правило, является тем, что вы никогда не захотите синхронно вызывать во время подтверждения заказа. Что делать, если ваше приложение для выставления счетов (стажер или внештатный сотрудник) не работает? Теоретически вы все еще можете обрабатывать заказы, если создадите счет-фактуру в какой-то более поздний момент времени. Если вы соедините все вместе, вы поставите подтверждение заказа в зависимость от процесса создания счета-фактуры, что я бы расценил как ненужную зависимость.
Я бы действительно посоветовал не использовать пошаговые функции для этого варианта использования. Они могут быть использованы для длительных процессов, которым необходимо сохранять состояние и «просыпаться» в определенные моменты, но для этого конкретного потока я бы сказал, что они не помогают и излишне сложны. Если у вас есть 3 вещи, которые вам нужно сделать, которые вы не можете отделить друг от друга, просто запустите их в одной и той же Лямбде.
Комментарии:
1. Привет @Брэм, я привел 3 лямбды просто в качестве примера, чтобы поднять проблему. В нашей системе в настоящее время существует множество лямбд, которые синхронно вызывают друг друга. A вызывает B, B вызывает C, затем D и т. Д. Точно так же, как обычные функции, которые мы привыкли писать на наших языках программирования. Я просто хочу избавиться от этого и ввести несвязанные лямбда-функции, которые будут использовать архитектуру, управляемую событиями. Но я не понимаю, как это сделать синхронно.
2. @Hasan Я не понимаю, как это сделать синхронно — в этом суть проблемы — архитектуры, управляемые событиями, не должны быть синхронными. Вы можете использовать пошаговые функции AWS с экспресс-рабочими процессами для организации нескольких функций лямбда, но это не архитектура, управляемая событиями. Также не имеет смысла настаивать на создании архитектуры, управляемой событиями, если это не полезно для вашего конкретного случая использования.