API网关Kong

原创

ylw6006 2020-11-10 09:12:07 博主文章分类：WorkSpace ©著作权

文章标签 Kong nginx api 文章分类 运维

©著作权归作者所有：来自51CTO博客作者ylw6006的原创作品，请联系作者获取转载授权，否则将追究法律责任

网关是什么，为什么我们需要网关?

网关好比我们现实生活中的大门，我们要每天出门上班，下班回家都要通过大门进出。在网络世界中网关实际上起着控制流量进出的作用。我们平常使用电脑访问互联网，路由器承担了出去流量的网关的工作，在流量到达网关后，网关使用NAT技术完成了源地址转换。（可以理解为出门前换了一双鞋子）当客户端流量到达服务端之后，也需要进入服务端的网关进行处理，这个网关通常也叫web反向代理，通常为了提高性能和安全考虑，不会直接把web中间件的端口直接暴露给用户在服务端网关这层通常要完成认证、鉴权、流控等相关环节后进行路由转发给后端的web中间件处理，最终再将结果返回给客户端

目前我们的用的网关是啥？有什么优缺点？

市面上的网关产品或者解决方案主要分软件、硬件两种。硬件主要以F5为代表，软件则以nginx、openresty、kong等为代表。我们目前的所有项目均使用nginx来做服务端的网关

优点：

配置相对简单，参考文档和配置样例多官方和第三方的模块丰富，可扩展性强性能表现优异，系统开销低，并发吞吐能力强

缺点：

项目多，项目间相同的配置大量存在，配置文件可维护行差所有的配置必须人工配置与校验，自动化能力弱日志文件集中在本地，集群环境下分析工作量大

Kong是什么？

Kong是一个在Nginx运行的Lua应用程序，由lua-nginx-module实现。OpenResty不是Nginx的分支，而是一组扩展其功能的模块(整合了Lua模块后重新发布的nginx) 。Kong和OpenResty一起打包发行，其中已经包含了lua-nginx-module

可以简单理解为： Kong > OpenResty > Nginx + lua-nginx-module

Kong 是在客户端和（微）服务间转发API通信的API网关，通过插件扩展功能。Kong 有两个主要组件：

Kong Server ：基于nginx的服务，用来接收客户端请求，分api（默认8001）和http（默认8000）、https（默认8443）三个端口 Apache Cassandra或者postgresql数据库：用来持久化存储操作数据

Kong能解决什么问题？

Kong最诱人的一个特性是可以通过插件扩展已有功能，这些插件在 API 请求响应循环的生命周期中被执行。插件使用 Lua 编写，Kong的内置插件功能有：

认证插件支持多种认证方式。如：basic auth、key auth、oauth2、hmac auth、jwt、ladp auth、session等
安全插件上支持针对消费者的API ACL策略控制、IP限制、机器人检测、acme自签免费证书等
流控插件上支持请求速率限制、请求大小限制、请求中断、代理缓存等
监控分析插件上支持prometheus、zipkin等
日志插件上支持接入TCP、UDP、HTTP协议的日志服务，同时支持syslog、statsd等日志服务
还有一些第三方的无服务插件，例如aws、azure等。

简而言之，kong在nginx、openresty的基础上整合了众多的功能，实现了API网关服务。对我们而言，最直接的是可以通过api来配置nginx上的虚拟主机，通过使用官方提供的konga webui工具konga，使得配置管理可视化

Kong的几个重要概念

1、upstream 和nginx里面的upstream一致 api地址：http://192.168.1.16:8001/upstreams (192.168.1.16是kong服务的ip地址) 重要字段： name：必须配置，和后面service关联的时候使用 algorithm：默认round-robin。目前支持三种：round-robin, consistent-hashing, least-connections

API配置示例：创建upstream

curl -i -X POST \
  --url http://192.168.1.16:8001/upstreams/ \
  --data 'name=fjwjw-dev-web' \
  --data 'algorithm=round-robin'

curl -i -X POST \
  --url http://192.168.1.16:8001/upstreams/ \
  --data 'name=fjwjw-dev-static' \
  --data 'algorithm=round-robin'

2、target 和前面的upstream相关联，配置后端web中间件的ip地址和端口，权重等 api地址：http://192.168.1.16:8001/upstreams/fjwjw-dev-web/targets (fjwjw是前面upstream的名称) 重要字段： target: 后端web中间件的ip地址和端口,不配置端口默认为8000 weight：权重

API配置示例：创建target，关联前面创建好的upstream

curl -i -X POST \
  --url http://192.168.1.16:8001/upstreams/fjwjw-dev-web/targets \
  --data 'target=192.168.1.60:80' \
  --data 'weight=100' 
  
curl -i -X POST \
  --url http://192.168.1.16:8001/upstreams/fjwjw-dev-web/targets \
  --data 'target=192.168.1.61:80' \
  --data 'weight=100'   
  
curl -i -X POST \
  --url http://192.168.1.16:8001/upstreams/fjwjw-dev-static/targets \
  --data 'target=192.168.1.13:1457' \
  --data 'weight=100'

3、service 和前面的upstream相关联，配置虚拟主机相关的信息 api地址：http://192.168.1.16:8001/services/ 重要字段： name：服务名称 host：和upstream相关联的字段 port：指定upstream端口 protocol：指定连接后端的协议 connect_timeout：客户端连接超时时长 read_timeout: 客户端读取超时时长 write_timeout: 客户端写入超时时长 ca_certificates：服务端ca证书相关关联 client_certificate: 客户端证书相关 retries：后端重试次数

API配置示例：创建service，关联upstream

 curl -i -X POST \
  --url http://192.168.1.16:8001/services/ \
  --data 'name=fjwjw-dev-web' \
  --data 'path="/web"' \
  --data 'url=http://fjwjw-dev-web' 
  
    
 curl -i -X POST \
  --url http://192.168.1.16:8001/services/ \
  --data 'name=fjwjw-dev-static' \
  --data 'path=/' \
  --data 'url=http://fjwjw-dev-static'

4、route api地址：http://192.168.1.16:8001/routes 重要字段： name：路由规则的名称 paths：路径 service：和哪个service关联 methods: 支持的http方法（需要大写） hosts: 具体访问的域名

API配置示例：创建route,和前面的service相关联

 curl -i -X POST   \
  --url http://192.168.1.16:8001/services/fjwjw-dev-web/routes   \
  --data 'name=fjwjw-dev-web'  \
  --data 'hosts[]=fjszyws.dev.59iedu.com'  \
  --data 'paths=/web'   \
  --data 'preserve_host=true' \
  --data 'strip_path=false'    

  
 curl -i -X POST   \
  --url http://192.168.1.16:8001/services/fjwjw-dev-static/routes   \
  --data 'name=fjwjw-dev-static'  \
  --data 'hosts[]=fjszyws.dev.59iedu.com'  \
  --data 'paths=/'   \
  --data 'preserve_host=true' \
  --data 'strip_path=false'

5、consumer Consumer是使用Service的用户，其核心原则是为其添加Plugin插件,从而自定义他的请求行为. 最简单的理解和配置consumer的方式是,将其于用户进行一一映射,即一个consumer代表一个用户（或应用） api地址：http://192.168.1.16:8001/consumers

使用API网关需要哪些方面的调整和挑战

1、动静分离完全拆分目前我们项目的前后端的入口都是nginx，域名完全一致。 api网关实际上更适合处理动态部分的请求。虽然不拆分前后端请求域名也能满足现有需求，但从规范性以及后续静态资源CDN加速等方面考虑，建议前后端域名进行拆分。另外，拆分之后api网关和K8S服务集成，可以使用K8S服务名与后端进行动态关联。

2、日志收集与分析使用api网关之后，所有的项目日志集中化存储，运维分析上将带来挑战，需要一套完整的日志解决方案

3、核心插件适配使用api网关之后，客户端认证、鉴权、流控等工作不需要再由应用程序完成，网关层可以承担这部分工作，在认证、鉴权、流控插件上需要适配我们的项目和应用