API 网关 kong 的 konga 配置使用
程序员文章站
2022-06-22 15:56:35
...
一、Kong 概述：
kong的管理配置，官方（https://docs.konghq.com/2.1.x/admin-api）都是通过Kong API 的方式设置，通过 konga 进行管理配置的资料比较稀少且零散，为此根据本人实际的使用经验，归纳总结分享，希望对大家有所帮助！！
默认开放的端口：8000、8001、8443、8444
接受客户端流量的端口：
8000，监听来自客户端的HTTP请求，转发到你的upstream服务上。
8443，监听来自客户端的HTTPS请求，功能跟8000一样。可以通过配置文件禁止。
Admin API 端口：
8001，Kong的HTTP监听的API管理接口。
8444，Kong的HTTPS监听的API管理接口。
port：8000 客户端调用api端口，网关对外开放端口。例如：新建一个api，访问path= /test，则访问http://10.110.2.3:8000/test
port：8001 kong admin api管理端口，可以通过该端口对api、consumer、plugin进行管理，例如：查看名字叫test这个api配置信息，访 http://10.110.2.3:8001/apis/test，查看所有api信息，访问 http://10.110.2.3:8001/apis
概念术语：
Upstream：是对上游服务器的抽象，托管后端服务器，设置负载均衡策略。
Target：代表了一个物理服务，是最终处理请求的Backend服务（IP：PORT）。
Services：是抽象层面的服务，他可以直接映射到一个物理服务（host指向ip+port）；也可以指向一个Upstream来做到负载均衡，是多个Upstream的集合，是Route的转发目标，维护route与upstream之间的映射关系。
Route：是路由的抽象，路由是Kong的入口(client请求入口)，路由实体定义规则以匹配客户端的请求。每个Route与一个Service相关联，他负责将实际的request映射到service，设置请求的转发规则，按照Hosts和Paths，将请求转发给Service，Kubernetes的Ingress中每个path对应一个Route。
Route 路由：
对请求进行路由功能。可以有多个，每个route中包含了serviceid。
路由用来匹配客户端请求的规则，每一个路由都要与一个服务相关联，当一个请求到达Kong的时候，会先给路由匹配，如果匹配成功，那么会将请求转发给服务，服务再去后端请求数据。所以路由是Kong的入口。
Consumer：是API的用户，里面记录用户的一些信息。
Plugin：是插件，plugin可以是全局的，绑定到Service，绑定到Router，绑定到Consumer。
Certificate：是https证书。
Sni：是域名与Certificate的绑定，指定了一个域名对应的https证书。
服务(Service)的主要属性是它的URL，其可以被设置为单个串或通过指定其protocol，host，port和path。
服务(Service)与路由(Route)相关联（服务可以有许多与之关联的路由）。路由是Kong的入口点，并定义匹配客户端请求的规则。一旦匹配路由，Kong就会将请求代理到其关联的服务。
一个服务(Service)可能有多个与之关联的路由(Route)。与给定路由匹配的每个请求都将代理到其关联的Service上。路由可以配置的字段有：
hosts
paths
methods
Service 和 Route 的组合（以及它们之间的关注点分离）提供了一种强大的路由机制，通过它可以在Kong中定义细粒度的入口点，从而使基础架构路由到不同上游服务。
对应关系：
Upstream ：Target -> 1:n
Service ：Upstream -> 1:1 or 1:0 (Service 可以直接指向具体的Target，相当于不做负载均衡)
Service : Route -> 1:n
注意：Client 请求的流量通过 Route 指向与之相关的 Service，如果配置插件的话就会作用插件，Service 接到流量后给相应的 Upstream 的 Target 服务上面。
流程原理：
client ----> route ----> service ------> upstream -----> target1，target2,.....
所以，Route(路由)是Kong的入口
二、Kong 配置：
Nginx配置文件：
upstream helloupstream{
server 192.101.11.162:30080 weight 100;
server 192.101.11.163:30080 weight 100;
server 192.101.11.164:30080 weight 100;
}
server{
listen 80;
server_name 192.101.11.152;
max_client_body 128M; ## 限制请求报文大小128M，对应kong的 Request Size Limiting插件
location /hi{
proxy_pass http://helloupstream/hello
}
allow 192.168.0.0/16; ## IP 白名单，对应kong的 Ip Restriction 插件
deny 10.0.0.0/16; ## IP 黑名单，对应kong的 Ip Restriction 插件
}
Kong 对应定义：
Upstream 定义 ngnix 中的 upstream helloupstream
Target 定义 niginx 中upstream 的 server对应
server 192.101.11.162:30080 weight 100;
server 192.101.11.163:30080 weight 100;
server 192.101.11.164:30080 weight 100;
Service 定义 nginx 中server 的 proxy_pass对应 http://helloupstream
Route 定义 ngnix中server中的listen 80; server_name 192.101.11.152; location /hi
通过Kong API配置：
1）配置Upstream
# curl -i -X POST http://<ip>:8001/upstreams -d "name=helloupstream"
2) 配置Target
# curl -i -X POST http://<ip>:8001/upstreams/helloupstream/targets -d "target=192.101.11.162:30080" -d "weight=100"
# curl -i -X POST http://<ip>:8001/upstreams/helloupstream/targets -d "target=192.101.11.163:30080" -d "weight=100"
# curl -i -X POST http://<ip>:8001/upstreams/helloupstream/targets -d "target=192.101.11.164:30080" -d "weight=100"
一个Upstream可以包含多个Target，负载均衡的过程，就是为当前的请求选择一个Target的过程。
Target是IP或者host加端口，是提供服务的最小单位，每个target可以设置不同的权重。
Upstream是对多个target封装，多个target封装成一个虚拟的host，这个虚拟的host就是upstream的name，被用在Service的host中。
每个upstream中有一个预先设置好的slot数量，upstream中的多个target按照各自的权重分到slot中的一块，slot需要是预计的target数量的100倍。
变更target的开销很小，upstream变更的开销比较大，因为涉及到slot的重新分配。
Target的权重设置为0，target将不被选用。
负载均衡算法默认是带有权重的轮询（weighted-round-robin ）
3) 配置Service
# curl -i -X POST http://<ip>:8001/services -d "name=hello-service" -d "protocol=http" -d "host=helloupstream" -d "port=80" -d "path=/hello"
Service 服务：如果不需要负载均衡可以直接指定路径和url即可。可以不是Upstream的名字。
下三个参数设置太短容易超时，出现请求失败的可能
“connect_timeout”: 60000, 与上游连接的超时时间，单位毫秒
“write_timeout”: 60000, 向上游发送请求两次连续写操作的超时时间 ，单位毫秒
“read_timeout”: 60000, 用于向上游服务器发送请求的两次连续读取操作之间的超时 ，单位毫秒
4）配置Route
# curl -i -X POST http://<ip>:8001/routes -d "name=hello-route" -d "host=/<ip>" -d "path=/hi" -d "protocol=http" -d "service.id=50fdaec9-bfb0-42ce-8e8b-40d3a65f2270"
注意：<ip> 替换为 Kong 服务器地址 192.101.11.152
注意：methods，hosts，paths这三个参数必须要指定一个，否则无法创建路由。
Route中的匹配条件有host、path、method三个，条件越多的Route的优先级越高。
三、upstream健康检查：
upstream是指位于Kong网关之后的上游API/service，即客户端请求被Kong网关转发到的目标地址。在Kong网关中，upstream表示虚拟主机名，可用于：
健康检查
熔断
负载均衡。
在实际生产环境中，upstream可以指向部署在不同ip和端口的服务（target）。
健康检查方式：
健康检查的目的是动态地将target标记为健康或不健康的状态。每个Kong服务节点分别确定target的运行状况，而不会在集群范围内同步target的健康信息。因为其中的一个Kong服务节点可能成功连接到target，而另一个Kong节点则无法连接到target，第一个Kong服务节点将target标记为健康，第二个Kong节点将target标记为不健康，并将流量路由到其它target。
Kong支持两种健康检查，可以单独使用或结合使用：
主动检查（active checks）：定期请求目标中特定的HTTP或HTTPS的endpoint，根据其响应确定目标的运行状况；
被动检查（passive checks）：也被称为断路器，该模式下Kong通过分析代理的实时流量，根据其响应的状态确定目标的运行状况。
判定target是否健康
两种检查方式都会产生用于判断target是否健康的数据，一次客户端调用可能会产生TCP错误、超时或产生特定的HTTP状态码，根据这些信息，健康检查程序会更新其内部的相关计数器：
如果target返回的状态码为“健康”状态，将增加target的“成功”计数器，并清除所有其他计数器;
如果Kong和target连接失败，将增加target的“TCP失败”计数器，并清除“成功”计数器;
如果Kong获取target的响应超时，将增加目标的“超时”计数器，并清除“成功”计数器;
如果target返回“不健康”的状态码，将增加目标的“HTTP失败”的计数器，并清除“成功”计数器。
如果“TCP失败”、“HTTP失败”或“超时”计数器中的任意一个达到配置的阈值，target将被标记为不健康状态。
如果“成功”计数器达到配置的阈值，则target将被标记为正常。
配置HTTP状态代码为“健康”或“不健康”，以及这些计数器中每个计数器的各自阈值都可在upstream上进行配置。
如果upstream整体处于“不健康”状态（可用容量百分比小于配置的阈值），则Kong对客户端返回503 Service Unavailable。
注意：
健康检查仅对活动的target进行操作，而不会在Kong数据库中修改target的活动状态；
不健康的target不会从loadbalancer中删除，因此在使用散列算法时不会对负载均衡器的布局产生任何影响(不健康的target将被跳过)。
DNS警告和负载均衡警告也适用于健康检查。如果target使用是hostname，应该确保DNS服务器总是返回hostname的完整IP地址集，并且不限制响应，否则，可能会导致不执行运行状况检查。(没搞明白什么意思)
判定Upstreams是否健康
除了针对单个target的健康检查之外，upstream也具有运行健康概念。 upstream的运行状况取决于其target的状态。
upstream通过healthchecks.threshold属性来进行健康状态的配置，即upstream最小可用target的“权重”（容量）百分比，健康target/总target数。
例如：
upstream配置了healthchecks.threshold属性为55
有5个target，每个target的权重= 100，因此ring-balancer的总权重为500。
当故障发生，第一个target被标记为“不健康”状态。 此时在ring-balancer中，有20％的target不健康，该值高于55的阈值，因此其余target将继续提供服务。
若有三个target都为“不健康”的状态，则只有40%的可用target，低于55%的阈值，upstream的状态为“不健康”。
upstream一旦进入“不健康”状态，Kong将不再转发请求，直接向客户端返回错误，使服务有时间可以从级联故障中恢复。
一旦target恢复“健康”状态，且target可用容量超过阈值，环形负载均衡器的健康状态也会自动被更新。
主动健康检查会主动探测target的健康状态。 在upstream中启用主动健康检查后，Kong会定期向上游的每个target配置的路径发出HTTP或HTTPS请求。 这样，Kong可以根据探测结果自动启用和禁用负载均衡中的target。
四、Kong网关插件
Kong 网关是基于 OpenResty 应用服务器，OpenResty 是一个基于 Nginx 与 Lua 的高性能 Web 平台，其内部集成了大量精良的 Lua 库、第三方模块以及大多数的依赖项。用于方便地搭建能够处理超高并发、扩展性极高的动态 Web 应用、Web 服务和动态网关。而 Kong 核心基于 OpenResty 构建，并且拥有强大的插件扩展功能。
在 Http 请求到达 Kong 网关后，转发给后端应用之前，可以通过网关的各种插件对请求进行流量控制，安全，日志等各方面的处理能力。
目前，Kong 开源版本一共开放 25 个插件，主要分为五大类，Authentication认证，Security安全，Traffic Control流量控制，Analytics & Monitoring分析&监控，Logging日志，其他还有请求报文处理类。插件类似 AOP 开发中的横切功能，可以灵活的配置进行拦截控制。
下面选择一些关键性的插件进行简单的说明。
黑白名单控制能力（ip-restriction）
Kong 提供的 IP 黑白名单控制能力还算相当强，从配置项里面可以看到主要可以针对两个维度进行配置，是针对所有的 API 接口还是针对特定的 API 接口，一个是针对所有的消费方还是特定的某个消费方。对于 IP 配置可以是一个区段，也可以是特定的 IP 地址。但是黑白名单不能同时配置，其次当前没有一个功能是针对某一个系统提供的所有服务都启用黑名单或白名单功能。
日志记录能力（syslog、file-log、http-log）
这里主要日志的插件比较多，一个是 sysLog 在配置后可以直接将 Kong 产生的日志写入到应用服务器的系统日志文件中。如果配置了 file-log 则是单独写入到你指定的 file 文件中。对于 http-log 则是对于 http 服务请求，可以详细的记录请求的输入和输出报文信息，但是具体是记录到哪里，需要通过 config.http_endpoint 配置。具体关键的配置参数信息如下：
consumer_id: 可选参数，消费者 id(启用了消费者认证可以使用，根据 id 识别发出请求的消费者)
config.http_endpoint: 日志接收服务器(包括使用的协议，http or https)
config.method: 可选参数，默认POST，访问日志服务器的请求方式(可选值:PUT，PATCH，POST);
config.timeout: 可选参数，默认10000毫秒，请求超时时间
config.keepalive: 可选参数，默认60000毫秒，连接在关闭之前可存活时间
熔断插件（request-termination）
该插件用来定义指定请求或服务不进行上层服务，而直接返回指定的内容。用来为指定的请求或指定的服务进行熔断。注意 Kong 的熔断插件感觉是临时对服务的禁用，而不是说当达到某一种监控阈值的时候自动触发熔断，或者相关内容还没有了解到。从官方文档的应用场景也可以看到这点。
Temporarily disable a Service (e.g. it is under maintenance).
Temporarily disable a Route (e.g. the rest of the Service is up and running, but a particular endpoint must be disabled).
Temporarily disable a Consumer (e.g. excessive consumption).
如果仅仅是这种方式的熔断话，实际上意义并不是很大。但是可用的地方就在于当某个业务系统进行发版部署的时候我们可以对该业务系统或该业务系统所提供的所有服务进行熔断。
限流插件（rate-limiting）
Kong 当前提供的限流相对来说还是比较弱，即主要是控制某一个 API 接口服务在单位时间内最多只能够调用多少次，如果超过这个次数那么网关就直接拒绝访问并返回错误提示信息。限流实际上一个是根据服务调用次数，一个是根据服务调用数据量，需要在这两个方面进行限流。而里面更加重要的反而是数据量的限流，因为大数据量报文往往更加容易造成内存溢出异常。
安全认证类插件
当前 Kong 网关提供 basic-auth，key-auth，oauth2，hmac-auth，jwt，ldap-auth六种认证插件。
Basic Auth 基本认证插件，即我们根据用户名和密码来生成一个 base64 编码，同时将该编码和目标服务绑定，这样在消费目标服务的时候就需要在报文头填写这个 Base64 编码信息。
Key Auth 认证插件则是利用提前预设好的关键字名称，如下面设置的 keynote = apices，然后为 consumer 设置一个 key-auth 密钥，假如 key-auth = test@keyauth。在请求 api 的时候，将 apikey=test@keyauth，作为一个参数附加到请求 url 后，或者放置到 headers 中。
Hmac Auth 插件是设置绑定的 service 和 routte，以启动 hmac 验证。然后在 Consumers 页面中 Hmac credentials of Consumer 设置中添加一个 username 和 secret。
请求报文容量限制（request-size-limiting）
该插件用于限制请求报文的数据量大小，可以限制单个服务，也可以限制所有的 API 接口服务。
支持Oauth2.0身份认证（oauth2）
Kong 网关支持 Oauth2.0身份认证，Oauth2.0 协议根据使用不同的适用场景，定义了用于四种授权模式：
Authorization code（授权码模式）：标准的 Server 授权模式，非常适合 Server 端的 Web 应用。一旦资源的拥有者授权访问他们的数据之后，他们将会被重定向到 Web 应用并在 URL 的查询参数中附带一个授权码（code）。在客户端里，该 code 用于请求访问令牌（access_token）。并且该令牌交换的过程是两个服务端之前完成的，防止其他人甚至是资源拥有者本人得到该令牌。另外，在该授权模式下可以通过 refresh_token 来刷新令牌以延长访问授权时间，也是最为复杂的一种方式。
Implicit Grant（隐式模式）：该模式是所有授权模式中最简单的一种，并为运行于浏览器中的脚本应用做了优化。当用户访问该应用时，服务端会立即生成一个新的访问令牌（access_token）并通过 URL 的 #hash 段传回客户端。这时，客户端就可以利用 JavaScript 等将其取出然后请求 API 接口。该模式不需要授权码（code），当然也不会提供 refresh token 以获得长期访问的入口。
Resource Owner Password Credentials（密码模式）：自己有一套用户体系，这种模式要求用户提供用户名和密码来交换访问令牌（access_token）。该模式仅用于非常值得信任的用户，例如 API 提供者本人所写的移动应用。虽然用户也要求提供密码，但并不需要存储在设备上。因为初始验证之后，只需将 OAuth 的令牌记录下来即可。如果用户希望取消授权，因为其真实密码并没有被记录，因此无需修改密码就可以立即取消授权。token 本身也只是得到有限的授权，因此相比最传统的 username/password 授权，该模式依然更为安全。
Client Credentials（客户端模式）：没有用户的概念，一种基于 APP 的密钥直接进行授权，因此 APP 的权限非常大。它适合像数据库或存储服务器这种对 API 的访问需求。
简单转换能力（request-transformer、response transformer）
Kong 网关提供对输入和输出报文简单转换的能力。从当前配置来看，主要是对消息报文提供了Add，Replace，Rename，Append 等各种简单操作能力。
Kong Plugin通过consumer_id、route_id、service_id限定插件的作用范围：
作用于所有的Service、Router、Consumer： 创建时不指定consumer_id、service_id、route_id
作用于所有的Service、Router和指定的Consumer： 创建时只指定consumer_id
作用于所有的Consumer和指定的Service： 创建时只指定service_id，有些插件还需要指定route_id
作用于所有的Consumer和指定的Router： 创建时只指定route_id，有些插件还需要指定service_id
作用于特定的Service、Router、Consumer： 创建时指定consumer_id、service_id、route_id
没有绑定任何service、route、consumer的插件，称为global插件
五、Konga 配置使用：
Konga配置使用为了更直观，需要增加好多截图，因此通过我的印象笔记分享给大家：
https://app.yinxiang.com/fx/88e144ad-7396-48e2-82a2-472c554679af
六、Kong API:
API请求类型：
获取使用GET
修改使用 PATCH
创建使用 POST方法.添加
删除使用 DELETE 方法
GET /routers/ #列出所有路由
GET /services/ #列出所有服务
GET /consumers/ #列出所有用户
GET /services/{service name or id}/routes #列出服务关联的路由
GET /plugins/ #列出所有的插件配置
GET /plugins/enabled #列出所有可以使用的插件
GET /plugins/schema/{plugin name} #获得插件的配置模版
GET /certificates/ #列出所有的证书
GET /snis/ #列出所有域名与证书的对应
GET /upstreams/ #列出所有的upstream
GET /upstreams/{name or id}/health/ #查看upstream的健康状态
GET /upstreams/{name or id}/targets/all #列出upstream中所有的target
一、节点信息
查看节点信息：
curl -s http://<ip>:8001 | python -m json.tool
查看节点状态：
curl -s http://<ip>:8001/status | python -m json.tool
二、upstream/target
新增upstream：
curl -i -X POST http://<ip>:8001/upstreams -d 'name=hello-upstream'
新增target：
curl -i -X POST http://<ip>:8001/upstreams/hello-upstream/targets -d 'target=192.101.11.162:30080'
删除upstream：
curl -i -X DELETE http://10.10.203.230:8001/upstreams/hello-upstream
删除target：
target没有更新，只有新增/删除，设置weight=0就是删除。
curl -i -X POST http://<ip>:8001/upstreams/hello-upstream/targets -d 'target=192.101.11.162:30080' -d 'weight=0'
三、服务
添加服务：
curl -i -X POST http://<ip>:8001/services -d "name=test.service" -d "url=http://192.101.11.162:30080/hello"
curl -s -X POST --url http://<ip>:8001/services/ -d 'name=hello.service' -d 'protocol=http' -d 'host=192.101.11.162' -d 'port=30080' -d 'path=/hello' | python -m json.tool
查询所有服务：
curl -i -X GET http://<ip>:8001/services
curl -s --url http://<ip>:8001/services/ | python -m json.tool
查询某个服务：
curl -i -X GET http://<ip>:8001/services/{服务名称或服务ID}
curl -s --url http://<ip>:8001/services/{服务名称或服务ID} | python -m json.tool
curl -i -X GET http://<ip>:8001/services/test.service //查询name=test.service的服务(service.id=50fdaec9-bfb0-42ce-8e8b-40d3a65f2270)
curl -s --url http://<ip>:8001/services/hello.service | python -m json.tool
查询某个路由下的服务
curl -i -X GET http://<ip>:8001/routes/{路由ID}/service
curl -s -X GET --url http://<ip>:8001/routes/{路由ID}/service | python -m json.tool
curl -i -X GET http://<ip>:8001/routes/90a66cdb-476e-400f-9851-cff1f04ada99/service //route.id=90a66cdb-476e-400f-9851-cff1f04ada99
curl -s -X GET --url http://<ip>:8001/routes/90a66cdb-476e-400f-9851-cff1f04ada99/service | python -m json.tool
更新服务
curl -i -X PUT http://<ip>:8001/services/{服务名称或服务ID} -d "name=test.service" -d "protocol=http" -d "host=192.101.11.153" -d "path=/api"
curl -s -X PUT --url http://<ip>:8001/services/{服务名称或服务ID} -d 'name=test.service' -d 'protocol=http' -d 'host=192.101.11.153' -d 'path=/api' | python -m json.tool
curl -i -X PUT http://<ip>:8001/services/test.service -d "name=test.service" -d "protocol=http" -d "host=192.101.11.153" -d "path=/api"
删除服务
curl -i -X DELETE http://<ip>:8001/services/{服务名称或服务ID}
curl -i -X DELETE --url http://<ip>:8001/services/{服务名称或服务ID}
curl -i -X DELETE http://<ip>:8001/services/test.service
四、路由
添加路由：
curl -i -X POST --url http://192.101.11.152:8001/routes/ -d 'protocols[]=http&protocols[]=https' -d 'paths[]=/test&paths[]=/test/' -d 'hosts[]=192.101.11.152' -d 'preserve_host=false' -d 'strip_path=true' -d 'service.id=50fdaec9-bfb0-42ce-8e8b-40d3a65f2270'
curl -s -X POST --url http://192.101.11.152:8001/routes/ -d 'protocols=http' -d 'methods=GET' -d 'paths=/test' -d 'service.id=50fdaec9-bfb0-42ce-8e8b-40d3a65f2270' | python -m json.tool
curl -i -X POST --url http://<ip>:8001/routes/ -d 'protocols=http' -d 'paths=/test' -d 'service.id=50fdaec9-bfb0-42ce-8e8b-40d3a65f2270'
重要变量说明：
【strip_path】
值：false,true 默认true
是否把匹配成功的paths删除后再转发后端服务器.
该指令相当于proxy_pass http://jintest-server/
“strip_path”: true, 当通过其中一个路径匹配路由时，从上游请求URL中除去匹配前缀。匹配到path时，是否删除匹配到的前缀。
【preserve_host】
值：false,true 默认false
转发后端是否带host参数，默认不带。
该指令相当于proxy_set_header Host $host;
“preserve_host”: false, Route将请求代理给Service时，默认将请求头中的host修改为Route中配置的host，如果不希望这样，可以设置preserve_host，使用原始请求头中的host。
匹配到hosts时，使用请求头部的值为域名向后端发起请求，请求的头部为"host",例如"host:api.abc.com"
访问接口：
curl -i -X GET http://<ip>:8000/test/
查询全部路由：
curl -i -X GET --url http://<ip>:8001/routes/
curl -s http://<ip>:8001/routes/ | python -m json.tool
查询某个路由：
curl -i -X GET --url http://<ip>:8001/routes/{路由ID}
curl -s http://<ip>:8001/routes/{路由ID} | python -m json.tool
curl -i -X GET --url http://<ip>:8001/routes/90a66cdb-476e-400f-9851-cff1f04ada99
curl -s http://<ip>:8001/routes/90a66cdb-476e-400f-9851-cff1f04ada99 | python -m json.tool
查询某服务下的路由：
curl -i -X GET --url http://<ip>:8001/services/{服务名称或服务ID}/routes
curl -s http://<ip>:8001/services/{服务名称或服务ID}/routes | python -m json.tool
curl -i -X GET --url http://<ip>:8001/services/test.service/routes
curl -s http://<ip>:8001/services/test.service/routes | python -m json.tool
查看和路由关联的服务:
curl -s http://<ip>:8001/routes/{路由ID}/service | python -m json.tool
curl -s http://<ip>:8001/routes/90a66cdb-476e-400f-9851-cff1f04ada99/service | python -m json.tool
更新路由（可以使用PATCH和PUT方法，PATCH可以修改已存在的路由，PUT如果路由不存在则新建一个）
curl -i -X PUT http://<ip>:8001/routes/{路由ID} -d 'protocols[]=http&protocols[]=https' -d 'paths=/test'
curl -s -X PUT --url http://<ip>:8001/routes/{路由ID} -d 'protocols=http' -d 'methods=GET' -d 'paths=/test' -d 'service.id=50fdaec9-bfb0-42ce-8e8b-40d3a65f2270' | python -m json.tool
curl -i -X PUT http://<ip>:8001/routes/90a66cdb-476e-400f-9851-cff1f04ada99 -d 'protocols[]=http&protocols[]=https' -d 'paths=/test' -d 'service.id=50fdaec9-bfb0-42ce-8e8b-40d3a65f2270'
curl -i -X PUT http://<ip>:8001/routes/90a66cdb-476e-400f-9851-cff1f04ada99 -d 'protocols=http' -d 'paths=/test' -d 'service.id=50fdaec9-bfb0-42ce-8e8b-40d3a65f2270'
删除路由
curl -i -X DELETE http://<ip>:8001/routes/{路由ID}
curl -i -X DELETE http://<ip>:8001/routes/90a66cdb-476e-400f-9851-cff1f04ada99
五、用户
添加用户:
curl -s -X POST --url http://<ip>:8001/consumers -d 'username=luoms' | python -m json.tool
查询所有用户；
curl -s http://<ip>:8001/consumers/luoms | python -m json.tool
查询某个用户；
curl -s http://<ip>:8001/consumers/luoms | python -m json.tool
更新用户：
curl -s -X PUT --url http://<ip>:8001/consumers/{id} -d "custom_id=luoms123" | python -m json.tool
curl -s -X PUT --url http://<ip>:8001/consumers/c7456aff-ab6a-4d34-8d2e-2b987c795260 -d "custom_id=luoms123" | python -m json.tool
删除用户:
curl -i -X DELETE --url http://<ip>:8001/consumers/{id}
curl -i -X DELETE --url http://<ip>:8001/consumers/c7456aff-ab6a-4d34-8d2e-2b987c795260
六、插件
添加插件：
curl -s -X POST --url http://<ip>:8001/plugins/ -d 'name=basic-auth' -d 'route_id=90a66cdb-476e-400f-9851-cff1f04ada99' | python -m json.tool
查询所有插件：
curl -s --url http://<ip>:8001/plugins/ | python -m json.tool
查询某个插件：
curl -s --url http://<ip>:8001/plugins/{id} | python -m json.tool
更新插件:
curl -s -X PUT --url http://<ip>:8001/plugins/900aeaa3-0a47-49a1-9fea-649e6c90ab7f -d "service_id=da4dce88-4df3-4723-b544-b11b27184e97" | python -m json.tool
删除插件:
curl -s -X DELETE --url http://<ip>:8001/plugins/900aeaa3-0a47-49a1-9fea-649e6c90ab7f | python -m json.tool
查询已启用的插件:
curl -s -X GET --url http://<ip>:8001/plugins/enabled | python -m json.tool
检索插件架构:
curl -s -X GET --url http://<ip>:8001/plugins/schema/basic-auth | python -m json.tool
注意：<ip> 替换为 Kong 服务器地址 192.101.11.152
七、网关分类：
对于具体的后端业务应用或者是服务和业务有一定关联性的策略网关就是——业务网关。 业务网关针对具体的业务需要提供特定的流控策略、缓存策略、鉴权认证策略等等。
与业务网关相反，定义全局性的、跟具体的后端业务应用和服务完全无关的策略网关就是——流量网关。流量网关通常只专注于全局的Api管理策略，比如全局流量监控、日志记录、全局限流、黑白名单控制、接入请求到业务系统的负载均衡等，有点类似防火墙。Kong 就是典型的流量网关。
业务网关一般部署在流量网关之后、业务系统之前，比流量网关更靠近业务系统。
kong的管理配置，官方（https://docs.konghq.com/2.1.x/admin-api）都是通过Kong API 的方式设置，通过 konga 进行管理配置的资料比较稀少且零散，为此根据本人实际的使用经验，归纳总结分享，希望对大家有所帮助！！
默认开放的端口：8000、8001、8443、8444
接受客户端流量的端口：
8000，监听来自客户端的HTTP请求，转发到你的upstream服务上。
8443，监听来自客户端的HTTPS请求，功能跟8000一样。可以通过配置文件禁止。
Admin API 端口：
8001，Kong的HTTP监听的API管理接口。
8444，Kong的HTTPS监听的API管理接口。
port：8000 客户端调用api端口，网关对外开放端口。例如：新建一个api，访问path= /test，则访问http://10.110.2.3:8000/test
port：8001 kong admin api管理端口，可以通过该端口对api、consumer、plugin进行管理，例如：查看名字叫test这个api配置信息，访 http://10.110.2.3:8001/apis/test，查看所有api信息，访问 http://10.110.2.3:8001/apis
概念术语：
Upstream：是对上游服务器的抽象，托管后端服务器，设置负载均衡策略。
Target：代表了一个物理服务，是最终处理请求的Backend服务（IP：PORT）。
Services：是抽象层面的服务，他可以直接映射到一个物理服务（host指向ip+port）；也可以指向一个Upstream来做到负载均衡，是多个Upstream的集合，是Route的转发目标，维护route与upstream之间的映射关系。
Route：是路由的抽象，路由是Kong的入口(client请求入口)，路由实体定义规则以匹配客户端的请求。每个Route与一个Service相关联，他负责将实际的request映射到service，设置请求的转发规则，按照Hosts和Paths，将请求转发给Service，Kubernetes的Ingress中每个path对应一个Route。
Route 路由：
对请求进行路由功能。可以有多个，每个route中包含了serviceid。
路由用来匹配客户端请求的规则，每一个路由都要与一个服务相关联，当一个请求到达Kong的时候，会先给路由匹配，如果匹配成功，那么会将请求转发给服务，服务再去后端请求数据。所以路由是Kong的入口。
Consumer：是API的用户，里面记录用户的一些信息。
Plugin：是插件，plugin可以是全局的，绑定到Service，绑定到Router，绑定到Consumer。
Certificate：是https证书。
Sni：是域名与Certificate的绑定，指定了一个域名对应的https证书。
服务(Service)的主要属性是它的URL，其可以被设置为单个串或通过指定其protocol，host，port和path。
服务(Service)与路由(Route)相关联（服务可以有许多与之关联的路由）。路由是Kong的入口点，并定义匹配客户端请求的规则。一旦匹配路由，Kong就会将请求代理到其关联的服务。
一个服务(Service)可能有多个与之关联的路由(Route)。与给定路由匹配的每个请求都将代理到其关联的Service上。路由可以配置的字段有：
hosts
paths
methods
Service 和 Route 的组合（以及它们之间的关注点分离）提供了一种强大的路由机制，通过它可以在Kong中定义细粒度的入口点，从而使基础架构路由到不同上游服务。
对应关系：
Upstream ：Target -> 1:n
Service ：Upstream -> 1:1 or 1:0 (Service 可以直接指向具体的Target，相当于不做负载均衡)
Service : Route -> 1:n
注意：Client 请求的流量通过 Route 指向与之相关的 Service，如果配置插件的话就会作用插件，Service 接到流量后给相应的 Upstream 的 Target 服务上面。
流程原理：
client ----> route ----> service ------> upstream -----> target1，target2,.....
所以，Route(路由)是Kong的入口
二、Kong 配置：
Nginx配置文件：
upstream helloupstream{
server 192.101.11.162:30080 weight 100;
server 192.101.11.163:30080 weight 100;
server 192.101.11.164:30080 weight 100;
}
server{
listen 80;
server_name 192.101.11.152;
max_client_body 128M; ## 限制请求报文大小128M，对应kong的 Request Size Limiting插件
location /hi{
proxy_pass http://helloupstream/hello
}
allow 192.168.0.0/16; ## IP 白名单，对应kong的 Ip Restriction 插件
deny 10.0.0.0/16; ## IP 黑名单，对应kong的 Ip Restriction 插件
}
Kong 对应定义：
Upstream 定义 ngnix 中的 upstream helloupstream
Target 定义 niginx 中upstream 的 server对应
server 192.101.11.162:30080 weight 100;
server 192.101.11.163:30080 weight 100;
server 192.101.11.164:30080 weight 100;
Service 定义 nginx 中server 的 proxy_pass对应 http://helloupstream
Route 定义 ngnix中server中的listen 80; server_name 192.101.11.152; location /hi
通过Kong API配置：
1）配置Upstream
# curl -i -X POST http://<ip>:8001/upstreams -d "name=helloupstream"
2) 配置Target
# curl -i -X POST http://<ip>:8001/upstreams/helloupstream/targets -d "target=192.101.11.162:30080" -d "weight=100"
# curl -i -X POST http://<ip>:8001/upstreams/helloupstream/targets -d "target=192.101.11.163:30080" -d "weight=100"
# curl -i -X POST http://<ip>:8001/upstreams/helloupstream/targets -d "target=192.101.11.164:30080" -d "weight=100"
一个Upstream可以包含多个Target，负载均衡的过程，就是为当前的请求选择一个Target的过程。
Target是IP或者host加端口，是提供服务的最小单位，每个target可以设置不同的权重。
Upstream是对多个target封装，多个target封装成一个虚拟的host，这个虚拟的host就是upstream的name，被用在Service的host中。
每个upstream中有一个预先设置好的slot数量，upstream中的多个target按照各自的权重分到slot中的一块，slot需要是预计的target数量的100倍。
变更target的开销很小，upstream变更的开销比较大，因为涉及到slot的重新分配。
Target的权重设置为0，target将不被选用。
负载均衡算法默认是带有权重的轮询（weighted-round-robin ）
3) 配置Service
# curl -i -X POST http://<ip>:8001/services -d "name=hello-service" -d "protocol=http" -d "host=helloupstream" -d "port=80" -d "path=/hello"
Service 服务：如果不需要负载均衡可以直接指定路径和url即可。可以不是Upstream的名字。
下三个参数设置太短容易超时，出现请求失败的可能
“connect_timeout”: 60000, 与上游连接的超时时间，单位毫秒
“write_timeout”: 60000, 向上游发送请求两次连续写操作的超时时间 ，单位毫秒
“read_timeout”: 60000, 用于向上游服务器发送请求的两次连续读取操作之间的超时 ，单位毫秒
4）配置Route
# curl -i -X POST http://<ip>:8001/routes -d "name=hello-route" -d "host=/<ip>" -d "path=/hi" -d "protocol=http" -d "service.id=50fdaec9-bfb0-42ce-8e8b-40d3a65f2270"
注意：<ip> 替换为 Kong 服务器地址 192.101.11.152
注意：methods，hosts，paths这三个参数必须要指定一个，否则无法创建路由。
Route中的匹配条件有host、path、method三个，条件越多的Route的优先级越高。
三、upstream健康检查：
upstream是指位于Kong网关之后的上游API/service，即客户端请求被Kong网关转发到的目标地址。在Kong网关中，upstream表示虚拟主机名，可用于：
健康检查
熔断
负载均衡。
在实际生产环境中，upstream可以指向部署在不同ip和端口的服务（target）。
健康检查方式：
健康检查的目的是动态地将target标记为健康或不健康的状态。每个Kong服务节点分别确定target的运行状况，而不会在集群范围内同步target的健康信息。因为其中的一个Kong服务节点可能成功连接到target，而另一个Kong节点则无法连接到target，第一个Kong服务节点将target标记为健康，第二个Kong节点将target标记为不健康，并将流量路由到其它target。
Kong支持两种健康检查，可以单独使用或结合使用：
主动检查（active checks）：定期请求目标中特定的HTTP或HTTPS的endpoint，根据其响应确定目标的运行状况；
被动检查（passive checks）：也被称为断路器，该模式下Kong通过分析代理的实时流量，根据其响应的状态确定目标的运行状况。
判定target是否健康
两种检查方式都会产生用于判断target是否健康的数据，一次客户端调用可能会产生TCP错误、超时或产生特定的HTTP状态码，根据这些信息，健康检查程序会更新其内部的相关计数器：
如果target返回的状态码为“健康”状态，将增加target的“成功”计数器，并清除所有其他计数器;
如果Kong和target连接失败，将增加target的“TCP失败”计数器，并清除“成功”计数器;
如果Kong获取target的响应超时，将增加目标的“超时”计数器，并清除“成功”计数器;
如果target返回“不健康”的状态码，将增加目标的“HTTP失败”的计数器，并清除“成功”计数器。
如果“TCP失败”、“HTTP失败”或“超时”计数器中的任意一个达到配置的阈值，target将被标记为不健康状态。
如果“成功”计数器达到配置的阈值，则target将被标记为正常。
配置HTTP状态代码为“健康”或“不健康”，以及这些计数器中每个计数器的各自阈值都可在upstream上进行配置。
如果upstream整体处于“不健康”状态（可用容量百分比小于配置的阈值），则Kong对客户端返回503 Service Unavailable。
注意：
健康检查仅对活动的target进行操作，而不会在Kong数据库中修改target的活动状态；
不健康的target不会从loadbalancer中删除，因此在使用散列算法时不会对负载均衡器的布局产生任何影响(不健康的target将被跳过)。
DNS警告和负载均衡警告也适用于健康检查。如果target使用是hostname，应该确保DNS服务器总是返回hostname的完整IP地址集，并且不限制响应，否则，可能会导致不执行运行状况检查。(没搞明白什么意思)
判定Upstreams是否健康
除了针对单个target的健康检查之外，upstream也具有运行健康概念。 upstream的运行状况取决于其target的状态。
upstream通过healthchecks.threshold属性来进行健康状态的配置，即upstream最小可用target的“权重”（容量）百分比，健康target/总target数。
例如：
upstream配置了healthchecks.threshold属性为55
有5个target，每个target的权重= 100，因此ring-balancer的总权重为500。
当故障发生，第一个target被标记为“不健康”状态。 此时在ring-balancer中，有20％的target不健康，该值高于55的阈值，因此其余target将继续提供服务。
若有三个target都为“不健康”的状态，则只有40%的可用target，低于55%的阈值，upstream的状态为“不健康”。
upstream一旦进入“不健康”状态，Kong将不再转发请求，直接向客户端返回错误，使服务有时间可以从级联故障中恢复。
一旦target恢复“健康”状态，且target可用容量超过阈值，环形负载均衡器的健康状态也会自动被更新。
主动健康检查会主动探测target的健康状态。 在upstream中启用主动健康检查后，Kong会定期向上游的每个target配置的路径发出HTTP或HTTPS请求。 这样，Kong可以根据探测结果自动启用和禁用负载均衡中的target。
四、Kong网关插件
Kong 网关是基于 OpenResty 应用服务器，OpenResty 是一个基于 Nginx 与 Lua 的高性能 Web 平台，其内部集成了大量精良的 Lua 库、第三方模块以及大多数的依赖项。用于方便地搭建能够处理超高并发、扩展性极高的动态 Web 应用、Web 服务和动态网关。而 Kong 核心基于 OpenResty 构建，并且拥有强大的插件扩展功能。
在 Http 请求到达 Kong 网关后，转发给后端应用之前，可以通过网关的各种插件对请求进行流量控制，安全，日志等各方面的处理能力。
目前，Kong 开源版本一共开放 25 个插件，主要分为五大类，Authentication认证，Security安全，Traffic Control流量控制，Analytics & Monitoring分析&监控，Logging日志，其他还有请求报文处理类。插件类似 AOP 开发中的横切功能，可以灵活的配置进行拦截控制。
下面选择一些关键性的插件进行简单的说明。
黑白名单控制能力（ip-restriction）
Kong 提供的 IP 黑白名单控制能力还算相当强，从配置项里面可以看到主要可以针对两个维度进行配置，是针对所有的 API 接口还是针对特定的 API 接口，一个是针对所有的消费方还是特定的某个消费方。对于 IP 配置可以是一个区段，也可以是特定的 IP 地址。但是黑白名单不能同时配置，其次当前没有一个功能是针对某一个系统提供的所有服务都启用黑名单或白名单功能。
日志记录能力（syslog、file-log、http-log）
这里主要日志的插件比较多，一个是 sysLog 在配置后可以直接将 Kong 产生的日志写入到应用服务器的系统日志文件中。如果配置了 file-log 则是单独写入到你指定的 file 文件中。对于 http-log 则是对于 http 服务请求，可以详细的记录请求的输入和输出报文信息，但是具体是记录到哪里，需要通过 config.http_endpoint 配置。具体关键的配置参数信息如下：
consumer_id: 可选参数，消费者 id(启用了消费者认证可以使用，根据 id 识别发出请求的消费者)
config.http_endpoint: 日志接收服务器(包括使用的协议，http or https)
config.method: 可选参数，默认POST，访问日志服务器的请求方式(可选值:PUT，PATCH，POST);
config.timeout: 可选参数，默认10000毫秒，请求超时时间
config.keepalive: 可选参数，默认60000毫秒，连接在关闭之前可存活时间
熔断插件（request-termination）
该插件用来定义指定请求或服务不进行上层服务，而直接返回指定的内容。用来为指定的请求或指定的服务进行熔断。注意 Kong 的熔断插件感觉是临时对服务的禁用，而不是说当达到某一种监控阈值的时候自动触发熔断，或者相关内容还没有了解到。从官方文档的应用场景也可以看到这点。
Temporarily disable a Service (e.g. it is under maintenance).
Temporarily disable a Route (e.g. the rest of the Service is up and running, but a particular endpoint must be disabled).
Temporarily disable a Consumer (e.g. excessive consumption).
如果仅仅是这种方式的熔断话，实际上意义并不是很大。但是可用的地方就在于当某个业务系统进行发版部署的时候我们可以对该业务系统或该业务系统所提供的所有服务进行熔断。
限流插件（rate-limiting）
Kong 当前提供的限流相对来说还是比较弱，即主要是控制某一个 API 接口服务在单位时间内最多只能够调用多少次，如果超过这个次数那么网关就直接拒绝访问并返回错误提示信息。限流实际上一个是根据服务调用次数，一个是根据服务调用数据量，需要在这两个方面进行限流。而里面更加重要的反而是数据量的限流，因为大数据量报文往往更加容易造成内存溢出异常。
安全认证类插件
当前 Kong 网关提供 basic-auth，key-auth，oauth2，hmac-auth，jwt，ldap-auth六种认证插件。
Basic Auth 基本认证插件，即我们根据用户名和密码来生成一个 base64 编码，同时将该编码和目标服务绑定，这样在消费目标服务的时候就需要在报文头填写这个 Base64 编码信息。
Key Auth 认证插件则是利用提前预设好的关键字名称，如下面设置的 keynote = apices，然后为 consumer 设置一个 key-auth 密钥，假如 key-auth = test@keyauth。在请求 api 的时候，将 apikey=test@keyauth，作为一个参数附加到请求 url 后，或者放置到 headers 中。
Hmac Auth 插件是设置绑定的 service 和 routte，以启动 hmac 验证。然后在 Consumers 页面中 Hmac credentials of Consumer 设置中添加一个 username 和 secret。
请求报文容量限制（request-size-limiting）
该插件用于限制请求报文的数据量大小，可以限制单个服务，也可以限制所有的 API 接口服务。
支持Oauth2.0身份认证（oauth2）
Kong 网关支持 Oauth2.0身份认证，Oauth2.0 协议根据使用不同的适用场景，定义了用于四种授权模式：
Authorization code（授权码模式）：标准的 Server 授权模式，非常适合 Server 端的 Web 应用。一旦资源的拥有者授权访问他们的数据之后，他们将会被重定向到 Web 应用并在 URL 的查询参数中附带一个授权码（code）。在客户端里，该 code 用于请求访问令牌（access_token）。并且该令牌交换的过程是两个服务端之前完成的，防止其他人甚至是资源拥有者本人得到该令牌。另外，在该授权模式下可以通过 refresh_token 来刷新令牌以延长访问授权时间，也是最为复杂的一种方式。
Implicit Grant（隐式模式）：该模式是所有授权模式中最简单的一种，并为运行于浏览器中的脚本应用做了优化。当用户访问该应用时，服务端会立即生成一个新的访问令牌（access_token）并通过 URL 的 #hash 段传回客户端。这时，客户端就可以利用 JavaScript 等将其取出然后请求 API 接口。该模式不需要授权码（code），当然也不会提供 refresh token 以获得长期访问的入口。
Resource Owner Password Credentials（密码模式）：自己有一套用户体系，这种模式要求用户提供用户名和密码来交换访问令牌（access_token）。该模式仅用于非常值得信任的用户，例如 API 提供者本人所写的移动应用。虽然用户也要求提供密码，但并不需要存储在设备上。因为初始验证之后，只需将 OAuth 的令牌记录下来即可。如果用户希望取消授权，因为其真实密码并没有被记录，因此无需修改密码就可以立即取消授权。token 本身也只是得到有限的授权，因此相比最传统的 username/password 授权，该模式依然更为安全。
Client Credentials（客户端模式）：没有用户的概念，一种基于 APP 的密钥直接进行授权，因此 APP 的权限非常大。它适合像数据库或存储服务器这种对 API 的访问需求。
简单转换能力（request-transformer、response transformer）
Kong 网关提供对输入和输出报文简单转换的能力。从当前配置来看，主要是对消息报文提供了Add，Replace，Rename，Append 等各种简单操作能力。
Kong Plugin通过consumer_id、route_id、service_id限定插件的作用范围：
作用于所有的Service、Router、Consumer： 创建时不指定consumer_id、service_id、route_id
作用于所有的Service、Router和指定的Consumer： 创建时只指定consumer_id
作用于所有的Consumer和指定的Service： 创建时只指定service_id，有些插件还需要指定route_id
作用于所有的Consumer和指定的Router： 创建时只指定route_id，有些插件还需要指定service_id
作用于特定的Service、Router、Consumer： 创建时指定consumer_id、service_id、route_id
没有绑定任何service、route、consumer的插件，称为global插件
五、Konga 配置使用：
Konga配置使用为了更直观，需要增加好多截图，因此通过我的印象笔记分享给大家：
https://app.yinxiang.com/fx/88e144ad-7396-48e2-82a2-472c554679af
六、Kong API:
API请求类型：
获取使用GET
修改使用 PATCH
创建使用 POST方法.添加
删除使用 DELETE 方法
GET /routers/ #列出所有路由
GET /services/ #列出所有服务
GET /consumers/ #列出所有用户
GET /services/{service name or id}/routes #列出服务关联的路由
GET /plugins/ #列出所有的插件配置
GET /plugins/enabled #列出所有可以使用的插件
GET /plugins/schema/{plugin name} #获得插件的配置模版
GET /certificates/ #列出所有的证书
GET /snis/ #列出所有域名与证书的对应
GET /upstreams/ #列出所有的upstream
GET /upstreams/{name or id}/health/ #查看upstream的健康状态
GET /upstreams/{name or id}/targets/all #列出upstream中所有的target
一、节点信息
查看节点信息：
curl -s http://<ip>:8001 | python -m json.tool
查看节点状态：
curl -s http://<ip>:8001/status | python -m json.tool
二、upstream/target
新增upstream：
curl -i -X POST http://<ip>:8001/upstreams -d 'name=hello-upstream'
新增target：
curl -i -X POST http://<ip>:8001/upstreams/hello-upstream/targets -d 'target=192.101.11.162:30080'
删除upstream：
curl -i -X DELETE http://10.10.203.230:8001/upstreams/hello-upstream
删除target：
target没有更新，只有新增/删除，设置weight=0就是删除。
curl -i -X POST http://<ip>:8001/upstreams/hello-upstream/targets -d 'target=192.101.11.162:30080' -d 'weight=0'
三、服务
添加服务：
curl -i -X POST http://<ip>:8001/services -d "name=test.service" -d "url=http://192.101.11.162:30080/hello"
curl -s -X POST --url http://<ip>:8001/services/ -d 'name=hello.service' -d 'protocol=http' -d 'host=192.101.11.162' -d 'port=30080' -d 'path=/hello' | python -m json.tool
查询所有服务：
curl -i -X GET http://<ip>:8001/services
curl -s --url http://<ip>:8001/services/ | python -m json.tool
查询某个服务：
curl -i -X GET http://<ip>:8001/services/{服务名称或服务ID}
curl -s --url http://<ip>:8001/services/{服务名称或服务ID} | python -m json.tool
curl -i -X GET http://<ip>:8001/services/test.service //查询name=test.service的服务(service.id=50fdaec9-bfb0-42ce-8e8b-40d3a65f2270)
curl -s --url http://<ip>:8001/services/hello.service | python -m json.tool
查询某个路由下的服务
curl -i -X GET http://<ip>:8001/routes/{路由ID}/service
curl -s -X GET --url http://<ip>:8001/routes/{路由ID}/service | python -m json.tool
curl -i -X GET http://<ip>:8001/routes/90a66cdb-476e-400f-9851-cff1f04ada99/service //route.id=90a66cdb-476e-400f-9851-cff1f04ada99
curl -s -X GET --url http://<ip>:8001/routes/90a66cdb-476e-400f-9851-cff1f04ada99/service | python -m json.tool
更新服务
curl -i -X PUT http://<ip>:8001/services/{服务名称或服务ID} -d "name=test.service" -d "protocol=http" -d "host=192.101.11.153" -d "path=/api"
curl -s -X PUT --url http://<ip>:8001/services/{服务名称或服务ID} -d 'name=test.service' -d 'protocol=http' -d 'host=192.101.11.153' -d 'path=/api' | python -m json.tool
curl -i -X PUT http://<ip>:8001/services/test.service -d "name=test.service" -d "protocol=http" -d "host=192.101.11.153" -d "path=/api"
删除服务
curl -i -X DELETE http://<ip>:8001/services/{服务名称或服务ID}
curl -i -X DELETE --url http://<ip>:8001/services/{服务名称或服务ID}
curl -i -X DELETE http://<ip>:8001/services/test.service
四、路由
添加路由：
curl -i -X POST --url http://192.101.11.152:8001/routes/ -d 'protocols[]=http&protocols[]=https' -d 'paths[]=/test&paths[]=/test/' -d 'hosts[]=192.101.11.152' -d 'preserve_host=false' -d 'strip_path=true' -d 'service.id=50fdaec9-bfb0-42ce-8e8b-40d3a65f2270'
curl -s -X POST --url http://192.101.11.152:8001/routes/ -d 'protocols=http' -d 'methods=GET' -d 'paths=/test' -d 'service.id=50fdaec9-bfb0-42ce-8e8b-40d3a65f2270' | python -m json.tool
curl -i -X POST --url http://<ip>:8001/routes/ -d 'protocols=http' -d 'paths=/test' -d 'service.id=50fdaec9-bfb0-42ce-8e8b-40d3a65f2270'
重要变量说明：
【strip_path】
值：false,true 默认true
是否把匹配成功的paths删除后再转发后端服务器.
该指令相当于proxy_pass http://jintest-server/
“strip_path”: true, 当通过其中一个路径匹配路由时，从上游请求URL中除去匹配前缀。匹配到path时，是否删除匹配到的前缀。
【preserve_host】
值：false,true 默认false
转发后端是否带host参数，默认不带。
该指令相当于proxy_set_header Host $host;
“preserve_host”: false, Route将请求代理给Service时，默认将请求头中的host修改为Route中配置的host，如果不希望这样，可以设置preserve_host，使用原始请求头中的host。
匹配到hosts时，使用请求头部的值为域名向后端发起请求，请求的头部为"host",例如"host:api.abc.com"
访问接口：
curl -i -X GET http://<ip>:8000/test/
查询全部路由：
curl -i -X GET --url http://<ip>:8001/routes/
curl -s http://<ip>:8001/routes/ | python -m json.tool
查询某个路由：
curl -i -X GET --url http://<ip>:8001/routes/{路由ID}
curl -s http://<ip>:8001/routes/{路由ID} | python -m json.tool
curl -i -X GET --url http://<ip>:8001/routes/90a66cdb-476e-400f-9851-cff1f04ada99
curl -s http://<ip>:8001/routes/90a66cdb-476e-400f-9851-cff1f04ada99 | python -m json.tool
查询某服务下的路由：
curl -i -X GET --url http://<ip>:8001/services/{服务名称或服务ID}/routes
curl -s http://<ip>:8001/services/{服务名称或服务ID}/routes | python -m json.tool
curl -i -X GET --url http://<ip>:8001/services/test.service/routes
curl -s http://<ip>:8001/services/test.service/routes | python -m json.tool
查看和路由关联的服务:
curl -s http://<ip>:8001/routes/{路由ID}/service | python -m json.tool
curl -s http://<ip>:8001/routes/90a66cdb-476e-400f-9851-cff1f04ada99/service | python -m json.tool
更新路由（可以使用PATCH和PUT方法，PATCH可以修改已存在的路由，PUT如果路由不存在则新建一个）
curl -i -X PUT http://<ip>:8001/routes/{路由ID} -d 'protocols[]=http&protocols[]=https' -d 'paths=/test'
curl -s -X PUT --url http://<ip>:8001/routes/{路由ID} -d 'protocols=http' -d 'methods=GET' -d 'paths=/test' -d 'service.id=50fdaec9-bfb0-42ce-8e8b-40d3a65f2270' | python -m json.tool
curl -i -X PUT http://<ip>:8001/routes/90a66cdb-476e-400f-9851-cff1f04ada99 -d 'protocols[]=http&protocols[]=https' -d 'paths=/test' -d 'service.id=50fdaec9-bfb0-42ce-8e8b-40d3a65f2270'
curl -i -X PUT http://<ip>:8001/routes/90a66cdb-476e-400f-9851-cff1f04ada99 -d 'protocols=http' -d 'paths=/test' -d 'service.id=50fdaec9-bfb0-42ce-8e8b-40d3a65f2270'
删除路由
curl -i -X DELETE http://<ip>:8001/routes/{路由ID}
curl -i -X DELETE http://<ip>:8001/routes/90a66cdb-476e-400f-9851-cff1f04ada99
五、用户
添加用户:
curl -s -X POST --url http://<ip>:8001/consumers -d 'username=luoms' | python -m json.tool
查询所有用户；
curl -s http://<ip>:8001/consumers/luoms | python -m json.tool
查询某个用户；
curl -s http://<ip>:8001/consumers/luoms | python -m json.tool
更新用户：
curl -s -X PUT --url http://<ip>:8001/consumers/{id} -d "custom_id=luoms123" | python -m json.tool
curl -s -X PUT --url http://<ip>:8001/consumers/c7456aff-ab6a-4d34-8d2e-2b987c795260 -d "custom_id=luoms123" | python -m json.tool
删除用户:
curl -i -X DELETE --url http://<ip>:8001/consumers/{id}
curl -i -X DELETE --url http://<ip>:8001/consumers/c7456aff-ab6a-4d34-8d2e-2b987c795260
六、插件
添加插件：
curl -s -X POST --url http://<ip>:8001/plugins/ -d 'name=basic-auth' -d 'route_id=90a66cdb-476e-400f-9851-cff1f04ada99' | python -m json.tool
查询所有插件：
curl -s --url http://<ip>:8001/plugins/ | python -m json.tool
查询某个插件：
curl -s --url http://<ip>:8001/plugins/{id} | python -m json.tool
更新插件:
curl -s -X PUT --url http://<ip>:8001/plugins/900aeaa3-0a47-49a1-9fea-649e6c90ab7f -d "service_id=da4dce88-4df3-4723-b544-b11b27184e97" | python -m json.tool
删除插件:
curl -s -X DELETE --url http://<ip>:8001/plugins/900aeaa3-0a47-49a1-9fea-649e6c90ab7f | python -m json.tool
查询已启用的插件:
curl -s -X GET --url http://<ip>:8001/plugins/enabled | python -m json.tool
检索插件架构:
curl -s -X GET --url http://<ip>:8001/plugins/schema/basic-auth | python -m json.tool
注意：<ip> 替换为 Kong 服务器地址 192.101.11.152
七、网关分类：
对于具体的后端业务应用或者是服务和业务有一定关联性的策略网关就是——业务网关。 业务网关针对具体的业务需要提供特定的流控策略、缓存策略、鉴权认证策略等等。
与业务网关相反，定义全局性的、跟具体的后端业务应用和服务完全无关的策略网关就是——流量网关。流量网关通常只专注于全局的Api管理策略，比如全局流量监控、日志记录、全局限流、黑白名单控制、接入请求到业务系统的负载均衡等，有点类似防火墙。Kong 就是典型的流量网关。
业务网关一般部署在流量网关之后、业务系统之前，比流量网关更靠近业务系统。