Kong的API管理方式


前言须知:
从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.comapi.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.comapi.service.com的请求转到到我们的Kong集群上,也就是我们上面一节中通过Nginx配置的请求地址

那么,当我们请求api.example.com/loginapi.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↓]

posted @ 2019-12-03 16:45  孙红雷哔哔  阅读(3228)  评论(0编辑  收藏  举报