如何架构一个合适的企业API网关

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

image.png

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

一：网关的几种使用场景

1、面向WebApp

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

2、面向MobileApp

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

3、面向PartnerOpenAPI

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

4、面向PartnerExternalAPI

这类场景，业界提的比较少，很多时候系统的建设，都是为了满足企业自身业务的需要，实现对企业自有业务的映射。当互联网形态逐渐影响传统企业时，很多系统都会为了导入流量或者内容，依赖外部合作伙伴的能力，一些典型的例子就是使用「合作方账号登录」、「使用第三方支付平台支付」等等，这些对于企业内部来说，都是一些外部能力。此时的APIGW就需要在边界上，为企业内部Service统一调用外部的API做统一的认证、（多租户形式的）授权、以及访问控制。

在我们讲的微服务架构下的API网关，一般指的是前三类使用场景。即，主要是把企业内部的API能力，暴露给其他应用或合作伙伴使用。网关层作为客户端与服务端的一层挡板，主要起到了三大类作用：

• 第一类作用是隔离作用，作为企业系统边界，隔离外网系统与内网系统。
• 第二类作用是解耦作用，通过解耦，使得微服务系统的各方能够独立、自由、高效、灵活地调整，而不用担心给其他方面带来影响。
• 第三类作用是脚手架作用，提供了一个地点，方便通过扩展机制对请求进行一系列加工和处理。

二：网关的好处

（1）网关层对外部和内部进行了隔离，保障了后台服务的安全性。
（2）对外访问控制由网络层面转换成了运维层面，减少变更的流程和错误成本
（3）减少客户端与服务的耦合，服务可以独立发展。通过网关层来做映射。
（4）通过网关层聚合，减少外部访问的频次，提升访问效率。
（5）节约后端服务开发成本，减少上线风险。
（6）为服务熔断，灰度发布，线上测试提供简单方案。
（7）便于扩展。

三：API网关需要考虑的因素

1、安全性问题

企业在把服务暴露给外部使用时，首先要确保服务使用的安全，防止外部的恶意访问对公司业务的影响，特别是涉及交易方面的服务，更是要全面考虑安全性。为确保安全，需要考虑在通讯链路的建立、通讯数据的加密、数据的完整性、不可抵赖性等方面。

2、性能问题

作为企业API的入口，所有的请求都会经过API网关进行转发，可想而知，对API网关的访问压力是巨大的，有的网站甚至达到每分钟上千万的访问量。特别是在一些互联网企业，海量的移动终端每时每刻都需要与后端的服务进行交互，如果不能保证网关的高性能，企业在网关层需要投入大量的设备和成本。曾在一家互联网公司发生过，由于网关性能问题，网关的机器数量，需要与后台服务器的数量保持同步增长。这种情况显然是企业服务忍受的。

3、高可用问题

API网关作为逻辑上的单点，一旦发生问题，将造成企业服务的不可用，对企业来说可能造成的致命的影响。计算短时间的不可用，也会给企业带来直接的经济损失。所以，如何保证API网关的7*24小时的稳定运行，网关的自动伸缩、API的热更新等问题，都是企业级的网关需要考虑的。

4、扩展性问题

前面说到，企业网关提供了一个脚手架，一些非功能性的问题，例如日志、安全、负载均衡策略、鉴权等。这些插件会随着企业业务规模等的变化进行不断的强化与调整。这就需要网关层提供这样一种机制，使得可以灵活地进行这些调整和变化，而不用频繁对网关层进行改动，确保网关层的稳定性。

5、API高效运维的问题

API在上线、发布过程中，都需要涉及到网关层的配合，例如，需要网关层知道API发布的地址，API的接口形式、报文格式，也需要网关层对后台API进行封装。在API调整后，需要作出相应的修改。所以，API网关设计时，需要明确网关层与服务层的职责切分与协作模式，使得API的管理、发布更加高效。

6、API全生命周期的管理

API服务的全生命周期，包括服务的开发、测试、上线发布；服务使用的申请、开通；服务分类分级别的管理、服务使用情况的监控、计费等等。
一个企业可能会暴露成百上千个API，日常也会经常进行API的发布、升级、改造、下架等操作。对不同的服务，不同的访问者，需要提供不同的服务访问策略。有的商业API公司，还需要对API的使用进行付费。所以，与API网关配套的，需要一套完善的自助系统，提供给服务的提供者、管理者、使用者，来对服务的发布、使用、和运营。

四：业界常用的API网关方案

1：Nginx+Lua

基本功能：
（1）静态web资源服务器，能够缓存打开的文件描述符
（2）支持http/imap/pop3/smtp的反向代理；支持缓存、负载均衡
（3）支持fastcgi(fpm)
（4）模块化，非DSO机制，支持过滤器zip压缩，SSI以及图像大小调整
（5）支持SSL

Nginx的扩展功能：
（1）基于名称和IP的虚拟主机
（2）支持keepalive的保持机制
（3）支持平滑升级
（4）定制访问日志，支持使用日志缓存区提高日志存储性能
（5）支持urlrewrite
（6）支持路径别名（root或alias指定）
（7）支持基于IP以及用户的访问控制
（8）支持传输速率限制，并发限制

性能和高可用性上：
Nginx性能极高，Nginx先天的事件驱动型设计、全异步的网络I/O处理机制、极少的进程间切换以及许多优化设计，都使得Nginx天生善于处理高并发压力下的互联网请求。Nginx的稳定性也在各大网站得到验证。官方提供的常用模块都非常稳定，每个worker进程相对独立，master进程在1个worker进程出错时可以快速“拉起”新的worker子进程提供服务。支持热部署，可以不停机更新配置文件、更新日志文件、更新服务器程序版本。

扩展性上：
Nginx的设计极具扩展性，它完全是由多个不同功能、不同层次、不同类型且耦合度极低的模块组成。因此，当对某一个模块修复Bug或进行升级时，可以专注于模块自身，无须在意其他

易用性上：
Nginx使用最自由的BSD许可协议，允许用户在自己的项目中直接使用或修改Nginx源码，有大量的插件可以利用。但是，Nginx模块需要用C开发，而且必须符合一系列复杂的规则。虽然通过第三方模块，可以支持Nginx与Perl、Lua等脚本语言集成工作，但对使用者的要求还是很高。

2：SpringCloudZuul

基本功能

• 验证与安全保障:识别面向各类资源的验证要求并拒绝那些与要求不符的请求。
• 审查与监控:在边缘位置追踪有意义数据及统计结果，从而为我们带来准确的生产状态结论。
• 动态路由:以动态方式根据需要将请求路由至不同后端集群处。
• 压力测试:逐渐增加指向集群的负载流量，从而计算性能水平。
• 负载分配:为每一种负载类型分配对应容量，并弃用超出限定值的请求。
• 静态响应处理:在边缘位置直接建立部分响应，从而避免其流入内部集群。
• Netflix公司还利用Zuul的功能通过金丝雀版本实现精确路由与压力测试。
  虽然提供的功能还算丰富，但都比较弱，很难满足高要求的场景。

性能和高可用性:
Zuul处理每个请求的方式是针对每个请求是用一个线程来处理。通常情况下，为了提高性能，所有请求会被放到处理队列中，从线程池中选取空闲线程来处理该请求。2016年底，Netflix将它们的网关服务Zuul进行了升级，全新的Zuul2将HTTP请求的处理方式从同步变成了异步，以提升其处理性能。除了Netflix公司，目前Zuul在企业中用的还比较少，性能和稳定性方面还有待进一步观察。

扩展性上
从Zuul的架构图上可以看出，Zuul更像是一个过滤器框架，其自身的路由、日志、反向代理、ddos预防等功能都是通过过滤器实现的。提供了PRE、ROUTING、POST和ERROR四个扩展点，可以很容易的添加自定义的过滤器。

易用性上
Zuul的搭建非常简便，使用和配置也很简单。Zuul的开源社区比较活跃，一直在更新状态，但版本不算太稳定，在使用的过程中，还有一些坑要踩。例如重定向问题、异常处理问题，还没有解决的很好，需要自己重写一些filter。

3.MashapeKong

image.png

Kong的一个非常诱人的地方就是提供了大量的插件来扩展应用，通过设置不同的插件可以为服务提供各种增强的功能。Kong默认插件插件包括：

• 身份认证：Kong提供了BasicAuthentication、Keyauthentication、OAuth2.0authentication、HMACauthentication、JWT、LDAPauthentication认证实现。
• 安全：ACL（访问控制）、CORS（跨域资源共享）、动态SSL、IP限制、爬虫检测实现。
• 流量控制：请求限流（基于请求计数限流）、上游响应限流（根据upstream响应计数限流）、请求大小限制。限流支持本地、Redis和集群限流模式。
• 分析监控：Galileo（记录请求和响应数据，实现API分析）、Datadog（记录APIMetric如请求次数、请求大小、响应状态和延迟，可视化APIMetric）、Runscope（记录请求和响应数据，实现API性能测试和监控）。
• 转换：请求转换、响应转换

Kong本身也是基于Nginx的，所以在性能和稳定性上都没有问题。Kong作为一款商业软件，在Nginx上做了很扩展工作，而且还有很多付费的商业插件。Kong本身也有付费的企业版，其中包括技术支持、使用培训服务以及API分析插件。

从对上面三种方案的比较中可以看到，SpringCloudZuul非常适合创业初期的团队，快速搭建一个“基本可用”的API网关。Nginx适合有较强研发团队，自主开发企业自己的API网关。Kong适合于没有自身研发团队，但需要拥有企业级API网关能力的公司。

五：如何设计一个好的企业级API网关产品

1：功能需求

• API生命周期管理功能：
  覆盖API的定义、测试、发布的整个生命周期管理，便捷的日常管理、版本管理，支持热升级和快速回滚
• 开发和使用支持功能：
  提供页面调试工具，自动生成API文档和SDK，大大降低人力成本。
• 安全防护功能：
  API请求到达网关需要经过严格的身份认证、权限认证，才能到达后端服务。支持算法签名，支持SSL加密。
• 流量控制功能：
  可控制单位时间内API允许被调用次数。用来保护企业的后端服务，实现业务分级和用户分级。支持对API流控，您可以根据API的重要程度来配置不同流控，从而保障重要业务的稳定运行；支持用户、应用和例外流控，您可以根据用户的重要性来配置不同流控，从而可以保证大用户的权益；流控粒度：分钟、小时、天。
• 请求管理功能：
  可根据配置进行参数类型、参数值（范围、枚举、正则、JsonSchema）的校验，减少后端对非法请求、无效请求的资源消耗和处理成本。可以在API网关定义参数映射规则，网关通过映射规则将后端服务通过映射翻译成任何形式，以满足不同用户的不同需求，从而避免功能重复开发。
• 监控告警功能：
  提供实时、可视化的API监控，包括：调用量、调用方式、响应时间、错误率，让您能够清楚的了解API的运行状况和用户的行为习惯。
  支持自定义报警规则，来针对异常情况进行报警，降低故障处理时间。
  提供可订阅的数据分析报表和智能分析。

2：高性能设计

传统的基于线程的并发模型（Thread-basedconcurrency），为每一个请求分配一个线程或进程。这种模型编程简单，可以将处理一个完整请求的代码编写在一个代码路径中。这种模型的弊端是，随着线程(进程)数的上升，操作系统在这些线程(进程)之间的频繁切换，将急剧降低系统的性能。

3：高可用设计

• 无状态设计原则。
  网关层为保证高可以，易于伸缩，快速启动，需要设计成无状态的。用户的状态数据我们通常使用session对象来封装，网关层要设计成无状态的，也就是说，不能由网关来负责session的维护。那由谁来维护session相关的信息呢？我们是采用cookie+session服务器的方式;
  • a)用户在登录页完成登录操作后，服务器会生成一个登录session信息，保存起来，设置个失效时间，并设置到用户的cookie里
  • b)用户后续的每次请求里会带着这个cookie信息，服务端会对这个cookie信息进行校验，通过了就认为是合法用户，执行请求操作
• 优雅下线原则
  当需要撤掉一台网关服务的时候，不是直接结束网关进程，而是先关闭监听套接字，但是继续为当前连接的客户提供服务，所有客户端的服务完成后，在把进程关闭。
• Slowstart特性
  当网关监听到有一台新的服务注册上来时，考虑到有些服务启动后，刚开始会有许多初始化的工作，此时服务对请求的响应速度是比较慢的。如果一开始就给这台服务分配太多的压力，有可能导致服务瞬间被压垮。为了避免这种情况，网关层需要考虑支持SlowStart特性。即，经过一段时间，逐渐把压力增加到预设的值。
• 扩展性设计
  我们知道，网关对请求的处理，可以分为三个阶段：接受请求、路由并转发请求、接受服务的返回数据并返回给请求者，除此之外，还有一种情况是处理错误。所以我们也可以在这四个地方添加扩展点。
  • （1）接受到请求后
  • （2）定位到一个服务，并准备转发之前
  • （3）接受到服务的返回数据，返回给客户端之前
  • （4）当服务调用失败后
    拦截器的处理顺序，可以分为两大类：一类为网关平台自带的拦截器，例如安全校验、日志记录等；一类为网关层逻辑开发的，例如格式转换等。一般来说，网关先执行网关平台自带的拦截器，再执行为了业务逻辑编写的拦截器。当然，网关也需要提供一种机制，可以较容易地调整拦截器的执行顺序。最简单的一种方法，就是给每个拦截器定义一个优先级，网关按优先级顺序依次调用各拦截器。
    对网关层来说，它接收和处理的数据都是Request对象，网关层在接收到请求后，把请求封装为Request对象，为了让后续的filter能够获得这个对象，可以考虑把Request对象保存在线程变量中。
    有些拦截器，例如一些调试日志的拦截器，通常情况下都是关闭的，只有在出现问题的时候才需要打开。为了保证网关的高可用，网关层必须具备在线启用或关闭拦截器的能力。一般，网关需要提供restful接口方式，来关闭和启用一个拦截器。类似这样的命令：PUT/apigateway/v1/filters/filterName?enable=value
• 5）API管理与动态发布设计
  对服务管理来说，分为前端服务管理与后端服务管理。前端服务指的是网关层暴露给客户端使用的服务API，后端服务指的是服务层提供的业务服务API。一个服务暴露给客户端使用，除了网关层和服务层提供服务的代码外，还需要配置前端服务与后端服务的映射关系。
  网关层API调用服务层API，有多种方式。例如，可以由按照服务层API的服务契约，生成一段客户端代码，发布给网关层使用。这种方式的弊端是，网关层代码依赖于服务层代码，服务层频繁修改和调整接口时，导致网关层的代码很难维护。
  可以通过配置前后端服务映射的方式，解耦网关层对服务层的依赖。当服务层的API（例如服务名、参数名等）发生变化时，只需调整映射关系，无需对网关层的代码进行调整。网关层按照映射，自动装配服务层API所需要的数据格式。这样，网关层团队与服务层团队可以相互不受干扰地开发各自的服务。
  总结：API网关作为企业能力开放的一个门户，除了具备基本的请求转发、协议转换、路由等功能，以及高性能和高稳定性外，还需具备良好的扩展性，已便于网关能力的不断增强。在网关实施过程中，要规划好网关层与服务层的交互方式，尽量使得网关层与服务层解耦，便于各个团队工作的独立性。

转自普元云。