微服务网关除了zuul、spring cloud gateway还有更出色的

前言

在微服务架构中，由于系统和服务的细分，导致系统结构变得非常复杂， 为了跨平台，为了统一集中管理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停止维护，Spring Cloud Gateway还在完善之中的情况下，Kong也是值得关注的网关技术选型之一。今后也会在https://www.spring4all.com 分享相关的使用心得。 也可以关注社区公众号：SpringForAll社区 和我进行直接的探讨交流。