Какой вариант использовать для микросервисов: Spring Boot или AWS Lamba

Question

Я родом из Java / Java EE, а также для Microservices и AWS;хотя я много читал об этом.Я попробовал свой первый микросервис с Spring Boot, и я впечатлен Spring Boot.Я также использовал AWS в течение последних 2 месяцев, и теперь я немного знаком с ним.

Сейчас я работаю над большим приложением и думаю о разработке полного бэкэнда (API) и хотел бы использовать для него микроуслуги - хотя я все равно использовал бы только несколько микросервисов: один для управления пользователями иеще три с бизнес-логикой.Я должен также обработать аутентификацию.

Исходя из моих исследований и работы, я рассматриваю два варианта:

Вариант 1: AWS Cognito (для поддержки входа в социальные сети) + AWS API Gateway + несколько AWS Lambdas (код Java) + одинDynamoDB (желательно иначе RDS MySQL).Меня интересует, могу ли я написать сложную бизнес-логику и обработать сложные отношения таблиц (такие как «многие ко многим», «жадная / ленивая выборка» и т. Д.) В лямбдах AWS, что очень аккуратно сделано в Spring Boot + Spring Data JPA

Вариант 2. Начните с написания бизнес-логики в Spring boot, то есть четырех приложений весенней загрузки с MySQL или DynamoDb в качестве бэкэнда;и развернуть их на AWS EC2;Я также могу реализовать еще одно загрузочное приложение Sprint с JWT для аутентификации. Моя задача здесь: как управлять аутентификацией (одна точка входа для всех API) для нескольких приложений с весенней загрузкой;Если я столкнусь с проблемой интеграции с AWS API Gateway (для централизованного управления аутентификацией и авторизацией);и столкнусь ли я с трудностями при интеграции с AWS Cognito, если я хочу войти в систему через социальные сети

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

Большое спасибо

Answer 1

После исследования я выбрал AWS lambdas.Мое приложение представляет собой приложение для управления событиями, и я хочу архитектуру, управляемую событиями.В общем вопрос должен был быть контейнер против лямбд, и я нашел хорошее сравнение .Начать с Spring легко, потому что он настолько знаком с фоном Java.Хорошо писать микросервисы с бизнес-логикой и представлять их как HTTP REST API.Я читал дизайн, управляемый доменом, и было бы хорошо определиться с размером микро-сервисов на основе границ (ограниченный контекст).

Но я также вижу, что при загрузке Spring мне придется управлять аутентификацией (для приложения управления событиями нам нужна поддержка входа в социальные сети), авторизацией, пользователями, ролями, политиками, а также, наконец, интегрировать микросервисы с API Gateway,Аутентификация и авторизация без сервера AWS очень сложны .Использование базы данных NoSQL, такой как DynamoDB, следует некоторым рекомендациям по микросервисам, таким как CQRS.С Lambdas границы будут слишком маленькими, но в моем случае AWS Lambdas подходит лучше.

Answer 2

Если у вас сложная бизнес-логика / сложные отношения, выполнение которых может занять больше времени, тогда вам следует быть осторожным при использовании комбинации Lambda и API Gateway по следующим причинам:

1. Api Gateway очень полезен в случае написания API только в том случае, если вы уверены, что ваши API работают быстро и быстро принесут ответ.В настоящее время API gateway имеет жесткий предел времени ожидания через 29 секунд .Это означает, что если вашему API требуется более 29 секунд, он будет напрямую завершать этот запрос.
2. Нечто подобное происходит и с lambda.Lambdas специально разработаны для обработки небольших кусков обработки.В настоящее время он поддерживает максимальный объем памяти 3008 МБ и время ожидания 5 минут .Через 5 минут лямбда прекратит обработку запроса.

Таким образом, ваш вариант 1 имеет эти ограничения, в противном случае это комбинированное сочетание действительно просто и экономно по времени + AWS Cognito.

Теперь давайте рассмотрим ваш вариант 2.

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

Если вы думаете пойти на это, я хотел бы сообщить вам, что API Gateway не будет полезен из-за жесткого ограничения времени ожидания, указанного выше.В этом случае аутентификация может быть выполнена с использованием широко доступных методов, таких как JWT, OAuth, Basic Auth или даже AWS Cognito.

Так что, на мой взгляд, если у вас есть архитектура на основе микросервиса, тоне будет никаких проблем с вариантом 1, при условии, что время будет выполнено!