微服务最强开源流量网关Kong

前言

在微服务架构中，因为系统和服务的细分，致使系统结构变得很是复杂， 为了跨平台，为了统一集中管理api，同时为了避免暴露后置服务。甚至有时候须要对请求进行一些安全、负载均衡、限流、熔断、灰度等中间操做，基于此类种种的客观需求一个相似综合前置的系统就产生了，这就是API网关（API Gateway）。API网关做为分散在各个业务系统微服务的API聚合点和统一接入点，外部请求经过访问这个接入点，便可访问内部全部的REST API服务。目前经常使用的微服务网关有zuul、gateway，今天来简单介绍一下另外一种选择——Kong 。说到Kong可能对你们有点陌生，咱们来先了解下另外一种不陌生的中间件——OpenResty。

OpenResty

OpenResty® 是一个基于 Nginx 与 Lua 的高性能 Web 平台，其内部集成了大量精良的 Lua 库、第三方模块以及大多数的依赖项。用于方便地搭建可以处理超高并发、扩展性极高的动态 Web 应用、Web 服务和动态网关。所以，咱们能够作出各类符合咱们须要的网关策略的Lua脚本，以其为基础构建高性能的网关系统。

Kong

Kong基于OpenResty，是一个云原生、快速、可扩展、分布式的Api 网关。继承了OpenResty的高性能、易扩展性等特色。Kong经过简单的增长机器节点，能够很容易的水平扩展。同时功能插件化，可经过插件来扩展其能力。并且在任何基础架构上均可以运行。具备如下特性：

• 提供了多样化的认证层来保护Api。
• 可对出入流量进行管制。
• 提供了可视化的流量检查、监视分析Api。
• 可以及时的转换请求和相应。
• 提供log解决方案
• 可经过api调用Serverless 函数。

业务网关与流量网关

对于具体的后端业务应用或者是服务和业务有必定关联性的策略网关就是上图左边的架构模型——业务网关。 业务网关针对具体的业务须要提供特定的流控策略、缓存策略、鉴权认证策略等等。

与业务网关相反，定义全局性的、跟具体的后端业务应用和服务彻底无关的策略网关就是上图右边所示的架构模型——流量网关。流量网关一般只专一于全局的Api管理策略，好比全局流量监控、日志记录、全局限流、黑白名单控制、接入请求到业务系统的负载均衡等，有点相似防火墙。Kong 就是典型的流量网关。

这里须要补充一点的是，业务网关通常部署在流量网关以后、业务系统以前，比流量网关更靠近业务系统。一般API网指的是业务网关。 有时候咱们也会模糊流量网关和业务网关，让一个网关承担全部的工做,因此这二者之间并无严格的界线。

Kong 的架构

请求流程

每一个客户请求都会先到达Kong 网关，而后再代理到最终的API。在请求和响应之间，Kong将执行已安装配置的插件，从而扩展AP的I功能集。

插件

插件做为Kong的一大特点这里不得不简单提一下，目前Kong的插件有免费、有收费（企业版）、还有社区（github）提供的，有能力也能够经过Kong官方提供的模板使用lua脚原本开发本身定制的插件。现阶段提供有8类插件功能涉及身份验证、权限安全、流量控制、Serverless、分析与监控、数据转换、日志信息、部署发布。可经过官方插件库或者github搜索来获取。

上手难度

Kong 提供了在各个平台的安装包。目前最新版本提供了无数据库依赖和数据库依赖两种模式，安装并不复杂。若是从现有的Kong提供的功能来讲，所有基于配置。可经过配置文件或者Restful Admin Api 进行配置管理。并且有不少第三方可视化UI，如Konga 。若是须要对Kong进行定制化开发，须要深度掌握OpenResty、Nginx、lua脚本等相关的知识，因此通常建议Kong做为流量网关使用。

总结

今天大致简单介绍了Kong网关，在zuul中止维护，gateway还在完善之中的状况下，Kong也是值得关注的网关技术选型之一。从此也会在https://felord.cn 分享相关的使用心得。 也能够关注个人公众号：Felordcn 和我进行直接的探讨交流。

关注公众号：码农小胖哥 获取更多资讯