Насколько хорош Krakend по сравнению с Kong? - PullRequest
0 голосов
/ 04 февраля 2020

Я застрял в выборе одного шлюза API из трех указанных ниже шлюзов API:

  1. KrakenD (https://www.krakend.io/)
  2. Kong (https://konghq.com/kong/)
  3. Spring Cloud Gateway (https://cloud.spring.io/spring-cloud-gateway/reference/html/)

Мои требования:

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

Все три из них хорошо выглядят из списка функций и производительность мудрая. Я думаю об ослаблении второго требования, поскольку я не уверен, является ли это хорошей практикой или нет.

1 Ответ

2 голосов
/ 15 апреля 2020

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

Я постараюсь обобщить здесь основные моменты в соответствии с вашими требованиями.

И Kong, и KrakenD предлагают "большинство" функций шлюза API. Хотя это слово нечеткое, по крайней мере все они охватывают такие вещи, как маршрутизация, ограничение скорости, авторизация и т. Д.

Kong

Kong - это в основном прокси Nginx, который добавляет много функциональность поверх него с использованием Lua.

При использовании Kong ваши конечные точки имеют отношение 1: 1 с вашими бэкэндами. Это означает, что вы объявляете конечную точку в Конге, которая предоставляет данные из одного бэкэнда и выполняет волхвы c в середине (авторизация, ограничение и т. Д. c). Этот маги c является сущностью Kong и основан на Lua плагинах (к сожалению, они не записаны в C как Nginx).

Если вы хотите объединить данные из нескольких бэкэнды в одну конечную точку, Kong не вписывается в ваш сценарий.

Наконец, Kong имеет с состоянием (впечатляет, как они пытаются продать его наоборот, но это не так объем этого вопроса). Конфигурация живет в базе данных, и изменения в конфигурации происходят через API, который в конечном итоге изменяет ее внутренний Postgres или эквивалентный.

Производительность также неизбежно связана с существованием этой базы данных (и Lua ), и переход в несколько регионов может быть настоящей болью.

Функциональность Kong может быть расширена с помощью Lua кода.

В итоге:

  • Прокси с сквозные проблемы
  • Узлы требуют координации и синхронизации
  • Изменяемая конфигурация
  • База данных является источником истины
  • Больше деталей, больше сложности
  • Мультирегиональная задержка
  • Требуется мощное оборудование для запуска
  • Настройки в Lua

KrakenD

KrakenD - это сервис, написанный на Начните использовать Go, используя преимущества языковых возможностей для параллелизма, скорости и небольшого размера. С точки зрения производительности, это выигрышная скаковая лошадь.

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

KrakenD равен без сохранения состояния , ваш API версии так же, как и с остальная часть кода, используя git. И вы развертываете его так же, как и в своем приложении (например, конвейер CI / CD, который выдвигает новый контейнер с новой конфигурацией и разворачивается). Поскольку все в конфигурации, нет необходимости иметь центральную базу данных, ни один узел не нуждается в связи друг с другом.

В соответствии с настройками, с KrakenD вы можете создавать промежуточное ПО, плагины или просто создавать скрипты на нескольких языках. : Go, Lua, тип общего языка выражений (CEL) JS - и марсианский DSL.

В итоге:

  • Создание API на лету использование вышестоящих сервисов со сквозными проблемами (шлюз API).
  • Не прокси, хотя его можно использовать как один.
  • Нет координации узлов
  • Синхронизация не требуется
  • Нулевая сложность (docker контейнер с файлом конфигурации)
  • Нет проблем для нескольких регионов
  • Декларативная конфигурация
  • Неизменная инфраструктура
  • Работает на микро и малых машинах в производстве без проблем.
  • Настройки в Go, Lua, CEL и марсианских DSL

Spring Cloud Gateway

(а также Zuul ) в основном Java разработчиками, которые хотят остаться в пространстве JVM. Я менее знаком с этим, но его дизайн также предназначен для проксирования к существующим сервисам, добавляет также перекрестные проблемы шлюза API.

Я рассматриваю его скорее как основу, которую вы используете для доставки своего API , С этим продуктом вам нужно кодировать преобразования самостоятельно в Java. Включенные функциональные возможности шлюза также декларативны.

-

Я надеюсь, что это проливает некоторый свет

...