Подтвердить что ты не робот

Есть ли всестороннее сравнение между Tyk против Kong?

Я разрабатывал микросервисы (Spring Cloud) на некоторое время (~ 2 года) и сильно использовал Netflix Zuul. Хотя он предлагает множество функциональных возможностей и отличных функций, мой ум разработчика бродил по пути к знанию об альтернативах и узнал о Тайке и Конге.

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

4b9b3361

ОТВЕТЫ

Ответ 1

В соответствии с CI/CD оба могут соответствовать подходу "Инфраструктура как код", поэтому я не вижу разницы в терминах практики развертывания развертывания.

  • Функция tyk API больше по сравнению с Kong, что может иметь смысл, если вы полагаетесь на свою бизнес-интерфейс (нужно интегрировать с некоторыми биллингами,...) https://tyk.io/docs/tyk-rest-api/api-definition-objects/

С другой стороны, API Конга имеет ограниченные функции и терминологию ИМХО не понятно: https://galileo.gelato.io/docs/versions/2.0.0/

  • Конг использует инструмент отчетности Galileo для DashBoard/UI, tyk использует собственный DashBoard, включая не только функции Reporting, но и почти все функции управления, если вы хотите пойти с пользовательским интерфейсом
  • Если вам нужно преобразовать устаревшие API в внешний мир, tyk имеет функцию Transform, которая может использоваться для преобразования XML ↔ JSON ↔ YAML ↔ Custom
  • В tyk вы можете кодировать расширение не только с помощью Lua, но и с Go, Java. Python..NET, Javascript...
  • Если у вас есть потребности в DR, tyk имеет параметр Multi-Datacenter, который предназначен для архитектуры уровня предприятия, включая сайт бедствия
  • Если вам нужна производительность, tyk записывается с помощью Go. (У нас есть контрольный тик, чтобы ответить примерно на 3000 req./sec, где Kong сделал около 2500 req./sec. На той же VM с теми же шаблонами APICall).

Итак, исходя из ваших потребностей, если какие-либо из ваших потребностей совпадают с одним из вышеперечисленных, вы можете рассмотреть tyk, если вы не можете рассмотреть то, что вам больше нравится...

Ответ 2

Пойдите с Тиком. Я оценил оба варианта, и было намного проще расширить (imho) Tyk (go) из-за его механизма Javascript (через otto), Python и Grpc промежуточного программного обеспечения, чем Kong, который основан на Lua/nginx.

Оба являются с открытым исходным кодом и управляемы через API, однако предложения kong gui (другие проекты oss) выглядели наполовину испеченными и их было намного сложнее настроить.

Из модели enterprise/sass (оплачивается для опций). Тык вытаскивает Конга с карты. Архитектура Tyk кажется намного более впечатляющей imho с четким разделением проблем для шлюзов, аналитики и компонентов приборной панели. Его хорошо собраны, а форумы сообщества получают молниеносные ответы от разработчиков Tyk.