微服务网关Kong系列文章之一：简介

为什么需要 API 网关？

当使用单体应用程序架构时，客户端（Web 或移动端）通过向后端应用程序发起一次 REST 调用来获取数据。负载均衡器将请求路由给 N 个相同的应用程序实例中的一个。然后应用程序会查询各种数据库表，并将响应返回给客户端。微服务架构下，单体应用被切割成多个微服务，如果将所有的微服务直接对外暴露，势必会出现安全方面的各种问题。

客户端可以直接向每个微服务发送请求，其问题主要如下：

• 客户端需求和每个微服务暴露的细粒度API不匹配。
• 部分服务使用的协议不是Web友好协议。可能使用Thrift二进制RPC，也可能使用AMQP消息传递协议。
• 微服务难以重构。如果合并两个服务，或者将一个服务拆分成两个或更多服务，这类重构就非常困难了。

服务端的各个服务直接暴露给客户端调用势必会引起各种问题。同时，服务端的各个服务可扩展和伸缩性很差。API 网关是微服务架构中的基础组件，位于接入层之下和业务服务层之上，如前所述的这些功能适合在 API 网关实现。

什么是kong？

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

面对以上问题，API GATEWAY是一个不错的解决方案，其所提供的访问限制、安全、流量控制、分析监控、日志、请求转发、合成和协议转换功能，可以解放开发者去把精力集中在具体逻辑的代码，而不是把时间花费在考虑如何解决应用和其他微服务链接的问题上。

为什么使用kong？

提供类似的API网关不止一家，Kong侧重于解决如下传统方式的四大痛点：

kong的基本架构

Kong 是 Mashape 开源的高性能高可用 API 网关和 API 服务管理层，一款基于 Nginx_Lua 模块写的高可用服务网关，由于 Kong 是基于 Nginx 的，所以可以水平扩展多个 Kong 服务器。通过前置的负载均衡配置把请求均匀地分发到各个 Server，来应对大批量的网络请求。

Kong 主要有三个组件：

• Kong Server ：基于nginx的服务器，用来接收 API 请求。
• Apache Cassandra/PostgreSQL：用来存储操作数据。
• Kong dashboard：官方推荐 UI 管理工具，当然，也可以使用restfull方式管理 admin api。

Kong dashboard 支持的版本

Kong 采用插件机制进行功能定制，插件集（可以是 0 或 N 个）在 API 请求响应循环的生命周期中被执行。插件使用 Lua 编写，基础功能包括：HTTP 基本认证、密钥认证、CORS（Cross-Origin Resource Sharing，跨域资源共享）、TCP、UDP、文件日志、API 请求限流、请求转发以及 Nginx 监控等。