Нужен ли мне действительно веб-сервер вместе с API - шлюзом в микросервисной архитектуре

Question

Прежде чем наши высококвалифицированные модераторы по разным причинам решат этот вопрос, я хотел бы подчеркнуть, что это в первую очередь связано с изменением дизайна моего текущего проекта.
Итак, к моему вопросу, в моем текущем приложении на Python яЯ использую Gunicorn вместе с Nginx.
Теперь, когда мы переходим в облако, я думаю, что мне действительно нужен nginx или какой-то другой веб-сервер.
В нашей облачной архитектуре мы будем использовать шлюз API, через который мы планируем:
1) Предоставить API-интерфейсы через Интернет
2) Балансировка нагрузки
3) Аутентификация и авторизация
Есть лилюбая другая цель веб-сервера, которая не может быть достигнута с помощью API-шлюза
Также является ли API-шлюз просто еще одним причудливым названием для веб-сервера?

Answer 1

Я отвечу, обращаясь к тому, что подразумевается под термином API-шлюз.Шлюз API - это реализация шаблона проектирования фасада.Этот шаблон, как следует из названия, просто означает размещение некоторого компонента перед некоторыми другими компонентами.В контексте веб-приложения API-интерфейс шлюза - это модуль, который находится перед вашими веб-службами / конечными точками.Однако, вопреки тому, что вы описали, аутентификация и авторизация обычно лучше всего подходят в качестве отдельных модулей / микросервисов в вашей архитектуре.Вот один из способов настройки службы API шлюза:

┌──────────────┐         (1)          ┌────────────────┐
│              ├─── authenthicate ──> │                │
│  gateway API │                      │ authentication │
│              │ <──── yes/no ────────┤                │
└───────┬───┬──┘                      └────────────────┘
        │   │         (2)
        │   └─────────────────────┐
    (3) │                         │
        │                         │
┌───────┴──────┐          ┌───────┴───────┐
│              │          │               │
│ web services │          │ authorization │
│              │          │               │
└──────────────┘          └───────────────┘

При таком дизайне все ваши компоненты теперь имеют единую точку для входа в систему / аутентификации.Модуль аутентификации в основном говорит «да» или «нет», и это также означает, что вам нужно поддерживать только один набор логики или кода для обработки всей вашей аутентификации.Это может показаться тривиальным, но представьте, сколько работы это спасет для такой компании, как Google или Microsoft, у которой есть десятки общедоступных продуктов и услуг.Обратите внимание, что на практике ваша аутентификация может быть многоуровневой или многоуровневой.Например, у вас могут быть уровни аутентификации 1FA и 2FA или что-то еще.

Следующим шагом, который происходит, является то, что API шлюза попадет в модуль авторизации, чтобы выяснить, имеет ли входящий запрос достаточные права дляполучить доступ к запрашиваемой конечной точке / услуге.Если он не , то шлюз отклонит запрос.Если это произойдет, то он разрешит запросу обратиться к соответствующему веб-сервису.

Примите во внимание, что как только аутентификация и авторизация оказываются вне пути, API-интерфейс шлюза в основном является просто большим маршрутизатором, который отображает входящие запросы на некоторыеконкретная конечная точка в одном или нескольких ваших приложений.Еще одно преимущество этой микросервисной структуры, о которой стоит упомянуть, состоит в том, что, если вам когда-либо потребуется сменить поставщика аутентификации или логику авторизации, вам нужно будет только изменить этот модуль.Если вы разумно кодируете интерфейс, необходимые для ваших приложений изменения должны быть минимальными.

Вот ссылка на документацию для Spring Cloud Gateway Framework.В этом случае приложение Spring Boot используется в качестве реализации API шлюза.