大家好,又见面了,我是你们的朋友全栈君。
最近公司打算重构API网关,给定的硬性条件是支持lua脚本,kubernetes可部署,可解析lua,另外需要支持身份认证,IP黑白名单,限流,负载均衡等一些功能,为此,在技术选型上锁定了kong以及APISIX,最终选择了kong。
其原因如下:
举一个例子:Zuul,其自身只提供基本的路由功能,如果想使用其他功能,就需自研,而这些成本是很高的,另外,他与spring cloud深度集成,就需要引入其他的框架; 另外,附一个性能测试链接:Kong1.4 vs SC Gateway2.2 vs Zuul1.3 性能测试
目前市面上的开源的API网关除了kong还有:
其对比如下:
Kong | Traefik | Ambassador | Tyk | Zuul | |
---|---|---|---|---|---|
基本 | |||||
主要用途 | 企业级API管理 | 微服务网关 | 微服务网关 | 微服务网关 | 微服务网关 |
学习曲线 | 适中 | simple | simple | 适中 | simple |
成本 | 开源/企业版 | 开源 | 开源/pro | 开源/企业版 | 开源 |
社区star | 20742 | 21194 | 1719 | 4299 | 7186 |
配置 | |||||
配置语言 | Admin Rest api, Text file(nginx.conf 等) | TOML | YAML(kubernetes annotation) | Tyk REST API | REST API,YAML静态配置 |
配置端点类型 | 命令式 | 声明式 | 声明式 | 命令式 | 命令式 |
拖拽配置 | yes | no | no | no | no |
管理模式 | configurable | decentralised, self-service | decentralised, self-service | decentralised, self-service | decentralised, self-service |
部署 | |||||
kubernetes | 适中(k8s yaml,helm chart) | easy | easy | 适中(k8s yaml,helm chart) | 适中(k8s yaml,helm chart) |
Cloud IAAS | high | easy | N/A | easy | easy |
Private Data Center | high | easy | N/A | easy | easy |
部署模式 | 金丝雀(企业版) | 金丝雀 | 金丝雀,shadow | 金丝雀 | 金丝雀 |
state | postgres,cassandra | kubernetes | kubernetes | redis | 内存文件 |
可扩展性 | |||||
扩展功能 | 插件 | 自己实现 | 插件 | 插件 | 自己实现 |
扩展方法 | 水平 | 水平 | 水平 | 水平 | 水平 |
功能 | |||||
服务发现 | 动态 | 动态 | 动态 | 动态 | 动态 |
协议 | http,https,websocket | http,https,grpc,websocket | http,https,grpc,websocket | http,https,grpc,websocket | http,https |
基于 | kong+nginx | traefik | envoy | tyk | zuul |
ssl 终止 | yes | yes | yes | yes | no |
websocket | yes | yes | yes | yes | no |
routing | host,path,method | host,path | host,path,header | host,path | |
限流 | yes | no | yes | yes | 需要开发 |
熔断 | yes | yes | no | yes | 需要其他组件 |
重试 | yes | yes | no | yes | yes |
健康检查 | yes | no | no | yes | yes |
负载均衡算法 | 轮询,哈希 | 轮询,加权轮询 | 加权轮询 | 轮询 | 轮询,随机,加权轮询,自定义 |
权限 | Basic Auth, HMAC, JWT, Key, LDAP, OAuth 2.0, PASETO, plus paid Kong Enterprise options like OpenID Connect | basic | yes | HMAC,JWT,Mutual TLS,OpenID Connect,基本身份验证,LDAP,社交OAuth(例如GPlus,Twitter,Github)和传统基本身份验证提供程序 | 开发实现 |
tracing | yes | yes | yes | yes | 需要其他组件 |
istio集成 | no | no | yes | no | no |
dashboard | yes | yes | grafana,Prometheus | yes | no |
引用链接:微服务五种开源API网关实现组件对比
Kong 由Mashape公司开源,是一个在 Nginx 中运行的Lua应用程序,并且可以通过lua-nginx模块实现,Kong不是用这个模块编译Nginx,而是与 OpenResty 一起发布,OpenResty已经包含了 lua-nginx-module, OpenResty 不是 Nginx 的分支,而是一组扩展其功能的模块。
三者的关系如下:
实现数据库抽象,路由和插件管理,插件可以存在于单独的代码库中,并且可以在几行代码中注入到请求生命周期的任何位置。 由于Kong是运行在OpenResty,我们先来看一下OpenResty执行流程:
图出处:OpenResty 执行流程阶段
Kong通过在 openresty 各个阶段加入了lua代码来实现插件的注入和执行,Kong 的 nginx 配置:
init_by_lua_block {
kong = require 'kong'
kong.init() // 完成 Kong 的初始化,路由创建,插件预加载等
}
init_worker_by_lua_block {
kong.init_worker() // 初始化 Kong 事件, worker 之间的事件,由 worker_events 来处理, cluster 节点之间的事件,由 cluster_events 来处理,缓存机制
}
upstream kong_upstream {
server 0.0.0.1;
balancer_by_lua_block {
kong.balancer() //负载均衡
}
keepalive 60;
}
server {
server_name kong;
listen 0.0.0.0:8000 reuseport backlog=16384;
listen 0.0.0.0:8443 ssl http2 reuseport backlog=16384;
rewrite_by_lua_block {
kong.rewrite() //插件生效策略的筛选,并执行对应的操作,只能处理全局插件(kong插件级别,全局(作用于所有请求),route(作用于当前路由),service(作用于匹配到当前service的所有请求)),路由匹配未开始。
}
access_by_lua_block {
kong.access() //1.完成路由匹配,2.确认加载的插件(并加入缓存) 3.进入balancer阶段
}
header_filter_by_lua_block {
kong.header_filter() //遍历在缓存中的插件列表,并执行
}
body_filter_by_lua_block {
kong.body_filter() //遍历在缓存中的插件列表,并执行
}
log_by_lua_block {
kong.log() //遍历在缓存中的插件列表,并执行
}
location / {
proxy_pass $upstream_scheme://kong_upstream$upstream_uri;
}
}
函数名 | LUA-NGINX-MODULE Context | 描述 |
---|---|---|
:init_worker() | init_worker_by_lua | 在每个 Nginx 工作进程启动时执行 |
:certificate() | ssl_certificate_by_lua | 在SSL握手阶段的SSL证书服务阶段执行 |
:rewrite() | rewrite_by_lua | 从客户端接收作为重写阶段处理程序的每个请求执行。在这个阶段,无论是API还是消费者都没有被识别,因此这个处理器只在插件被配置为全局插件时执行 |
:access() | access_by_lua | 为客户的每一个请求而执行,并在它被代理到上游服务之前执行(路由) |
:header_filter() | header_filter_by_lua | 从上游服务接收到所有响应头字节时执行 |
:body_filter() | body_filter_by_lua | 从上游服务接收的响应体的每个块时执行。由于响应流回客户端,它可以超过缓冲区大小,因此,如果响应较大,该方法可以被多次调用 |
:log() | log_by_lua | 当最后一个响应字节已经发送到客户端时执行 |
对于kong的部署,由于它是基于Nginx的,所以只需要添加多台服务器就可以配置成一个集群,通过前置的负载均衡配置把请求均匀地分发到各个 Server,来应对大批量的网络请求。
共分为3大块:
具体如下:
目前已经提供的插件有:
kong目前提供了37个插件,其中商业收费7个,30个开源免费的插件,可以设定到api/服务/路由粒度上,详情如下:
类别 | 免费/收费 | name | 插件名 | 使用场景 |
---|---|---|---|---|
认证 | 免费 | basic-auth | Basic Authentication | 对于服务或者路由提供用户名/密码基本认证机制 |
认证 | 免费 | key-auth | Key Authentication | 对于服务或者路由提供用关键字认证机制 |
认证 | 收费 | – | OpenID Connect | 提供与三方OpenID的集成方式 |
认证 | 免费 | oauth2 | OAuth 2.0 Authentication | 添加OAuth 2.0认证 |
认证 | 收费 | – | OAuth 2.0 Introspection | 提供与三方OAuth 2.0认证服务器的集成方式 |
认证 | 免费 | hmac-auth | HMAC Authentication | 提供HMAC(Hashed Message Authentication Code)签名认证方式 |
认证 | 免费 | jwt | JWT | 提供JWT(JSON WEB Token)的认证方式 |
认证 | 免费 | ldap-auth | LDAP Authentication | 提供了与LDAP认证服务器的集成方式 |
安全 | 免费 | acl | ACL | 通过ACL(Access Control List)的组名称对服务或者路由进行黑白名单的访问控制 |
安全 | 免费 | cors | CORS | 对服务或者路由提供CORS支持 |
安全 | 免费 | ip-restriction | IP Restriction | 通过IP地址对服务或者路由进行黑白名单的访问控制 |
安全 | 免费 | bot-detection | Bot Detection | 对服务或者路由提供机器人检出并能进行黑白名单的设定 |
安全 | 免费 | ssl | Dynamic SSL | 对路由或者API提供ssl支持 |
流量控制 | 收费 | – | EE Canary Release | 提供金丝雀发布支持 |
流量控制 | 收费 | – | EE Forward Proxy | 提供企业内网中前向代理的支持 |
流量控制 | 收费 | – | EE Proxy Caching | 提供代理缓存的加速功能 |
流量控制 | 免费 | request-size-limiting | Request Size Limiting | 可以对请求的body的size进行限制 |
流量控制 | 免费 | rate-limiting | Rate Limiting | 提供对给定时间段HTTP请求数目的控制功能 |
流量控制 | 收费 | – | EE Rate Limiting | CE版本Rate Limiting的强化 |
流量控制 | 免费 | response-ratelimiting | Response Rate Limiting | 基于用户响应Header的信息,提供对HTTP请求数目的控制功能 |
流量控制 | 免费 | request-termination | Request Termination | 根据响应的状态码和信息,可停止对某个服务或者路由的流量 |
Serverless | 免费 | aws-lambda | AWS Lambda | 调用和管理AWS Lambda函数 |
Serverless | 免费 | openwhisk | Apache OpenWhisk | 调用和管理OpenWhisk |
分析&监控 | 免费 | zipkin | Zipkin | 提供兼容zipkin的方式对用户请求进行追踪 |
分析&监控 | 免费 | datadog | Datadog | 可将API的指标信息在datadog上进行可视化地展示 |
分析&监控 | 免费 | runscope | Runscope | 结合runscope进行API性能测试和监控 |
转换 | 免费 | request-transformer | Request Transformer | 通过kong对请求进行转换 |
转换 | 收费 | – | EE request Transformer | request Transformer的强化版 |
转换 | 免费 | response-transformer | Response Transformer | 通过kong对响应进行转换 |
转换 | 免费 | correlation-id | Correlation ID | 通过kong实现请求和响应之间的关联 |
日志 | 免费 | tcp-log | TCP | 发送请求和响应日志到TCP服务器 |
日志 | 免费 | udp-log | UDP | 发送请求和响应日志到UDP服务器 |
日志 | 免费 | http-log | HTTP | 发送请求和响应日志到HTTP服务器 |
日志 | 免费 | file-log | File | 发送请求和响应日志到磁盘的文件中 |
日志 | 免费 | statsd | StatsD | 发送请求和响应日志到StatsD服务器 |
日志 | 免费 | syslog | Syslog | 发送请求和响应日志到syslog中 |
日志 | 免费 | syslog | Loggly | 发送请求和响应日志到Loggly服务器 |
从技术的角度讲,Kong 可以认为是一个 OpenResty 应用程序。 OpenResty 运行在 Nginx 之上,使用 Lua 扩展了 Nginx。 Lua 是一种非常容易使用的脚本语言,可以让你在 Nginx 中编写一些逻辑操作。之前我们提到过一个概念 Kong = OpenResty + Nginx + Lua,但想要从全局视角了解 Kong 的工作原理,还是直接看源码比较直接。我们定位到本地的 Kong 文件夹,按照上图中的目录层级来识识 Kong 的庐山真面目。
从上述文件夹浏览下来,大概可以看到它和 Nginx 的相似之处,并在此基础之上借助于 Lua 对自身的功能进行了拓展,除了 nginx.conf 中的配置,和相对固定的文件层级,Kong 还需要连接一个数据库来管理路由配置,服务配置,upstream 配置等信息,是的,由于 Kong 支持动态路由的特性,所以几乎所有动态的配置都不是配置在文件中,而是借助于 Postgres 或者 Cassandra 进行管理。
Kong 对外暴露了 Restful API,最终的配置便是落地在了数据库之中。
引用链接:https://mp.weixin.qq.com/s/CWGy6cwy6QGLvwByurEGbw
API 网关可以通过实现一些中间件来解决一些问题,这些中间件的功能你就不用再到每个service中实现了。你也是知道的,不同的团队使用不同的方式来实现了不同的微服务。
如果你不去做一些中心化和抽象化的事情,你将会死于不同的认证方式以及不同的速率限制实现,五花八门。你肯定希望避免这样的糟糕局面。
API网关不仅可以帮你解决API的管理部分,而且还可以解决下面两件事情:
Kong作为API网关提供了API管理功能,及围绕API管理实现了一些默认的插件,另外还具备集群水平扩展能力,从而提升整体吞吐量。Kong本身是基于OpenResty,可以在现有Kong的基础上进行一些扩展,从而实现更复杂的特性。
虽然有一些特性Kong默认是缺失的,如API级别的超时、重试、fallback策略、缓存、API聚合、AB测试等,这些功能插件需要企业开发人员通过Lua语言进行定制和扩展。
传统方式的四大痛点:
痛点 | 说明 |
---|---|
重复多 | 在多个微服务中,共通的功能重复,比如认证或者日志相关共通模块 |
巨石化 | 单个服务仍然后变成尾大不掉的巨石应用的趋势 |
影响大 | 影响较大,很难做到扩展功能而能不影响其他服务 |
效率低 | 由于系统限制,导致生产性低下 |
加了网关之后:
如何选择微服务 API 网关:对比 Kong、APISIX、Tyk、Apigee 和其他网关: 主要说明了API网关的作用,以及API网关在选型上的注意点是什么
kong作为一款API网关的应用实现,其优点很明显:
发布者:全栈程序员栈长,转载请注明出处:https://javaforall.cn/153188.html原文链接:https://javaforall.cn