2. API网关的职能
API网关的职能如图7-4所示。
图7-4
一般来说，API网关有四大职能。
-
请求接入：作为所有API接口服务请求的接入点，管理所有的接入请求。
-
业务聚合：作为所有后端业务服务的聚合点，所有的业务服务都可以在这里被调用。
-
中介策略：实现安全、验证、路由、过滤、流控、缓存等策略，进行一些必要的中介处理。
-
统一管理：提供配置管理工具，对所有API服务的调用生命周期和相应的中介策略进行统一管理。
3. API网关的关注点
API网关并不是一个典型的业务系统，而是一个为了让业务系统更专注于业务服务本身，给API服务提供更多附加能力的一个中间层。
在设计和实现API网关时，需要考虑两个目标：
（1）开发维护简单，节约人力成本和维护成本。即应选择成熟的简单可维护的技术体系。
（2）高性能，节约设备成本，提高系统吞吐能力。要求我们需要针对API网关的特点进行一些特定的设计和权衡。
当并发量小的时候，这些都不是问题。一旦系统的API访问量非常大，这些都会成为关键的问题。
海量并发的API网关最重要的三个关注点：
（1）保持大规模的inbound请求接入能力（长短连接），比如基于Netty实现。
（2）最大限度地复用outbound的HTTP连接能力，比如基于HttpClient4的异步HttpClient实现。
（3）方便灵活地实现安全、验证、过滤、聚合、限流、监控等各种策略。
API网关的分类与技术分析
1. API网关的分类
如果对上述的目标和关注点进行更深入的思考，那么所有需要考虑的问题和功能可以分为两类。
- 一类是全局性的，跟具体的后端业务系统和服务完全无关的部分，比如安全策略、全局性流控策略、流量分发策略等。
-
一类是针对具体的后端业务系统，或者是服务和业务有一定关联性的部分，并且一般被直接部署在业务服务的前面。
随着互联网的复杂业务系统的发展，这两类功能集合逐渐形成了现在常见的两种网关系统：流量网关和业务网关，如图7-5所示。
图7-5
2. 流量网关与WAF
我们定义全局性的、跟具体的后端业务系统和服务完全无关的策略网关，即为流量网关。这样流量网关关注全局流量的稳定与安全，比如防止各类SQL注入、黑白名单控制、接入请求到业务系统的负载均衡等，通常有如下通用性的具体功能：
-
全局性流控；
-
日志统计；
-
防止SQL注入；
-
防止Web攻击；
-
屏蔽工具扫描；
-
黑白名单控制。
通过这个功能清单，我们可以发现，流量网关的功能跟Web应用防火墙（WAF）非常类似。WAF一般是基于Nginx/OpenResty的ngx_lua模块开发的Web应用防火墙。
一般WAF的代码很简单，专注于使用简单、高性能和轻量级。简单地说就是在Nginx本身的代理能力以外，添加了安全相关功能。用一句话描述其原理，就是解析HTTP请求（协议解析模块），规则检测（规则模块），做不同的防御动作（动作模块），并将防御过程（日志模块）记录下来。
一般的WAF具有如下功能：
-
防止SQL注入、部分溢出、fuzzing测试、XSS/SSRF等Web攻击；
-
防止Apache Bench之类压力测试工具的攻击；
-
屏蔽常见的扫描黑客工具，比如扫描器；
-
禁止图片附件类目录执行权限、防止webshell上传；
-
支持IP白名单和黑名单功能，直接拒绝黑名单的IP访问；
-
支持URL白名单，定义不需要过滤的URL；
-
支持User-Agent的过滤、支持CC攻击防护、限制单个URL指定时间的访问次数；
-
支持支持Cookie过滤，URL与URL参数过滤；
-
支持日志记录，将所有拒绝的操作记录到日志中。
以上WAF的内容主要参考如下两个项目：
流量网关的开源实例还可以参考著名的开源项目Kong（基于OpenResty）。
3. 业务网关
我们定义针对具体的后端业务系统，或者是服务和业务有一定关联性的策略网关，即为业务网关。比如，针对某个系统、某个服务或某个用户分类的流控策略，针对某一类服务的缓存策略，针对某个具体系统的权限验证方式，针对某些用户条件判断的请求过滤，针对具体几个相关API的数据聚合封装，等等。
业务网关一般部署在流量网关之后、业务系统之前，比流量网关更靠近业务系统。我们大部分情况下说的API网关，狭义上指的是业务网关。如果系统的规模不大，我们也会将两者合二为一，使用一个网关来处理所有的工作。
开源网关的分析与调研
常见的开源网关介绍
常见的开源网关如图7-6所示。
图7-6