Шлюз API проти зворотного проксі

Для того, щоб мати справу з архітектурою мікросервісу, її часто використовують поряд із зворотним проксі (наприклад, nginx або apache httpd) і для наскрізних проблем, що стосуються схеми реалізації шлюзу API API . Іноді Reverse proxy виконує роботу шлюзу API.
Добре буде побачити чіткі відмінності між цими двома підходами. Схоже, що потенційною перевагою використання шлюзу API є використання декількох мікросервісів та агрегування результатів. Усі інші обов'язки шлюзу API можна реалізувати за допомогою Reverse Proxy.Such як:

• Аутентифікація (Це можна зробити за допомогою скриптів nginx LUA);
• Безпека транспорту. Сама задача зворотного проксі;
• Балансування навантаження
• ….

Отже, виходячи з цього, виникає кілька питань:

1. Чи має сенс одночасно використовувати шлюз API та Reverse proxy (як приклад запит-> Api шлюз-> зворотний проксі (nginx) -> бетонний мікстосервіс)? У яких випадках?
2. Які ще відмінності, які можна реалізувати за допомогою шлюзу API, і які неможливо реалізувати через Reverse proxy, і навпаки?

Про них легше думати, якщо ти розумієш, що вони не є винятковими. Подумайте про шлюз API як про реалізацію зворотного проксі конкретного типу.

Що стосується ваших питань, то нечасто бачити обидва, які використовуються спільно, коли шлюз API розглядається як рівень програми, що сидить за зворотним проксі-сервером для балансування навантаження та перевірки стану здоров'я. Прикладом може бути щось на зразок сендвіч-архітектури WAF в тому, що шлюз вашого веб-додатка / API шлюзу прошитий зворотними проксі-рівнями: один для самого WAF, а другий для окремих мікросервісів, з якими він спілкується.

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

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

1. Це має сенс, поки кожен компонент у цій послідовності виконує своє призначення.
2. Відмінності не в списку функцій, а в способі застосування змін конфігурації.

Крім того, API - шлюз часто надається у вигляді SAAS, як Apigee або TYK , наприклад.

Також ось мій підручник про те, як створити простий шлюз API за допомогою Node.js https://memz.co/api-gateway-microservices-docker-node-js/

Сподіваюся, це допомагає.

Шлюзи API зазвичай працюють як конструкція L7.

Шлюзи API надають додаткову функціональність порівняно із звичайним зворотним проксі. Якщо ви розглядаєте деякі портали там, вони можуть надати:

• повне управління життєвим циклом API, включаючи документацію
• портал, який може бути використаний як джерело істини для різних клієнтських додатків і де ви можете надати клієнтське управління, обмеження ставок тощо.
• маршрутизація до різних версій API, включаючи канальні / бета версії
• виявлення моделей використання, реєстрація програм, отримання облікових даних клієнта тощо.

Однак з появою таких сервісних мереж, як Istio, консул багато функціональності шлюзів API буде включено в сітки.