开源API网关Kong基本介绍和安装验证

本文将介绍开源API网关Kong。在GtiHub搜索API网关类的开源产品，可以看到Kong网关常年都是排第一的位置，而且当前很多都有一定研发能力的企业在API网关产品选型的时候基本也会选择Kong网关，并基于Kong网关进行二次开发和定制。

API网关概述

简单来说API网关就是将所有的微服务提供的API接口服务能力全部汇聚进来，统一接入进行管理，也正是通过统一拦截，就可以通过网关实现对API接口的安全，日志，限流熔断等共性需求。如果再简单说下，通过网关实现了几个关键能力。

• 内部的微服务对外部访问来说位置透明，外部应用只需和网关交互
• 统一拦截接口服务，实现安全，日志，限流熔断等需求

从这里，我们就可以看到API网关和传统架构里面的ESB总线是类似的，这些关键能力本身也是ESB服务总线的能力，但是ESB服务总线由于要考虑遗留系统的接入，因此增加了：

• 大量适配器实现对遗留系统的遗留接口适配，多协议转换能力
• 进行数据的复制映射，路由等能力

对于两者，我原来做过一个简单的对比，大家可以参考。

基于Openresty开发API网关

在谈API网关前，我们先谈下Openresty。在前面文章谈到过，当前适合用于API网关的架构，一种是基于Openresty的，一种是基于Go语言的。

OpenResty®是一个基于Nginx与Lua的高性能Web平台，其内部集成了大量精良的Lua库、第三方模块以及大多数的依赖项。用于方便地搭建能够处理超高并发、扩展性极高的动态Web应用、Web服务和动态网关。

OpenResty®通过汇聚各种设计精良的Nginx模块（主要由OpenResty团队自主开发），从而将Nginx有效地变成一个强大的通用系统Web应用平台。这样，Web开发人员和系统工程师可以使用Lua脚本语言调动Nginx支持的各种C以及Lua模块，快速构造出足以胜任10K乃至1000K以上单机并发连接的高性能Web应用系统。

OpenResty®的目标是让你的Web服务直接跑在Nginx服务内部，充分利用Nginx的非阻塞I/O模型，不仅仅对HTTP客户端请求，甚至于对远程后端诸如MySQL、PostgreSQL、Memcached以及Redis等都进行一致的高性能响应。

为何OpenResty适合用于API网关开发？

对于API网关，有一个最基础的核心功能即需要实现接口服务代理路由，而这个本身也是Nginx反向代理能够提供的一个标准功能。

如果应用场景比较简单，仅仅是实现统一接口对外暴露，可以看到很多企业实际并没有采用API网关，而是直接采用了Nginx来替代API网关的服务代理路由功能。

其次，对于常规的API网关的中间件研发，在研发完成后本身还要依托一个Web容器进行部署，同时还需要自己去实现类似路由代理等各种能力。

在这种场景下可以看到，依托于Nginx，在其内部来扩展一个Web容器能力，既可以充分的利用Nginx本身的代理路由和性能优势就是一个重要的选择。而OpenResty本身可以看做是基于Nginx服务器，在其worker里面内嵌了一个LuaJVM，通过这种方式来实现了两者的融合。同时又可以通过开发和定制各种Lua库来进行快速的功能扩展。

也正是这样原因，基于Openresty来扩展动态网关功能是一个很好的选择。

OpenResty的安装

在CentOS下可以通过yum很方便的安装OpenResty，具体如下：

//安装yum-utils
# sudo yum install yum-utils
//添加OpenResty仓库
sudo yum-config-manager --add-repo https://openresty.org/package/centos/openresty.repo
//安装OpenResty
# sudo yum install openresty
//安装命令行工具
# sudo yum install openresty-resty
//至此安装成功，默认安装在  /usr/local/openresty
//测试
# sudo /sbin/service openresty start
# sudo /sbin/service openresty stop

注意在安装完成后如果通过浏览器访问，需要先关闭防火墙或者打开放行80端口。

Kong网关概述

首先我们看下GitHub上对Kong网关的一些介绍。

当我们决定对应用进行微服务改造时，应用客户端如何与微服务交互的问题也随之而来，毕竟服务数量的增加会直接导致部署授权、负载均衡、通信管理、分析和改变的难度增加。