简单示例
为什么使用 Kong
当我们对原有业务系统进行微服务改造时，客户端（包括移动端和 Web 端等）如何与各个微服务进行交互这个问题需要我们认真考虑，服务数量的增加会导致一些基础功能的实现变得困难，如认证授权、负载均衡和服务间通信管理。
但微服务网关所提供的访问限制、安全、流量控制、分析监控、日志、请求转发、合成和协议转换功能，可以使得开发者更加集中精力在各个业务服务的实现上，从而避免将大量时间花在考虑如何解决这些问题上。
在业内流行的微服务网关组件中，基于 Nginx 的 Kong 表现突出。Kong 是 Mashape 开源的高性能、高可用 API 网关，也可以认为是 API 服务管理层。
它可以通过插件扩展已有功能，这些插件（使用 Lua 编写）在 API 请求响应循环的生命周期中被执行。
除此之外，Kong 本身还提供了包括 HTTP 基本认证、密钥认证、CORS、TCP、UDP、文件日志、API 请求限流、请求转发及 Nginx 监控等基本功能。
在用 Kong 进行实践之前，我们得先介绍一些 Kong 中常用的术语，因为这些术语在实践中会经常用得到。
- Route：请求的转发规则，按照 Hostname 和 PATH，将请求转发给 Service。
- Services：多个 Upstream 的集合，是 Route 的转发目标。
- Consumer：API 的用户，记录用户信息。
- Plugin：插件，可以是全局的，也可以绑定到 Service、Router 或者 Consumer。
- Certificate：HTTPS 配置的证书。
- SNI：域名与 Certificate 的绑定，指定了一个域名对应的 HTTPS 证书。
- Upstream：上游对象用来表示虚拟主机名，拥有多个服务（目标）时，会对请求进行负载均衡。
- Target：最终处理请求的 Backend 服务。
使用 docker 快速启动服务
https://github.com/Kong/docker-kong
1 2 | |
1 2 | |
The Gateway will be available on the following ports on localhost:
:8000 on which Kong listens for incoming HTTP traffic from your clients, and forwards it to your upstream services.
:8001 on which the Admin API used to configure Kong listens.
https://docs.konghq.com/gateway-oss/2.6.x/getting-started/configuring-a-service/