kong的介绍
kong基于nginx开发的API Gateway(可以认为是一个OpenResty应用程序)，可以方便的横向扩展，底层使用Apache Cassandra或PostgreSQL数据库。开发者可以方便的添加已定义的插件，甚至可以自己开发插件并使用，来达到代理、负载均衡、健康检查、日志、登录等功能。 --https://konghq.com/about-kong/
kong的服务架构
请求流程：
- 浏览器访问域名，经过DNS解析到kong的地址
- kong根据域名识别到相应服务。 (除了kong的每个服务需要被分配一个域名，域名都指向kong的ip地址)
-
kong对此服务配备的插件(限流、认证、负载均衡)校验
- 校验成功，获取服务相应资源
oauth2.0的介绍
OAuth在"客户端"(浏览器)与"服务提供商"(接口服务)之间，设置了一个授权层。"客户端"不能直接登录"服务提供商"，只能登录授权层，以此将用户与客户端区分开来。"客户端"登录授权层以后，"服务提供商"根据令牌的权限范围和有效期，向"客户端"开放用户储存的资料。
- A. 向客户端提供用户名和密码
- B. 客户端将用户名和密码发给认证服务器，向后者请求令牌
- C. 认证服务器确认无误后，向客户端提供访问令牌
kong oauth2插件的使用
kong的核心概念：
- upstream：相当于nginx的upstream
- target：相当于nginx中upstream的server
- service: 相当于nginx的server，可以指向到一个upstream
- route: 相当于nginx中service的location
- plugin：插件，可以配置到service或者route甚至所有服务
- consumer：用户
- certificate：凭证
对于kong的oauth插件来说，consumer相当于oauth中的client。
这里kong是不提供用户校验的，所以我们需要自己开发一个backend来做用户的信息校验。
图例：(线段是对应颜色节点的行为)
- 绿色client application: 客户端，前端项目
- 黄色kong: kong / kong dashboard(kong api的GUI项目)
- 蓝色webapp backend: 待开发的用户验证服务，需要连接用户数据库
- 紫色resource service: 资源服务
前端请求流程(即上图client application的三条线段)：
用户注册也是访问backend服务
- 请求backend的域名，请求内容是username和password，获取到token及refresh token。
- 请求资源服务的域名，请求携带token，并获取到数据资源
- token过期后，刷新token
