TykとKongの包括的な比較はありますか？
私はしばらくの間（約2年）マイクロサービス（Spring Cloud）を開発しており、Netflix Zuulを頻繁に使用しています。それは多くの機能と優れた機能を提供しますが、私の開発者の心は代替案を知ることに迷い、TykとKongについて知るようになりました。
個々のドキュメントとブログを読んで、多かれ少なかれどちらも同じような機能を提供していることを理解しました。この2つと、実装した実際の例との包括的な比較は、理解に非常に役立ちます。
CI/CDによると、どちらも「コードとしてのインフラストラクチャ」アプローチに準拠できるため、デプロイメントパイプラインの実践に関する用語の違いはわかりません。
- tyk API function-setはKongに比べて多く、ビジネスをAPIに依存している場合に意味があります（一部の請求と統合する必要がある...） https://tyk.io/docs/tyk- rest-api/api-definition-objects /
一方、KongのAPIは機能が制限されており、用語IMHOは理解できません： https://galileo.gelato.io/docs/versions/2.0.0/
- KongはDashBoard/UIにGalileoレポートツールを使用し、tykは独自のDashBoardを使用します。これには、レポート機能だけでなく、UIを使いたい場合はほとんどすべての管理機能も含まれます。
- レガシーAPIを外部の世界に変換する必要がある場合、tykにはXML <-> JSON <-> YAML <-> Customの変換に使用できる変換関数があります
- Tykでは、LuaだけでなくGo、Javaでも拡張機能をコーディングできます。 Python。 .NET、Javascript ...
- DRのニーズがある場合、tykには、災害サイトを含むエンタープライズレベルのアーキテクチャを対象とするマルチデータセンターオプションがあります。
- パフォーマンスが必要な場合は、tykをGoで記述します。 （tykのベンチマークの結果、約3000リクエスト/秒で応答しました。コングは同じVM）で約2500リクエスト/秒を返しました）
したがって、ニーズに基づいて、ニーズのいずれかが上記のいずれかに一致する場合は、tykを検討できます。そうでない場合は、もっと好きな方を検討できます...
Tykと一緒に行きます。私は両方を評価し、そのJavascript（オットーを介して）、PythonおよびGrpcミドルウェアエンジン）により、Lu/nginxベースのKongよりも（imho）Tyk（go）を拡張する方がはるかに簡単でした。
どちらもオープンソースであり、APIを介して制御できますが、kongのgui製品（他のossプロジェクト）は中途半端で、セットアップがはるかに困難であるように見えました。
エンタープライズ/ sassモデルから（オプションに対して支払われます）。 TykはKongの提供物を地図から吹き飛ばしました。 Tykのアーキテクチャは、ゲートウェイ、分析、およびダッシュボードコンポーネントに関する懸念を明確に分離しているので、はるかに健全に思えます。うまくまとめられており、コミュニティフォーラムはTyk開発者から非常に速い応答を受け取ります。
少し自慢します。 Moesifの私の共同創設者は、さまざまなAPIゲートウェイの最も包括的な比較を書いたところです。最後に、一目でわかるテーブルがあります。