✨ API Gateway и 10 его главных функций: практическое руководство для аналитиков и архитекторов ✨

🔗 Полный гайд по API Gateway

API Gateway (API-шлюз) — это единая точка входа для всех клиентских запросов к Backend.

Обычно используется в микросервисной архитектуре.

👉 Его главная функция — маршрутизация запросов.
Но, помимо этого, API Gateway предоставляет и другие важные функции.


Как он работает:

1️⃣ Первичная обработка запроса
Клиент отправляет запрос в API Gateway, а не напрямую к сервисам. Это обеспечивает централизованную точку входа в систему, а также упрощает интеграцию для клиента.

2️⃣ Валидация запроса
API Gateway проверяет корректность запроса.
Если формат нарушен — запрос отклоняется.

3️⃣ Проверка безопасности
Выполняется проверка по спискам разрешённых (allow-list) и запрещённых (deny-list) источников. Небезопасные запросы блокируются.

4️⃣ Аутентификация и авторизация
Проверяет токены и другие учетные данные. Гарантирует, что у клиента есть необходимые разрешения для доступа к запрашиваемым ресурсам.

5️⃣ Ограничение частоты запросов (Rate Limiting)
Если клиент превышает лимит запросов — они отклоняются с соответствующим ответом.

6️⃣ Маршрутизация к нужному сервису
На основе пути или других признаков, API-шлюз определяет, какому микросервису должен быть направлен запрос.

7️⃣ Преобразование протоколов
При необходимости, преобразует запрос в нужный формат.
Например, если API Gateway принимает запрос в HTTP (REST API), то он может преобразовать его в gRPC для внутреннего микросервиса.

8️⃣ Агрегация ответов
Если ответ зависит от нескольких микросервисов, API Gateway собирает данные с каждого и формирует единый ответ.

9️⃣ Возврат ответа клиенту

🔟 Логирование, мониторинг, обработка ошибок и кэширование


API Gateway упрощает взаимодействие клиентов с распределённой системой и обеспечивает её безопасную и управляемую работу, выступая в роли централизованной точки входа.

Про API Gateway с картинками и реальными примерами использования:
🔗 Полный гайд по API Gateway

#АрхитектураGA

👩‍💻 8 Шаблонов Проектирования Микросервисов 👩‍💻

1️⃣ API Gateway
Единая точка входа для всех внешних запросов.
Отвечает за маршрутизацию, кэширование, аутентификацию.

2️⃣ Service Registry and Discovery
Динамическое обнаружение и регистрация сервисов.
Это механизм? по которому сервисы сами находят адреса друг друга. Он помогает им корректно взаимодействовать без жёстко прописанных адресов.

3️⃣ Backends for Frontends (BFF)
Отдельные адаптивные бэкенды под каждый вид клиентов. Например: Web и Mobile.
Каждый клиент получает ровно те данные и в том виде, который ему нужен.

4️⃣ Event Driven
Микросервисы обмениваются информацией не напрямую, а через публикацию и подписку на «события» в общем брокере: один сервис публикует сообщение о случившемся изменении, а все заинтересованные сервисы, подписанные на эти события, асинхронно получают и обрабатывают их.

5️⃣ CQRS (Command Query Responsibility Segregation)
Шаблон, в котором операции изменения состояния системы (Commands) отделяются от операций чтения данных (Queries).
• Commands реализуют запись данных, с их валидацией.
• Queries оптимизированы под быстрое получение и агрегации, отчёты.

6️⃣ Database-per-Service
Изоляция данных каждого сервиса в своей БД.
Минимизирует зависимость между микросервисами.
Главная проблема - сложность синхронизации данных.

7️⃣ Оркестрация
Центральный сервис управляет порядком вызовов.
Обеспечивает:
• последовательность выполнения алгоритмов, которые используют разные микросервисы,
• целостность и контроль транзакций.
Пример сервиса-оркерстратора: Camunda.

8️⃣ Хореография
Сервисы обмениваются событиями напрямую через брокер, которые управляет порядком выполнения алгоримов, в которых задействованы разные микросервисы.


⚙️ Как применяют?
• В зависимости НФТ (нефункциональных требований).
• Часто комбинируют несколько подходов.


Сохраните себе шпаргалку и используйте при проектировании архитектуры микросервисов, анализе своих проектов и подготовке к собеседованиям 🙌


Исходник: png | svg (анимация)

#АрхитектураGA

⚙️📞 Camunda и BPMN в микросервисах: успешный кейс для оркестрации процессов техподдержки ⚙️📞

Если вы рассматриваете Camunda для внедрения на проект и пытаетесь понять, «а оно нам точно надо?», или хотите разобраться как работает оркестрация процессов в микросервисной архитектуре — этот эпизод для вас.

🔗 Статья к эпизоду
(внутри доп. материалы и ссылки по Camunda и BPMN)

Обсуждаем реальный опыт внедрения Camunda на действующем высоконагруженном проекте со старшим системным аналитиком.

Рассказываем, где Camunda реально помогает развивать и поддерживать систему, а где добавляет новые головные боли. Когда стоит выбирать Camunda, а когда лучше пойти другим путём.

Слушайте, делайте заметки и делитесь с коллегами!


Эпизод доступен в:
⏯ Apple Podcast
⏯ Яндекс.Музыка
⏯ Telegram
⏯ Castbox
⏯ Звук
⏯ Spotify
⏯ RuTube
⏯ YouTube
⏯ VK Video


✅ Подписывайтесь на GetAnalyst — ваша база знаний в мире системного анализа и архитектуры!

🧩 Пример архитектуры микросервисов с API Gateway, где он - точка отказа 🚫

На этой неделе опубликовала подробный гайд по API Gateway.

Теперь показываю первую версию схемы архитектуры для проекта доставки еды #FoodDeliveryGA.

На ней вы можете увидеть, что все Frontend-приложения ходят к Backend через API Gateway, а уже за ним целый зоопарк микросервисов.

И вот тут начинают всплывать интересные вопросы...

Как реализовывать сложные процессы, в которых нужно несколько микросервисов?

🔎 Представим типичный сценарий - успешная оплата заказа

После того как платёж прошёл на сервисе платежей, система должна:
1. На Сервисе Заказов поменять статус заказа на «оплачен»
2. Отправить уведомление ресторану о новом заказе - сервис Уведомлений
3. Отправить уведомление пользователю, что заказ оплачен и ушёл в работу - сервис Уведомлений
4. На сервис курьеров отправить запрос на поиск курьера и завершить процесс обработки платежа, не дожидаясь нахождения курьера
5. После всех этих действий показываем пользователю экран "оплачено" на frontend


Если у нас есть только API Gateway:

👉 Либо все микросервисы начинают общаться между собой через него - точка отказа будет знатная

👉 Либо разрешаем микросервисам вызывать друг-друга напрямую
Звучит нормально… до первой диаграммы с прямыми интеграциями, когда появится паутина стрелок в дополнение к существующим 🕸️
Такую схему сложно не только читать, но и поддерживать в реальном проекте. Любое изменение бизнес-процесса = новая порция хаоса в связях между сервисами

👉 Либо мы можем добавить внутренний API Gateway Internal для взаимодействий между сервисами. Но в бизнес-процессах есть фоновые (асинхронные) задачи, параллельность, необходимость откатов и повторных попыток в случае ошибок. API Gateway не должен управлять логикой процессов, это не его функция


Поэтому в микросервисной архитектуре обычно сочетают подходы:
API Gateway + Хореография и/или Оркестрация

Их мы будем подробно разбирать на следующей неделе 🤝


#АрхитектураGA

🗓 [29.11 - 02.12] Хореография и оркестрация микросервисов: открытый урок 🗓

Когда на Backend не один большой монолит, а десятки микросервисов, главный риск прячется не внутри сервисов, а между ними. Стоит допустить ошибку во взаимодействиях — и запросы «теряются», рассинхронизируются данные, неожиданные сбои...

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


💎 Хореография и оркестрация микросервисов: практика проектирования процессов

🗓 29 ноября - 2 декабря [сб-вт]
🕘 Время на обучение: ~4 часа

📚 Урок в записи, смотрете в удобное время

🔗 Зарегистрироваться


👉 План:
1. Основы архитектуры систем: монолит и микросервисы
2. Разработка схемы архитектуры для проекта
3. Оркестрация процессов: практика
4. Введение в брокеры сообщений (RabbitMQ, Kafka)
5. Хореография процессов: практика


Это не просто демо-урок, где вы узнаете 5% от реального объема знаний, а полноформатное обучение, после которого вы получите реальные инструменты и знания, которые помогут значительно поднять планку вашей карьеры.


Прокачивайте своё понимание архитектуры систем! Регистрируйтесь и смотрите занятие в удобное время с 29 ноября по 2 декабря 🙌

-----
Урок проводится в качестве вводного занятия к практической программе "Проектирование архитектуры" для системных аналитиков.