API网关Kong

网关是什么，为何咱们须要网关?

网关比如咱们现实生活中的大门，咱们要天天出门上班，下班回家都要经过大门进出。在网络世界中网关实际上起着控制流量进出的做用。咱们日常使用电脑访问互联网，路由器承担了出去流量的网关的工做，在流量到达网关后，网关使用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、oauth二、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的几个重要概念

一、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'

二、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'

三、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'

四、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'

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

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

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

二、日志收集与分析
使用api网关以后，全部的项目日志集中化存储，运维分析上将带来挑战，须要一套完整的日志解决方案

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