Реалізація API Gateway Pattern для мікросервісів
Уявіть: у вас 15 мікросервісів, кожен зі своїм API. Фронтенд робить десятки запитів до різних ендпоінтів, а аутентифікація дублюється в кожному сервісі. Один невдалий рефакторинг — і клієнти ловлять 500-ті помилки. API Gateway вирішує цю біль: єдина точка входу, централізована маршрутизація, аутентифікація та rate limiting. Замість прямих викликів до десятків сервісів клієнт спілкується з одним шлюзом, який маршрутизує запити, агрегує дані та застосовує політики безпеки.
Цей паттерн спрощує безпеку, знижує навантаження на сервіси та робить систему масштабованою. Наші інженери з 7+ річним досвідом у мікросервісах впроваджують API Gateway під ключ — від вибору інструменту до налаштування моніторингу. Зв'яжіться з нами для консультації щодо вашого проекту.
Технічні проблеми мікросервісної архітектури
Зазначимо: коли клієнт запитує дані з різних сервісів, виникає проблема множинних викликів. Наприклад, сторінка профілю потребує дані користувача, його замовлень та сповіщень. Без шлюзу клієнт робить 3 запити. З API Gateway — один. Шлюз паралельно збирає дані через Promise.allSettled і повертає єдину відповідь. Це знижує затримки на 40% і спрощує клієнтську логіку.
Інша проблема — дублювання аутентифікації. Кожен мікросервіс вимушений перевіряти JWT, що збільшує latency і ризик помилок. API Gateway перевіряє токен один раз і передає дані користувача в заголовках. Це зменшує навантаження на сервіси та централізує безпеку.
Як API Gateway вирішує проблему N+1 запитів?
Агрегація запитів (BFF-паттерн у шлюзі)
Мобільний клієнт за один запит отримує дані з кількох сервісів. Шлюз паралельно звертається до них і збирає відповідь у єдиний JSON. Приклад реалізації на Express:
// Gateway aggregates data from multiple services
app.get('/api/dashboard/:userId', jwtMiddleware, async (req, res) => {
const { userId } = req.params;
const [user, orders, notifications] = await Promise.allSettled([
userService.get(`/users/${userId}`),
orderService.get(`/orders?customerId=${userId}&limit=5`),
notificationService.get(`/notifications/${userId}/unread`)
]);
res.json({
user: user.status === 'fulfilled' ? user.value.data : null,
recentOrders: orders.status === 'fulfilled' ? orders.value.data : [],
unreadCount: notifications.status === 'fulfilled'
? notifications.value.data.count : 0
});
});
Які метрики покращує API Gateway?
Час відповіді (TTFB) зменшується за рахунок агрегації, кількість мережевих запитів скорочується в 3-5 разів. Core Web Vitals (LCP, CLS) покращуються, оскільки клієнт отримує всі дані однією відповіддю. Шлюз також знижує навантаження на мікросервіси — вони обробляють лише перевірені запити.
Як ми впроваджуємо API Gateway
Функції, які налаштовуємо
- Маршрутизація —
/api/orders→ Order Service,/api/users→ User Service - Аутентифікація та авторизація — JWT/OAuth2 перевіряється один раз у шлюзі
- Rate Limiting — захист від зловживань
- SSL Termination — TLS завершується на шлюзі, мікросервіси спілкуються по HTTP всередині кластера
- Request/Response трансформація — зміна форматів, додавання заголовків
- Агрегація запитів — один запит клієнта → кілька запитів до сервісів
- Circuit Breaker — захист від каскадних відмов
- Логування та трейсинг — єдина точка збору access logs
Порівняння інструментів
| Інструмент | Тип | Особливості |
|---|---|---|
| Kong | Self-hosted / Cloud | Плагіни на Lua/Go, Kubernetes Ingress |
| Traefik | Self-hosted | Автодискавері в Docker/K8s |
| AWS API Gateway | Managed | Інтеграція з Lambda, IAM |
| NGINX + Lua | Self-hosted | Максимальний контроль |
| Envoy | Proxy | gRPC, складні сценарії |
| Express Gateway | Node.js | Прості випадки |
Kong краще підходить для складних сценаріїв з кастомними плагінами, Traefik виграє в інтеграції з Kubernetes. Ми обираємо інструмент під ваш стек. Наш досвід включає проекти з Kong (понад 50 сервісів) та Traefik (K8s-кластери до 30 нод).
Конфігурація Kong
Kong — найпопулярніший self-hosted шлюз:
# kong.yaml (декларативна конфігурація)
_format_version: "3.0"
services:
- name: order-service
url: http://order-service:3000
routes:
- name: orders-route
paths: ["/api/orders"]
methods: ["GET", "POST", "PUT", "DELETE"]
- name: user-service
url: http://user-service:3001
routes:
- name: users-route
paths: ["/api/users"]
methods: ["GET", "PUT"]
plugins:
- name: jwt
config:
claims_to_verify: ["exp"]
- name: rate-limiting
config:
minute: 100
hour: 5000
policy: local
- name: request-transformer
config:
add:
headers: ["X-Service-Version:1.0"]
Аутентифікація на рівні шлюзу
JWT верифікується в шлюзі, мікросервіси отримують вже перевірений заголовок з даними користувача:
// Кастомний middleware на Express Gateway
async function jwtMiddleware(req, res, next) {
const token = req.headers.authorization?.replace('Bearer ', '');
if (!token) return res.status(401).json({ error: 'No token' });
try {
const payload = jwt.verify(token, process.env.JWT_SECRET);
// Прокидаємо дані користувача в заголовках
req.headers['X-User-Id'] = payload.sub;
req.headers['X-User-Role'] = payload.role;
req.headers['X-User-Email'] = payload.email;
next();
} catch {
res.status(401).json({ error: 'Invalid token' });
}
}
Приклад конфігурації Traefik у Kubernetes
# Traefik IngressRoute
apiVersion: traefik.containo.us/v1alpha1
kind: IngressRoute
metadata:
name: api-gateway
spec:
entryPoints:
- websecure
routes:
- match: PathPrefix(`/api/orders`)
kind: Rule
services:
- name: order-service
port: 3000
middlewares:
- name: jwt-auth
- name: rate-limit
- match: PathPrefix(`/api/users`)
kind: Rule
services:
- name: user-service
port: 3001
middlewares:
- name: jwt-auth
---
apiVersion: traefik.containo.us/v1alpha1
kind: Middleware
metadata:
name: rate-limit
spec:
rateLimit:
average: 100
burst: 50
period: 1m
Процес робіт з впровадження
| Етап | Тривалість | Результат |
|---|---|---|
| Аудит архітектури | 1-2 дні | Схема маршрутів, вимоги до безпеки |
| Налаштування базового шлюзу | 3-5 днів | Робоча маршрутизація, JWT-аутентифікація |
| Розширена конфігурація | 2-3 дні | Rate limiting, circuit breaker, логування |
| Кастомна агрегація | 1-2 тижні | BFF-ендпоінти, оптимізація запитів |
Вартість розраховується індивідуально після аудиту вашої архітектури. Замовте консультацію — оцінимо проект безкоштовно.
Склад реалізації API Gateway
- Проектування маршрутів і політик безпеки
- Налаштування Kong, Traefik або хмарного шлюзу під вашу інфраструктуру
- Інтеграція з JWT/OAuth2, LDAP або іншим провайдером
- Конфігурація rate limiting, circuit breaker та моніторингу
- Документація API та інструкції для команди
- Передача доступів та навчання ваших інженерів
Ми також надаємо підтримку після впровадження: оновлення версій, оптимізація продуктивності. Наші інженери мають сертифікати з Kubernetes та Kong, понад 7 років досвіду та 50+ успішних проектів. Ми гарантуємо стабільну роботу шлюзу під навантаженням. Отримайте консультацію для вашого проекту.
Додаткові матеріали
Детальніше про паттерн можна прочитати в Wikipedia. Офіційна документація Kong доступна на konghq.com.