Представь, что мы успешно распилили монолит на 10 независимых микросервисов. Теперь, чтобы собрать главную страницу интернет-магазина, клиенту (фронтенду или мобилке) нужно сходить в Сервис Пользователей, Сервис Рекомендаций, Сервис Оплат и Сервис Заказов. Это порождает кучу сетевых запросов и убивает производительность на клиенте. Как это решить?
1. Агрегатор-сервис (Aggregator)
Мы создаем специальный сервис, единственная задача которого — принимать запрос от клиента, под капотом дергать нужные микросервисы, склеивать их ответы в один большой JSON и отдавать клиенту. Клиент видит только один запрос.
- Плюсы: Клиенту просто (один эндпоинт). Можно кэшировать агрегированные ответы.
- Минусы: Агрегатор может стать бутылочным горлышком, если в нём будет слишком много логики.
2. Умный API Gateway (Архитектурный)
Вспоминаем Неделю 2: мы говорили, что API Gateway бывает инфраструктурный (Edge) и архитектурный. Так вот, логику агрегации можно перенести прямо в Архитектурный API Gateway (например, Apollo GraphQL). Шлюз не просто прокидывает трафик, а ходит по сервисам и выдергивает нужные куски данных.
Graceful Degradation: Если при сборке страницы Сервис Реакций (лайков) упал, Умный Gateway не кидает 500 на весь запрос. Он просто отдает пост без лайков (graceful degradation).
3. Backend For Frontend (BFF)
Эволюция умного шлюза. Если у нас есть Мобильное приложение и Веб-сайт, им нужны разные данные (вебу нужны тяжелые 4K картинки, мобилке — легкие превью). Если мы сделаем один универсальный Агрегатор, он превратится в монстра. Паттерн BFF предлагает сделать отдельный Агрегатор под каждый тип клиента.
- Плюсы: Нет одного сервиса для всех. Команда мобилки может пилить свой Mobile BFF, команда веба — свой Web BFF, независимо друг от друга.
- Минусы: Поддержка нескольких BFF, возможное дублирование логики (например, авторизации).