共计 1341 个字符，预计需要花费 4 分钟才能阅读完成。
Kong系列文章
当使用单体应用程序架构时，客户端（Web 或移动端）通过向后端应用程序发起一次 REST 调用来获取数据。负载均衡器将请求路由给 N 个相同的应用程序实例中的一个。然后应用程序会查询各种数据库表，并将响应返回给客户端。微服务架构下，单体应用被切割成多个微服务，如果将所有的微服务直接对外暴露，势必会出现安全方面的各种问题。
客户端可以直接向每个微服务发送请求，其问题主要如下：
-
客户端需求和每个微服务暴露的细粒度
API不匹配。 -
部分服务使用的协议不是Web友好协议。可能使用
Thrift二进制RPC，也可能使用AMQP消息传递协议。 -
微服务难以重构。如果合并两个服务，或者将一个服务拆分成两个或更多服务，这类重构就非常困难了。
什么是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 监控等。
