API Gateway — это архитектурная схема услуги, которая находится между клиентом и внутренними бэкэнд -службами.
Ворота принимает все запросы клиента и в некоторых случаях передает их в правильный сервис или даже в несколько услуг.
Он используется для внедрения централизованных решений для аутентификации запросов, ограничения скорости, сбора статистики и ограничения общественного доступа к одной точке въезда.
Аутентификация
Наличие одной точки входа означает, что вы можете аутентифицировать запросы, прежде чем передавать их внутренним, а иногда и чувствительным сервисам. Логика аутентификации не должна быть дублирована вокруг различных служб и может оставаться только в шлюзе API.
Ограничение скорости
Вы можете ограничить количество запросов, которые пользователи генерируют на ваш сервер, чтобы уменьшить нагрузку. Вместо того, чтобы внедрить этот механизм в каждой службе, вы можете просто реализовать его один раз в своем шлюзе API. Это может быть очень удобно, чтобы предотвратить атаку DDOS или вредоносного пользователя, пытающегося сломать вашу систему.
Единственная точка входа
С точки зрения безопасности, этот момент очень важен. Если вы следите за строгими предприятиями, вам может потребоваться отслеживать данные, которые входят и выходят из вашей системы. Наличие одной точки входа в систему сделает эту задачу намного проще. Только одна услуга, которую необходимо контролировать.
Есть больше преимуществ, но все они полагаются на тот факт, что есть одна точка входа, поэтому вы можете реализовать любую логику, которую вы хотите только один раз. Не нужно перемещать его в другие услуги.
Производительность
При представлении среднего человека между клиентом и фактическим сервисом, который выполняет запрос, всегда будут накладные расходы. Запрос должен перейти от клиента к шлюзу API. Оттуда продолжайте обслуживание, вернитесь к шлюзу API, а затем к клиенту. Вы можете сократить время в оба конца, транслируя запросы и убедившись, что шлюз API и службы находились в одной и той же зоне (в облачном провайдере). Тем не менее, всегда будут накладные расходы.
Единственная точка отказа
Одна точка входа также означает одну точку отказа. Если шлюз API не работает, все клиенты не смогут использовать систему. Вам нужно будет убедиться, что это не может произойти, и сильно контролировать шлюз API. В противном случае у вас есть тикающая бомба в вашей системе.
Когда я начал ломать Daily.dev Монолит к небольшим сервисам, я добавил пользовательский шлюз API. Моя главная причина состояла в том, чтобы обрабатывать аутентификацию централизованной манерой.
Некоторое время это было хорошо, но в конце дня я не мог вынести идею, что это влияет на производительность моей системы. Я распределял трассировку на месте Так что я знал это точно.
На прошлой неделе я решил сломать шаблон API Gateway и выставить другие услуги. Стоимость производительности была слишком большой, чтобы нести. Это оказалось великолепным, в конце статьи я делюсь некоторыми статистиками.
Важно подчеркнуть, что для каждого варианта использования может быть другое решение, я просто делюсь здесь своей историей. Это не значит, что вы также должны удалить свой шлюз API.
Честно говоря, это было не сложно достичь, а наверняка страшное путешествие. В шлюзе API не было много логики, помимо запросов на прокси и аутентификации. Поэтому мне пришлось подумать только о решении только этих двух проблем. Я сделал это доказательство концепции в моем сервисе GraphQL.
Аутентификация
Наша система аутентификации основана на токене JWT, который хранится в файле cookie. Основным преимуществом JWT является то, что это токен без гражданства. Вам не нужна база данных, чтобы проверить токен, все, что вам нужно, — это ключ, с которой она была подписана. Я дублировал функцию проверки токена JWT в шлюзе в мою службу GraphQL, чтобы само по себе обрабатывать аутентификацию. Эта часть была легкой и простой.
Прокси -запросы
Теперь для страшной части. Мне нужно было разоблачить свой сервис GraphQL общественности, не меняя клиента и не вводя время простоя. Я управляю своей инфраструктурой на Kubernetes, поэтому существует только один способ разоблачения услуг, входа. Ресурс Ingress определяет, как направлять внешний трафик между внутренними службами. За кулисами он создает балансировщик облачной нагрузки Google. Ingress поддерживает маршрутизацию на основе пути, так что это было идеально для меня.
Одна вещь, которую я знал, изменение настроек входа может занять несколько минут и может вызвать простоя. Таким образом, изменение производственного входа выходит за рамки. Я решил создать новый вход, проверить его, а затем сделать переключатель.
Вот новая конфигурация Ingress, я не хочу вдаваться в подробности, так как она выходит из области, но вы можете увидеть маршрутизацию на основе пути. По умолчанию запросы направлены на шлюз, но запросы GraphQL идут в службу API.
apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
annotations:
kubernetes.io/ingress.global-static-ip-name: daily-ingress-ip
labels:
app: daily
name: daily-ingress
namespace: daily
spec:
rules:
- http:
paths:
- path: /*
backend:
serviceName: daily-gateway
servicePort: http
- path: /graphql
backend:
serviceName: daily-api-v2
servicePort: http
tls:
- hosts:
- app.dailynow.co
secretName: app-dailynow-co-tls
- hosts:
- api.daily.dev
secretName: api-daily-dev-tls
После того, как я развернул новый вход, я установил свой файл локального хоста в point api.daily.dev в новый вход, чтобы я мог проверить его локально. Я сделал несколько ручных проверок и подтвердил, что эта новая настройка работает, включая аутентификацию.
Затем я приступил к изменению DNS на IP New Ingress. Только через несколько дней я решил удалить старый вход. Изменение производственной инфраструктуры требует времени и требует терпения, не спешите ее.
Я сделал это! Сделал переключение без простоя 🚀
Вы сделали все это, чтобы увидеть некоторую статистику, я знаю это! Итак, вот и мы, я сделал 3 разных сравнения:
- Производительность нашего анонимного канала, который является самым популярным запросом для незарегистрированных пользователей
- Производительность нашего зарегистрированного использования каналов, который является наиболее сложным запросом в системе
- Производительность маршрута GraphQL. Это сравнение, которое показывает общую тенденцию этого изменения.
Диаграммы сравнивают производительность после изменения производительности до изменения в то же время недели.
С нетерпением жду ваших мыслей ✨
Повседневная Предоставляет лучшие новости программирования каждую новую вкладку. Мы будем ранжировать сотни квалифицированных источников для вас, чтобы вы могли взломать будущее.
Оригинал: «https://dev.to/dailydotdev/breaking-the-gateway-1m5h»