kong组件_Kong API Gateway部署手册----介绍

Changlog 20171025:

1、Kong 0.11.x仅支持openresty 1.11.2.4(openresty 1.11.2.5不支持)

2、Kong 0.11.x不在依赖serf了

3、Kong 0.11.x默认开启HTTP/2(其实0.10.x是可以手动修改配置文件来支持的)

4、Kong 0.11.x支持了请求在路由时能够使用带有正则的URI

5、Kong 0.11.x里终于官方支持了升级路线

另外，Kong到目前为止基本上该有的功能都有了，可以放心投入生产了。

Kong 0.11.x  openresty 1.11.2.4

Kong 0.10.x  openresty 1.11.2.2

Changlog 20170626:

1、更新Kong dnsmasq组件的介绍

2、更新Kong在某些场景下https的应用

Kong是一个开源的、可伸缩的API层，也可以称为API网关或者API中间件，这东西是完全是基于lua-nginx模块开发的，关于Kong的特性可以查看官网，有详细的说明。

目前Kong由一些几个组件构成：

1、Nginx(官方说是Nginx，其实是OpenResty)

2、lua-nginx-module(所有的功能都是基于这个东西)

3、Apache Cassandra(太重了，虽然作为API的话，这货没啥压力，天然支持Cluster)

4、PostgreSQL(更适合生产环境里部署，这货的Cluster需要第三方软件支持)

5、dnsmasq(不是必须组件，在部署过程中可以使用用户自己部署的DNS服务，目前Kong 0.10.x的版本更支持了SRV记录，也可以直接添加IP:PORT的方式使用)

Kong的其他特点

1、伸缩性：主要是可以通过水平增加Kong的节点来处理负载(一般2台Kong做HA的时候可以提供20000 Request/S；用Haproxy+Kong的话性能更好，此处为虚拟机的测试结果)

2、模块化：Kong有很多插件，而且可以通过RESTful API来管理配置

3、可以在任何设施运行：可以运行在物理机、虚拟机、云上等

盗用下官方的架构图

实际上Kong通过lua-nginx实现了动态增加upstream的功能，让$host作为upstream的名字以及proxy_pass的对象，由于使用了$host变量，所以组件中默认带了dnsmasq作为解析$host的DNS,其中$host不是l来自url，而是来自HTTP Header中的Host字段，现有的0.8.3和0.9.3版本都不支持同一个upstream中有多台server，也就导致了upstream中的server是个单点，目前解决办法是使用skydns+rr算法对$host做多台机器的解析来解决单点问题，在0.10.x版本中Kong把upstream中的server称为target，一般的步骤是先创建API，然后创建这个API对应的upstream，然后再创建这个upstream对应的target，呵呵，流程就是这样。

Kong的使用有两种方式：

1、通过不同的uri来访问不同的API

2、通过应用在HTTP Header中携带Host字段，来访问不同的API(个人认为这种方式更加方便使用，在这种场景下如果需要跟第三方的服务对接，例如跟微信对接时，对方直接要求我们的接口需要支持HTTPS，当然在0.9.X的版本中我们通过增加自定义的一个HOST头来使用解决了这个问题，但是在0.10.X版本中这样方法不管用了，因为代码里对http路由做了很大的调整，所以在这种情况下就不能使用HOST头部来处理了，而是使用uris的方式来访问后端的API服务)

Kong的应用场景

1、Web PC端的API调用

2、手机 APP的API调用