[はじめに]：
香港はネイティブ雲、効率的、スケーラブルな分散APIゲートウェイです。2015年以来、githubのオープン、広く注目した後、+スターの1.68ワットを収穫してきた、そのコア値は、高いパフォーマンスとスケーラビリティがあります。
なぜ我々はAPIが必要なのかゲートウェイ（詳細）
マイクロサービスアーキテクチャの下では、サービスは分割は非常にだけでなく、より困難なサービスの一元管理に結合度を減らし、断片化されています。図に示すように監視し、他の一般的な機能は、これらの一元管理にグローバルな視野を持っていない、システムの保守を行い、別途各サービスで実装する必要があり、ガバナンスサービス、認証、制限、ログの古いシステムの下で、左機能。ゲートウェイは、問題を解決することを約束されたAPIは、拡張性に基づいてシステムを改善し、これらのマイクロサービスナノチューブの一般的な機能のためです。マイクロサービスAPIゲートウェイと、右側に示すように、サービスはよりその分野に焦点を当て、それ自体を作ることができ、優れたサービスコールやサービスプロバイダは、アイソレーションを行います。
なぜ香港
SpringCloudの選手は確かにZuul2とSpringcloudゲートウェイと他のフレームワークを含め、このZuulルーティングコンポーネントを、聞いたことが、国の認知度は低くありません。香港は、より多くの単語の製品にライニングされている間はい、私は、これらのコンポーネントまたはフレームに呼び出します。このケースでは、単純に比較するとZuulコングできます。
唯一Zuulは、基本的なルーティング機能を提供するので、開発者が独自の研究開発Zuulフィルターを必要とする、あなたはアプリケーションの必要性が制限電流追加するとき、Zuulを使用することを選択した場合たとえば、あなたはまた、すべての問題であってもよいが、この場合ではない機能を感じるかもしれませんより多くの需要に基づいて、残念ながら、ZuulユーザーがZuulにこれらの複雑を自分で取る必要があります。香港の場合は、電流制限機能は、ボックスの唯一の簡単な構成でプラグイン、アウトすることができますです。
香港プラグイン機構は、高い拡張性の源である、香港を容易ゲートウェイにルーティングし、サービスに必要なプラグインの種々の基本的な特性を提供することができ、香港は完全にサポートしています。
- クラウドネイティブ：プラットフォームに依存しないが、香港はKubernetesにベアメタルから実行することができます
- 動的ルーティング：香港の後ろにOpenResty + Luaのある、それはOpenRestyからルーティング動的特性を継承します
- ヒューズ
- ヘルスチェック
- ログ：HTTPを記録することができ、TCP、UDP、および香港の要求に応じインチ
- 認証：アクセス制御、IPブラックとホワイトリスト、それはまたOpenRestyの特徴であります
- SSL：セットアップ基本的なサービスやAPIのための具体的なSSL証明書。
- モニタリング：香港は、リアルタイム監視プラグインを提供します
- 認定：フルサポートHMAC、JWT、基本、OAuth2.0他の一般的に使用されるプロトコルで
- 限定的
- RESTのAPI：残りAPIを介して、構成管理、面倒な設定ファイルからの解放
- 可用性：分散型の自然サポート
- 高性能：nginxのは、非ブロッキング通信に裏打ちされた、パフォーマンス言うまでもなくと言って
- プラグイン機構は：ボックスのプラグ数多く出を提供し、かつ拡張可能なカスタム・プラグイン・インターフェースを簡単にあり、ユーザーはLuaのを使用して、独自のプラグインを開発することができます
上記のこれらの特性は、繰り返し実際には、香港を使用した後、nginxのは完全に放棄することができ、背後OpenRestyコングを述べ、香港はnginxのの機能的なスーパーセットです。
Zuulでの基本的なルーティング機能に加えだけでなく、より密接に、独自の外SpringCloudと一緒に、それはどんな利点を持っていません。
香港の経営スタイル
簡単には、すべてがRESTfulなAPIの操作が行われているHTTPに基づいており、香港の後ろに使用します。
HTTPとHTTPSポートフォワーディングしている8443分の8000、nginxのは、デフォルトのポート80に相当し、ポート8001がデフォルトのポート管理で、我々は動的にHTTP RESTfulなAPIを介して香港の構成を管理することができます。
例：一般的な構成nginxの
upstream helloUpstream {
server localhost:3000 weight=100;
}
server {
listen 80;
location /hello {
proxy_pass http://helloUpstream;
}
}この簡単な構成上のnginxのは、それが次のHTTPリクエストに変換することができます。
に対応した香港の設定：
# 配置 upstream
curl -X POST http://localhost:8001/upstreams --data "name=helloUpstream"
# 配置 target
curl -X POST http://localhost:8001/upstreams/hello/targets --data "target=localhost:3000" --data "weight=100"
# 配置 service
curl -X POST http://localhost:8001/services --data "name=hello" --data "host=helloUpstream"
# 配置 route
curl -X POST http://localhost:8001/routes --data "paths[]=/hello" --data "service.id=8695cc65-16c1-43b1-95a1-5d30d0a50409"このすべては、手動でリロードnginx.confにせずに、動的です。
从上面的配置及字面解释大概能够推测出他们的职责：upstream，target，service，route，他们便是 Kong 最最核心的四个对象
upstream 是对上游服务器的抽象；
target 代表了一个物理服务，是 ip + port 的抽象；
service 是抽象层面的服务，他可以直接映射到一个物理服务(host 指向 ip + port)，也可以指向一个upstream来做到负载均衡；
route 是路由的抽象，他负责将实际的 request 映射到 service。他们的关系如下：
- upstream 和 target ：1 对 n
- service 和 upstream ：1 对 1 或 1 对 0 （service 也可以直接指向具体的 target，相当于不做负载均衡）
- service 和 route：1 对 n
高可扩展性的背后—插件机制
Kong 的另一大特色便是其插件机制，这也是我认为的 Kong 最优雅的一个设计。
文章开始时我们便提到一点，微服务架构中，网关应当承担所有服务共同需要的那部分功能，这一节我们便来介绍下，Kong 如何添加 jwt 插件，限流插件。
插件（Plugins）装在哪儿？对于部分插件，可能是全局的，影响范围是整个 Kong 服务；大多数插件都是装在 service 或者 route 之上。这使得插件的影响范围非常灵活，我们可能只需要对核心接口进行限流控制，只需要对部分接口进行权限控制，这时候，对特定的 service 和 route 进行定向的配置即可
为 hello 服务添加50次/秒的限流
curl -X POST http://localhost:8001/services/hello/plugins \
--data "name=rate-limiting" \
--data "config.second=50"为 hello 服务添加 jwt 插件
curl -X POST http://localhost:8001/services/login/plugins \
--data "name=jwt"同理，插件也可以安装在 route 之上
curl -X POST http://localhost:8001/routes/{routeId}/plugins \
--data "name=rate-limiting" \
--data "config.second=50"
curl -X POST http://localhost:8001/routes/{routeId}/plugins \
--data "name=jwt"在官方文档中，我们可以获取全部的插件 https://konghq.com/plugins/，部分插件需要收费的企业版才可使用。
本文参考：
https://mp.weixin.qq.com/s/CWGy6cwy6QGLvwByurEGbw
https://www.jianshu.com/nb/27758849
[sleepy↓]