---

1. 为什么需要网关

微服务是运行在网络中的互相协调、互相配合的服务单元，服务于服务间采用轻量级的通信机制互相沟通，一般有不同的网络地址，而外部的客户端可能需要调用多个服务的接口才能完成一个业务需求。

如果客户端直接和微服务进行通信，会存在下列问题：

• 客户端需要管理微服务地址；
• 访问服务存在跨域请求；
• 服务的认证方式可能不同；
• 难以根据业务需求快速扩展。

2. 什么是 Kong Gateway

你可能听说过 Kong Gateway 是基于 Nginx 构建的，利用其稳定性和效率。但这怎么可能呢？

更准确地说，Kong Gateway 是一个在 Nginx 中运行的 Lua 应用程序，由lua-nginx-module 实现。Kong 不是用这个模块编译 Nginx，而是随OpenResty一起分发，它已经包含 lua-nginx-module。OpenResty不是Nginx 的一个分支，而是一组扩展其功能的模块。

这为可插拔架构奠定了基础，其中 Lua 脚本（称为插件）可以在运行时启用和执行。正因为如此，我们喜欢将 Kong Gateway 视为微服务架构的典范：在其核心，它实现了数据库抽象、路由和插件管理。插件可以存在于单独的代码库中，并且可以注入到请求生命周期的任何地方，只需几行代码即可。

Kong通过插件的形式提供负载均衡、身份验证、权限管理、.健康检查、速率限制、转换、日志记录等功能。

2.1. Kong的主要功能

• 高级路由、负载平衡、健康检查——所有这些都可以通过管理 API 或声明性配置进行配置。
• 使用 JWT、基本身份验证、ACL 等方法对 API 进行身份验证和授权。
• 代理、SSL/TLS 终止以及对 L4 或 L7 流量的连接支持。
• 用于实施流量控制、req/res 转换、日志记录、监控和包括插件开发人员中心的插件。
• 复杂的部署模型，如声明式无数据库部署和混合部署（控制平面/数据平面分离），没有任何供应商锁定。

2.2. Kong监听的端口

· 8000：此端口是KONG用来监听来自客户端传入的HTTP请求，并将此请求转发到上游服务器；
· 8443：此端口是KONG用来监听来自客户端传入的HTTPS请求的。它跟8000端口的功能类似，但是它只是用来监听HTTPS请求的，没有转发功能。您可以通过修改配置文件来禁止它；
· 8001：通过此端口，管理者可以对KONG的监听服务进行配置；
· 8444：通过此端口，管理者可以对HTTP请求进行监控；

3. 什么是Konga

Konga 是 Kong 的一个开源的管理后台，可以对于管理kong节点情况进行查看、监控和预警，konga主要特性如下：

• 多用户管理
• 管理多个Kong节点
• 电子邮件异常信息通知
• 管理所有Kong Admin API
• 使用快照备份，还原和迁移Kong节点
• 使用运行状况检查监控节点和API状态
• 轻松的数据库集成（MySQL，postgresSQL，MongoDB）

4. Docker部署Kong及Konga

4.1. 创建 postgres 容器

docker run -d --name kong-database --restart always -p 5432:5432 -e “POSTGRES_USER=kong” -e “POSTGRES_PASSWORD=kong123” -e “POSTGRES_DB=postgres” -e ALLOW_IP_RANGE=0.0.0.0/0 -v /mnt/kong_data:/var/lib/postgresql/data postgres:9.6

4.2. 初始化 kong 数据库

docker run --rm -e “KONG_DATABASE=postgres” -e “KONG_PG_HOST=172.29.0.108” -e “KONG_PG_PORT=5432” -e “KONG_PG_USER=kong” -e “KONG_PG_PASSWORD=kong123” -e “KONG_CASSANDRA_CONTACT_POINTS=kong-database” kong:2.4 kong migrations bootstrap

4.3. 创建 kong 容器

docker run -d --name kong -e “KONG_DATABASE=postgres” -e “KONG_PG_HOST=172.1.0.108” -e “KONG_PG_PORT=5432” -e “KONG_PG_USER=kong” -e “KONG_PG_PASSWORD=kong123” -e “KONG_CASSANDRA_CONTACT_POINTS=kong-database” -e “KONG_PROXY_ACCESS_LOG=/dev/stdout” -e “KONG_ADMIN_ACCESS_LOG=/dev/stdout” -e “KONG_PROXY_ERROR_LOG=/dev/stderr” -e “KONG_ADMIN_ERROR_LOG=/dev/stderr” -e “KONG_ADMIN_LISTEN=0.0.0.0:8001, 0.0.0.0:8444 ssl” -p 8000:8000 -p 8443:8443 -p 8001:8001 -p 8444:8444 kong:2.4

4.4. 初始化 konga 数据库 (手动复制konga数据库)

docker run --rm pantsel/konga -c prepare -a postgres -u postgresql://kong:kong123@172.1.0.108:5432/konga

4.5. 创建 konga 容器

docker run -d -p 1337:1337 -e “DB_ADAPTER=postgres” -e “DB_HOST=172.1.0.108” -e “DB_PORT=5432” -e “DB_USER=kong” -e “DB_PASSWORD=kong123” -e “DB_DATABASE=konga” -e “NODE_ENV=production” --name konga pantsel/konga

4.6. API网关控制台

http://127.0.0.1:1337/#!/login

4.7. 首次登录需要配置kong admin

5. kong的主要模块

5.1. Services

顾名思义，服务实体是您自己的每个上游服务的抽象。服务的示例包括数据转换微服务、计费 API 等。

5.2. Routes

Route 实体定义了匹配客户端请求的规则。每个 Route 都与一个 Service 相关联，而一个 Service 可能有多个与之相关联的 Route。每个与给定路由匹配的请求都将被代理到其关联的服务。

5.3. Consumers

Consumer 对象代表 API 的使用者或用户。您可以依赖 Kong 作为主数据存储，也可以将消费者列表与数据库映射，以保持 Kong 与现有主数据存储之间的一致性。

5.4. Plugins

插件实体表示将在 HTTP 请求/响应工作流期间执行的插件配置，它是您向在 Kong 后面运行的 API 添加功能的方式，例如身份验证或速率限制。

5.5. Upstreams

上游对象代表一个虚拟主机名，可用于通过多个服务（目标）对传入请求进行负载均衡。因此，例如，上游命名service.v1.xyz为 API 对象，该 API 对象使用upstream_url=https://service.v1.xyz/some/path. 对此 API 的请求将被代理到上游定义的目标。

5.6. Certificates

证书对象表示 SSL 证书的公共证书/私钥对。Kong 使用这些对象来处理加密请求的 SSL/TLS 终止。证书可选择与 SNI 对象相关联，以将证书/密钥对绑定到一个或多个主机名。

6. kong插件

6.1. Authentication

6.2. Security

6.3. Traffic Control

6.4. Serverless

6.5. Analytics & Monitoring

6.6. Transformations

6.7. Logging

6.8. Other

总结

当前我们项目中用到的Kong插件也不多，有Oauth2、Acl、Cors、Ip Restriction、Rate Limiting、Tcp Log、Grpc Gateway。

后面的会分别针对主要模块、部分插件的功能结合konga管理平台对Admin API进行说明，当前使用的版本是kong2.4 后面会升级到kong2.5进行演示， 应为kong 2.5 开放了对 kong.response.get_XXX()的访问权限，我们在Tcp-log需要使用PDK函数kong.*和ngx.*。