API-шлюз: єдина точка входу для багатьох сервісів

Коротко: Посередник, що приймає всі запити ззовні й пересилає їх відповідним внутрішнім сервісам.

Докладніше: За безлічі невеликих сервісів (мікросервісів) було б обтяжливо, якби кожному застосунку доводилося знати й захищати кожен сервіс окремо. API-шлюз об’єднує доступ: у нього одна адреса, він перевіряє запити й розподіляє їх. Наскрізні завдання вирішуються один раз централізовано, а не в кожному сервісі.

Подробиці

Завдання

• Маршрутизація (routing): /orders іде до сервісу замовлень, /users — до сервісу користувачів.
• Автентифікація та авторизація: перевірка токенів, перш ніж щось дійде до сервісів.
• Обмеження частоти запитів і захист від зловживань.
• Термінування TLS: шифрування на вході, всередині простіше.
• Об’єднання кількох відповідей в одну (агрегація) і перетворення форматів.
• Журналювання, метрики, кешування.

Приклад правила маршрутизації

У нотації, схожій на nginx:

location /api/orders/ { proxy_pass http://orderservice:8080/; }
location /api/users/  { proxy_pass http://userservice:8080/; }

На практиці використовують такі продукти, як Kong, Traefik, AWS API Gateway або Azure API Management.

Backend for frontend (BFF)

Варіант — окремий шлюз на кожен тип застосунку, наприклад один для мобільного застосунку й один для вебінтерфейсу. Кожен віддає саме ті дані, які потрібні його клієнту, і позбавляє від безлічі окремих викликів.

Недоліки

Шлюз — центральна точка: якщо він вийде з ладу, зникне все, і він може стати вузьким місцем. Тому його слід експлуатувати з резервуванням і високою доступністю. Він також не повинен накопичувати надто багато бізнес-логіки, інакше виникне новий моноліт. Чистий трафік між сервісами зазвичай іде не через нього, а через сервісну сітку (service mesh).

Див. також: Мікросервіси, nginx і зворотний проксі, Обмеження частоти запитів, Балансувальник навантаження