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

网关好比我们现实生活中的大门,我们要每天出门上班,下班回家都要通过大门进出。在网络世界中网关实际上起着控制流量进出的作用。我们平常使用电脑访问互联网,路由器承担了出去流量的网关的工作,在流量到达网关后,网关使用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的内置插件功能有:

  1. 认证插件支持多种认证方式。如:basic auth、key auth、oauth2、hmac auth、jwt、ladp auth、session等
  2. 安全插件上支持针对消费者的API ACL策略控制、IP限制、机器人检测、acme自签免费证书等
  3. 流控插件上支持请求速率限制、请求大小限制、请求中断、代理缓存等
  4. 监控分析插件上支持prometheus、zipkin等
  5. 日志插件上支持接入TCP、UDP、HTTP协议的日志服务,同时支持syslog、statsd等日志服务
  6. 还有一些第三方的无服务插件,例如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网关之后,客户端认证、鉴权、流控等工作不需要再由应用程序完成,网关层可以承担这部分工作,在认证、鉴权、流控插件上需要适配我们的项目和应用