前言
在微服务架构中, 由于系统和服务的细分, 导致系统结构变得非常复杂, 为了跨平台, 为了统一集中管理 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 和我进行直接的探讨交流.
来源: http://www.bubuko.com/infodetail-3496867.html