各种企业级API网关的设计对比

最新推荐文章于 2024-08-26 11:16:33 发布

ronon77

最新推荐文章于 2024-08-26 11:16:33 发布

阅读量3k

点赞数 1

分类专栏： python&nodejs 文章标签： api kong

本文链接：https://blog.csdn.net/ronon77/article/details/84903436

版权

本文详细探讨了API网关的背景、作用和价值，重点比较了Nginx+Lua、SpringCloud Zuul和Mashape Kong在企业级API网关设计中的优缺点。API网关作为企业系统边界，起到隔离、解耦和安全管控作用。Nginx以其高性能和扩展性受到青睐，Zuul适合快速搭建，Kong提供丰富的商业插件。文章还讨论了API网关的性能、高可用、扩展性和管理设计，强调了功能考量和高可用设计的重要性。

摘要由CSDN通过智能技术生成

1.1 API网关背景介绍

API Gateway（APIGW / API 网关），顾名思义，是出现在系统边界上的一个面向API的、串行集中式的强管控服务，这里的边界是企业IT系统的边界，主要起到隔离外部访问与内部系统的作用。在微服务概念的流行之前，API网关的实体就已经诞生了，例如银行、证券等领域常见的前置机系统，它也是解决访问认证、报文转换、访问统计等问题的。

API网关的流行，源于近几年来，移动应用与企业间互联需求的兴起。移动应用、企业互联，使得后台服务支持的对象，从以前单一的Web应用，扩展到多种使用场景，且每种使用场景对后台服务的要求都不尽相同。这不仅增加了后台服务的响应量，还增加了后台服务的复杂性。随着微服务架构概念的提出，API网关成为了微服务架构的一个标配组件。

1.2 网关的几种使用场景

我司王延炯博士的文章《谈API网关的背景、架构以及落地方案》中，提到了网关的几种使用场景：

1、面向Web App的网关

这类场景，在物理形态上类似前后端分离，此时的Web App已经不是全功能的Web App，而是根据场景定制、场景化的App。

2、面向MobileApp的网关

这类场景，移动App是后端Service的使用者，此时的APIGW还需要承担一部分MDM（此处是指移动设备管理，不是主数据管理）的职能。

3、面向PartnerOpenAPI的网关

这类场景，主要为了满足业务形态对外开放，与企业外部合作伙伴建立生态圈，此时的API GW需要增加配额、流控、令牌等一系列安全管控功能。

4、面向PartnerExternalAPI的网关

这类场景，主要是为了满足企业自身业务的需要，实现对企业自有业务的映射。一个典型的例子就是使用「合作方账号登录」、「使用第三方支付平台支付」等等。此时的APIGW就需要在边界上，为企业内部Service 统一调用外部的API做统一的认证、授权、以及访问控制。

5、面向IoTSmartDevice的网关

这类场景主要在传统企业，尤其是工业企业，传感器、物理设备从工业控制协议向IP转换，导致物理链路上会存在一部分公网链路。此时的API GW所需要满足的「内外兼修」的双向数据流，设备一般通过一个「客户侧」的集中网关在和企业的接入网关进行通信。

在我们讲的微服务架构下的API网关，一般指的是前两种使用场景。即，主要是把企业内部的API能力，暴露给其他应用或合作伙伴使用。

二、网关的作用和价值

网关层作为客户端与服务端的一层挡板，主要起到了三大类作用：

第一类作用是隔离作用，作为企业系统边界，隔离外网系统与内网系统。

第二类作用是解耦作用，通过解耦，使得微服务系统的各方能够独立、自由、高效、灵活地调整，而不用担心给其他方面带来影响。

第三类作用是脚手架作用，提供了一个地点，方便通过扩展机制对请求进行一系列加工和处理。

2.1 内外的隔离

企业为了保护内部系统的安全性，内网与外网都是隔离的，企业的服务应用都是运行在内网环境中，为了安全的考量，一般都不允许外部直接访问。API网关部署在防火墙外面，起到一层挡板作用，内部系统只接受API网关转发过来的请求。网关通过白名单或校验规则，对访问进行了初步的过滤。相比防火墙，这种软件实现的过滤规则，更加动态灵活。

2.2 多方的解耦

在微服务架构下，整个环境包括服务的提供者、服务的消费者、服务运维人员、安全管理人员等，每个角色的职责和述求都不同。例如：服务消费者已经需要提出一些新的服务需求，以快速应对业务变化；服务提供者，作为业务服务的沉淀方，希望保持服务的通用性与稳定性，很难应对快速的变化。有了API网关这一层，可以很好的解耦各方的相互依赖关系，让各方更加专注自己的目标。

1、解耦功能与非功能

企业在把服务提供给外部访问时，除了实现业务逻辑功能外，还面临许多非功能性的要求。例如：需要防范黑客攻击，需要应对突发的访问量、需要确认用户的权限，需要对访问进行监控等。这些非功能逻辑，不能与业务逻辑的开发混在一起，需要有专业的人员甚至专业的团队来处理。

2、解耦客户端与服务提供者

客户端与服务提供者分属于不同的团队，工作性质要求也不相同。对于服务提供者来说，他主要的职责是对业务进行抽象，提供可复用的业务功能，他们需要对业务模型进行深入的思考和沉淀，不能轻易为了响应外部的需求而破坏业务模型的稳定性。而业务的快速变化，又要求企业快速提供接口来满足客户端需求。这就需要一个中间层，来对服务层的接口进行封装，以及时响应客户端的需求。

通过解耦，服务层可以使用统一的接口、协议和报文格式来暴露服务，而不必考虑客户端的多种形态。