Вы можете выполнять поиск событий с помощью akka-persistence в Lambda, если вас устраивает (некоторое настраиваемое) согласованность событий и вы хотите также применить CQRS< /эм>.
Как выглядит такая установка?
У вас будет (1 или более) лямбда-функций, которые создают n экземпляров лямбда-выражений (давайте назовем их QUERY-Lambda; где n в основном не ограничено или ограничено ограничением параллелизма, доступным в вашей учетной записи), которые могут обрабатывать ваши стороны чтения (обрабатывать запросы, читая журнал/хранилище моментальных снимков и затем отвечая), и макс. 1 экземпляр лямбда-выражения на агрегат, который обрабатывает операции записи (убедитесь в этом, используя параметр concurrency в конфигурации лямбда-выражения) (давайте назовем их COMMAND-Lambda). Это важно, чтобы убедиться, что журнал не испортится, если в него будут писать более одного актера.
В зависимости от ваших гарантий согласованности обязательно остановите акторы в QUERY-Lambdas либо сразу после обработки запроса, либо установите тайм-аут получения на значение, соответствующее вашей гарантии согласованности, зная, что несколько акторов могут дать вам другое состояние. .
Если у вас есть операции CRUD, убедитесь, что операции чтения, которые показывают пользователю текущее состояние перед применением изменения (например, отображение текущих значений объекта клиента в форме перед его обновлением), также обрабатываются WRITE-Lambda, чтобы вы убедитесь, что состояние, которое вы меняете, является последним доступным состоянием.
Для этого вам не нужно создавать несколько jar-файлов, вы можете просто развернуть один и тот же jar-файл как несколько лямбда-функций. Вы должны убедиться в том, что в вашем API-шлюзе запросы, изменяющие состояние, перенаправляются на WRITE-Lambda (s), а те, для которых согласованность не так важна, направляются на READ-Lambda (s).
Также убедитесь, что вы не создаете моментальные снимки при воспроизведении журнала, а только при обработке команд (поскольку READ-Lambdas также воспроизводит журнал и, таким образом, может повредить ваше состояние, если они будут создавать моментальные снимки).
Для лучшей производительности создавайте моментальный снимок после каждой команды, которая изменила состояние, или, по крайней мере, перед завершением работы актора, чтобы следующие вызовы выполняли минимальное количество операций чтения. Насколько я знаю, лямбды в Java также остаются активными в течение разумного времени, поэтому холодные перезагрузки не должны быть такой большой проблемой. Если они для вас, создайте какой-нибудь cron, который каждые ~ 5-10 минут вызывает лямбду, чтобы поддерживать ее в рабочем состоянии. В качестве альтернативы вы можете использовать https://doc.akka.io/docs/alpakka/current/awslambda.html, чтобы просто отправлять запрос самому себе каждые x минут. Вы можете использовать Source.tick(3 minutes), а затем просто вызывать функцию WRITE-Lambda, как показано в документации Alpakka.
Также убедитесь, что операции, в которых вам нужно общаться с двумя агрегатами (Saga/Coordinator), обрабатываются одной и той же WRITE-Lambda. Это может стать узким местом, но, конечно, вы все равно можете применить какой-то сегментирование через маршрутизацию в шлюзе API. Это просто больше усилий, чем если бы у вас был обычный кластер Akka.
Если что-то непонятно, пожалуйста, оставьте комментарий, и я постараюсь ответить.
person
Dominik Dorn
schedule
01.05.2019
