作(zuò)者：佚名(míng) 来源：DockOne
微服務(wù)架构是当下比较流行的一种架构风格，它是一种以业務(wù)功能(néng)组织的服務(wù)集合，可(kě)以持续交付、快速部署、更好的可(kě)扩展性和容错能(néng)力，而且还使组织更容易去尝试新(xīn)技(jì )术栈。微服務(wù)具(jù)有(yǒu)几个关键特征：
高度可(kě)维护和可(kě)测试性
与其他(tā)服務(wù)松散耦合
且可(kě)独立部署
能(néng)够由一个小(xiǎo)团队开发
现在很(hěn)多(duō)公(gōng)司企业想将自己的单體(tǐ)应用(yòng)架构迁移到微服務(wù)架构，在这个问题上，Martin Fowler提出了3个前提，而Phil Calcado对其进行了扩展如下：
快速配置计算资源
基本监控
快速部署
易于配置存储
易于访问网关
认证、授权
标准化的 RPC
今天我们主要讲讲易于访问的网关，也就是 API 网关。
為(wèi)什么需要 API 网关
假设我们要使用(yòng)微服務(wù)架构构建一个電(diàn)商(shāng)平台，以下可(kě)能(néng)是一些潜在的服務(wù)：
購(gòu)物(wù)車(chē)服務(wù)
订单服務(wù)
商(shāng)品服務(wù)
评论服務(wù)
库存服務(wù)
等等，客户端应该怎么访问这些服務(wù)呢(ne)?原来单體(tǐ)应用(yòng)的情况我们都知道，都在一个服務(wù)器上部署，直接访问IP+端口+服務(wù)前缀即可(kě)，现在微服務(wù)架构下，每个服務(wù)都可(kě)以独立部署，并且是由不同的开发团队开发的，难道我们要这样访问吗?
理(lǐ)论上每个服務(wù)都有(yǒu)端点可(kě)以访问，但是客户端就需要记录所有(yǒu)服務(wù)的端点，发起5次请求，现在还是5个服務(wù)，如果之后扩展多(duō)了呢(ne)?对客户端来说就是一个灾难，随之带来的就是安(ān)全性问题、扩展性问题等，所以这种客户端直接与每个服務(wù)交互是不可(kě)取的，通常，更好的方式是使用(yòng) API 网关。
API 网关是客户端访问服務(wù)的统一入口，API 网关封装(zhuāng)了后端服務(wù)，还提供了一些更高级的功能(néng)，例如：身份验证、监控、负载均衡、缓存、多(duō)协议支持、限流、熔断等等，API 网关还可(kě)以针对不同的客户端定制不同粒度的 API，上面例子中(zhōng)修改架构后如下：
API 网关的优缺点
API 网关的好处是显而易见的，封装(zhuāng)了应用(yòng)程序的内部结构，為(wèi)不同客户端提供不同粒度的 API，同时网关自身也提供了一些高级功能(néng)，也减少了客户端与应用(yòng)程序之间的往返次数，使客户端代码更优雅。
同时使用(yòng)网关也存在一些缺点，增加了一个新(xīn)的组件，增加了整个应用(yòng)架构的复杂度，一个通俗的道理(lǐ)，你做的越多(duō)你犯错的风险也越高，网关不可(kě)用(yòng)很(hěn)可(kě)能(néng)导致整个应用(yòng)架构崩溃，当然现在有(yǒu)各种各样的方案，能(néng)防止网关崩溃，它也可(kě)能(néng)存在瓶颈风险。
使用(yòng)网关有(yǒu)利有(yǒu)弊，我个人而言，利肯定是大于弊的，我们尽可(kě)能(néng)的将弊端降到最低。
API 网关一些实现
使用(yòng)一个组件时，尤其是这种比较流行的架构，组件肯定存在开源的，我们不必自己去从零开始去实现一个网关，自己开发一个网关的工(gōng)作(zuò)量是相当可(kě)观的，现在比较流行的开源 API 网关如下所示：
Kong
Kong是一个在 Nginx 中(zhōng)运行的Lua应用(yòng)程序，并且可(kě)以通过lua-nginx模块实现，Kong不是用(yòng)这个模块编译Nginx，而是与 OpenResty 一起发布，OpenResty已经包含了 lua-nginx-module， OpenResty 不是 Nginx 的分(fēn)支，而是一组扩展其功能(néng)的模块。
它的核心是实现数据库抽象，路由和插件管理(lǐ)，插件可(kě)以存在于单独的代码库中(zhōng)，并且可(kě)以在几行代码中(zhōng)注入到请求生命周期的任何位置。
Traefik
Traefik 是一个现代 HTTP 反向代理(lǐ)和负载均衡器，可(kě)以轻松部署微服務(wù)，Traeffik 可(kě)以与您现有(yǒu)的组件(Docker、Swarm，Kubernetes，Marathon，Consul，Etcd，…)集成，并自动动态配置。
Ambassador
Ambassador 是一个开源的微服務(wù) API 网关，建立在 Envoy 代理(lǐ)之上，為(wèi)用(yòng)户的多(duō)个团队快速发布，监控和更新(xīn)提供支持，支持处理(lǐ) Kubernetes ingress controller 和负载均衡等功能(néng)，可(kě)以与 Istio 无缝集成。
Tyk
Tyk是一个开源的、轻量级的、快速可(kě)伸缩的 API 网关，支持配额和速度限制，支持认证和数据分(fēn)析，支持多(duō)用(yòng)户多(duō)组织，提供全 RESTful API。基于 go 编写。
Zuul
Zuul 是一种提供动态路由、监视、弹性、安(ān)全性等功能(néng)的边缘服務(wù)。Zuul 是 Netflix 出品的一个基于 JVM 路由和服務(wù)端的负载均衡器。
API 网关实现对比
总结
由上述对比表格中(zhōng)可(kě)以看出：从开源社區(qū)活跃度来看，无疑是Kong和Traefik较好；从成熟度来看，较好的是Kong、Tyk、Traefik；从性能(néng)角度来看，Kong要比其他(tā)几个领先一些；从架构优势的扩展性来看，Kong、Tyk有(yǒu)丰富的插件，Ambassador也有(yǒu)插件但不多(duō)，而Zuul是完全需要自研，但Zuul由于与Spring Cloud深度集成，使用(yòng)度也很(hěn)高，近年来Istio服務(wù)网格的流行，Ambassador因為(wèi)能(néng)够和Istio无缝集成也是相当大的优势。
具(jù)體(tǐ)使用(yòng)选择还是需要依据具(jù)體(tǐ)的业務(wù)场景，我们在参考链接中(zhōng)收集了一些性能(néng)对比，大家可(kě)以做下参考。
声明：本网站发布的内容（图片、视频和文(wén)字）以原创、转载和分(fēn)享网络内容為(wèi)主，如果涉及侵权请尽快告知，我们将会在第一时间删除。文(wén)章观点不代表本网站立场，如需处理(lǐ)请联系客服，電(diàn)话：0755-22671324。