微服务架构是当下比较流行的一种架构风格,它是一种以业务功能组织的服务集合,可以持续交付、快速部署、更好的可扩展性和容错能力,而且还使组织更容易去尝试新技术栈。微服务具有几个关键特征:
- 高度可维护和可测试性
- 与其他服务松散耦合
- 且可独立部署
- 能够由一个小团队开发
现在很多公司企业想将自己的单体应用架构迁移到微服务架构,在这个问题上,Martin Fowler提出了3个前提,而Phil Calcado对其进行了扩展如下:
- 快速配置计算资源
- 基本监控
- 快速部署
- 易于配置存储
- 易于访问网关
- 认证、授权
- 标准化的 RPC
今天我们主要讲讲易于访问的网关,也就是 API 网关。
为什么需要 API 网关
假设我们要使用微服务架构构建一个电商平台,以下可能是一些潜在的服务:
- 购物车服务
- 订单服务
- 商品服务
- 评论服务
- 库存服务
等等,客户端应该怎么访问这些服务呢?原来单体应用的情况我们都知道,都在一个服务器上部署,直接访问IP+端口+服务前缀即可,现在微服务架构下,每个服务都可以独立部署,并且是由不同的开发团队开发的,难道我们要这样访问吗?
理论上每个服务都有端点可以访问,但是客户端就需要记录所有服务的端点,发起5次请求,现在还是5个服务,如果之后扩展多了呢?对客户端来说就是一个灾难,随之带来的就是安全性问题、扩展性问题等,所以这种客户端直接与每个服务交互是不可取的,通常,更好的方式是使用 API 网关。
API 网关是客户端访问服务的统一入口,API 网关封装了后端服务,还提供了一些更高级的功能,例如:身份验证、监控、负载均衡、缓存、多协议支持、限流、熔断等等,API 网关还可以针对不同的客户端定制不同粒度的 API,上面例子中修改架构后如下:
API 网关的优缺点
API 网关的好处是显而易见的,封装了应用程序的内部结构,为不同客户端提供不同粒度的 API,同时网关自身也提供了一些高级功能,也减少了客户端与应用程序之间的往返次数,使客户端代码更优雅。
同时使用网关也存在一些缺点,增加了一个新的组件,增加了整个应用架构的复杂度,一个通俗的道理,你做的越多你犯错的风险也越高,网关不可用很可能导致整个应用架构崩溃,当然现在有各种各样的方案,能防止网关崩溃,它也可能存在瓶颈风险。
使用网关有利有弊,我个人而言,利肯定是大于弊的,我们尽可能的将弊端降到最低。
API 网关一些实现
使用一个组件时,尤其是这种比较流行的架构,组件肯定存在开源的,我们不必自己去从零开始去实现一个网关,自己开发一个网关的工作量是相当可观的,现在比较流行的开源 API 网关如下所示:
Kong
Kong是一个在 Nginx 中运行的Lua应用程序,并且可以通过lua-nginx模块实现,Kong不是用这个模块编译Nginx,而是与 OpenResty 一起发布,OpenResty已经包含了 lua-nginx-module, OpenResty 不是 Nginx 的分支,而是一组扩展其功能的模块。
它的核心是实现数据库抽象,路由和插件管理,插件可以存在于单独的代码库中,并且可以在几行代码中注入到请求生命周期的任何位置。
Traefik
Traefik 是一个现代 HTTP 反向代理和负载均衡器,可以轻松部署微服务,Traeffik 可以与您现有的组件(Docker、Swarm,Kubernetes,Marathon,Consul,Etcd,…)集成,并自动动态配置。
Ambassador
Ambassador 是一个开源的微服务 API 网关,建立在 Envoy 代理之上,为用户的多个团队快速发布,监控和更新提供支持,支持处理 Kubernetes ingress controller 和负载均衡等功能,可以与 Istio 无缝集成。
Tyk
Tyk是一个开源的、轻量级的、快速可伸缩的 API 网关,支持配额和速度限制,支持认证和数据分析,支持多用户多组织,提供全 RESTful API。基于 go 编写。
Zuul
Zuul 是一种提供动态路由、监视、弹性、安全性等功能的边缘服务。Zuul 是 Netflix 出品的一个基于 JVM 路由和服务端的负载均衡器。
API 网关实现对比
| 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 |
总结
由上述对比表格中可以看出:从开源社区活跃度来看,无疑是Kong和Traefik较好;从成熟度来看,较好的是Kong、Tyk、Traefik;从性能角度来看,Kong要比其他几个领先一些;从架构优势的扩展性来看,Kong、Tyk有丰富的插件,Ambassador也有插件但不多,而Zuul是完全需要自研,但Zuul由于与Spring Cloud深度集成,使用度也很高,近年来Istio服务网格的流行,Ambassador因为能够和Istio无缝集成也是相当大的优势。
具体使用选择还是需要依据具体的业务场景,我们在参考链接中收集了一些性能对比,大家可以做下参考。
参考链接
- https://www.bbva.com/en/api-gateways-kong-vs-tyk/ kong vs tyk
- https://stackshare.io/stackups/kong-vs-traefik kong vs traefik
- https://blog.getambassador.io/envoy-vs-nginx-vs-haproxy-why-the-open-source-ambassador-api-gateway-chose-envoy-23826aed79ef envoy vs nginx
- https://engineering.opsgenie.com/comparing-api-gateway-performances-nginx-vs-zuul-vs-spring-cloud-gateway-vs-linkerd-b2cc59c65369 nginx vs zuul