Kong的API管理方式

目录

• Kong 的管理方式
  • 1. kong的关键术语
    • Service：
    • Route：
    • Upstream：
    • Target：
    • API：
    • Consumer：
    • Plugin：
  • 2. 如何通过配置KONG API实现对目标(API或应用)的访问
    • kong的重要对象关系
    • kong对象特征

---

前言须知：

从0.13开始 kong就弃用的api改用service来组织api

• 增加了service Route Upstream Target
• service 相当于原来的api,但是没有路由信息,可以直接挂载物理host,也可以挂一个Upstream的host
• Route指kong的路由实体。Route是Kong的入口，定义了请求的匹配规则，路由到指定的服务。就是专门定义外部访问的分发hosts,strip_path,preserve_host,protocols,甚至method都在这里定义,和service关联
• Upstream,这个是新东西,一个虚拟的后端服务, 需要结合Target一起使用, 好处是可以在这里就完成负载均衡,还有健康检查
• 给Upstream添加实际的物理节点,实现的负载均衡

Kong 的管理方式

Kong 简单易用的背后，便是其所有的操作都是基于 HTTP Restful API 来进行的，Kong 在port上公开了RESTful Admin API:8001，使用它可以动态地添加和删除API以及使用基于插件架构的Nginx/OpenResty的功能。

kong的操作及功能实现围绕下面的知识点展开。

1. kong的关键术语

Service：

Service 顾名思义，就是我们自己定义的上游服务，通过Kong匹配到相应的请求要转发的地方

Service 可以与下面的Route进行关联，一个Service可以有很多Route，匹配到的Route就会转发到Service中，

当然中间也会通过Plugin的处理，增加或者减少一些相应的Header或者其他信息

Service可以是一个实际的地址，也可以是Kong内部提供的upstream object

Route：

Route 字面意思就是路由，实际就是我们通过定义一些规则来匹配客户端的请求，每个路由都会关联一个Service,

并且Service可以关联多个Route，当匹配到客户端的请求时，每个请求都会被代理到其配置的Service中

Route作为客户端的入口，通过将Route和Service的松耦合，可以通过hosts path等规则的配置，最终让请求到不同的Service中

例如，我们规定api.example.com 和 api.service.com的登录请求都能够代理到10.11.11.11:8000端口上，那我们可以通过hosts和path来路由

首先，创建一个Service s1，其相应的host和port以及协议为http://10.11.11.11:8000

然后，创建一个Route，关联的Service为s1，其hosts为api.service.com, api.example.com,path为login

最后，将域名api.example.com和api.service.com的请求转到到我们的Kong集群上，也就是我们上面一节中通过Nginx配置的请求地址

那么，当我们请求api.example.com/login和api.service.com/login时，其通过Route匹配，然后转发到Service，最终将会请求我们自己的服务。

Upstream：

这是指您自己的API /服务位于Kong后面，客户端请求被转发到该服务器。

相当于Kong提供了一个负载的功能，基于Nginx的虚拟主机的方式做的负载功能

当我们部署集群时，一个单独的地址不足以满足我们的时候，我们可以使用Kong的upstream来进行设置

首先在service中指定host的时候，可以指定为我们的upstream定义的hostname

我们在创建upstream时指定名字，然后指定solts(暂时不确定具体作用)，upstream可以进行健康检查等系列操作。这里先不开启（还没有研究）

然后我们可以再创建target类型，将target绑定到upstream上，那么基本上我们部署集群时，也可以使用

Target：

target 就是在upstream进行负载均衡的终端，当我们部署集群时，需要将每个节点作为一个target，并设置负载的权重，当然也可以通过upstream的设置对target进行健康检查。

当我们使用upstream时，整个路线是 Route >> Service >> Upstream >> Target

API：

用于表示您的上游服务的传统实体。自0.13.0起弃用服务。这里就不在深入了解

Consumer：

Consumer 可以代表一个服务，可以代表一个用户，也可以代表消费者，可以根据我们自己的需求来定义

可以将一个Consumer对应到实际应用中的一个用户，也可以只是作为一个Service的请求消费者

Consumer具体可以在Plugin使用时再做深入了解

Plugin：

在请求被代理到上游API之前或之后执行Kong内的动作的插件。

例如，请求之前的Authentication或者是请求限流插件的使用

Plugin通过Admin API配置，可以和Service绑定，也可以和Route以及Consumer进行关联。

2. 如何通过配置KONG API实现对目标(API或应用)的访问

其实用nginx的配置去举例KONG API 是有些差异的，这里只是通过nginx比较形象的让你理解kong的service、route以及其他相关联的对象。

我们来看一个典型的Nginx的配置对应在Kong上是怎么样的，下面是一个典型的Nginx配置

upstream helloUpstream {
    server localhost:3000 weight=100;
}

server {
    listen 8000;
    location /hello {
        proxy_pass http://helloUpstream;
    }
}

下面我们来看看其对应Kong中的配置

# 配置 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"

这一切配置都是通过其Http Restful API 来动态实现的，无需我们在手动的 reload Nginx.conf 。开发的同学看到这是不是感觉到很幸福了。

在上述的配置中涉及到了几个概念：upstrean、target、service、route等概念，它们是Kong的几个核心概念，也是我们在使用Kong Api时经常打交道的。

kong的重要对象关系

从上面的配置及字面解释大概能够推测出他们的职责：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对象特征

---

更多知识参考：

代理参考

负载平衡参考

Admin API: 详解各个对象的相关内容

[sleepy↓]