Лямбда-монолитный подход:
- Иметь только одну лямбда-функцию
- Используйте внутренний маршрутизатор, на который влияет конфигурация лямбда-прокси+.
- Направьте запрос в правильную функцию (вы можете разделить код внутри на основе функциональности, это поможет позже, если вы захотите перейти на другую архитектуру)
Плюсы: вы можете взять старомодный NodeJS API (скажем, основанный на экспресс или хапи) и быстро развернуть его на AWS Lambda и забыть об обслуживании и масштабировании серверов. Не нужно бояться 1000 функций и конфигураций, скрывающихся в консоли AWS. Быстрое развертывание.
Минусы: ваше приложение монолитно и старомодно, проповедники микросервисов будут смеяться над вами.
Подход Lambda к микросервисам
- Иметь одну лямбда-функцию для каждого «микросервиса» (у вас все еще есть только один проект, но вы разделяете код на модули в зависимости от функциональности: аутентификация, учетная запись, транзакции и т. д.)
- Для каждой микрослужбы вы используете конфигурацию proxy+ и внутренний маршрутизатор для вызова правильной внутренней функции.
Плюсы: ваш проект хорошо структурирован на основе функциональности, ваш проект развертывания меньше, потому что каждая функция содержит только то, что ей нужно. В итоге ваш проект будет иметь десятки или менее десяти функций. Развертывание занимает немного больше времени, но все равно быстро.
Минусы: евангелисты микросервисов все равно будут смеяться над вами, потому что вы подделываете микросервисы.
Подход Lambda «мини-сервисы»
- Иметь одну лямбду на маршрут
Плюсы: очень маленькие пакеты развертывания.
Минусы: в итоге у вас будет 100 функций в консоли AWS Lambda. Развертывание занимает много времени (вам нужно помнить об обрезке старых версий функций, потому что вы быстро получите максимальное хранилище Lambda). Евангелисты микросервисов по-прежнему будут смеяться над вами, потому что у вас не может быть отдельного стека технологий для каждой функции.
