干货 | 两分钟教你上手api网关系统

Posted 2021-04-21 AI脑力波

随着互联网的快速发展，当前已步入移动互联、物联网时代。用户访问系统入口也变得多种方式，由原来单一的PC客户端，变化到PC客户端、各种浏览器、手机移动端及智能终端等。

同时系统之间大部分都不是单独运行，经常会涉及与其他系统对接、共享数据的需求。所以系统需要升级框架满足日新月异需求变化，支持业务发展，并将框架升级为微服务架构。

 “API网关”核心组件是满足上述需求的架构，定位为应用系统服务接口的网关，区别于网络技术的网关，但是原理则是一样。

API网关统一服务入口，可方便实现对平台众多服务接口进行管控，对访问服务的身份认证、防报文重放与防数据篡改、功能调用的业务鉴权、响应数据的脱敏、流量与并发控制，甚至基于API调用的计量或者计费等等。

二、组件介绍

Spring cloud zuul是基于java语言，是spring cloud标准组件，基于过滤器模式，通过开发扩展，能够很好的实现认证&鉴权、限流、动态路由，监控，弹性，安全、负载均衡等。

Spring cloud zuul filter架构（图二）

Zuul以过滤器来实现的，定义了四种标准过滤器类型：

PRE：这种过滤器在请求被路由之前调用。我们可利用这种过滤器实现身份验证、在集群中选择请求的微服务、记录调试信息等。

ROUTING：这种过滤器将请求路由到微服务。这种过滤器用于构建发送给微服务的请求，并使用ApacheHttpClient或Netfilx Ribbon请求微服务。

POST：这种过滤器在路由到微服务以后执行。这种过滤器可用来为响应添加标准的HTTPHeader、收集统计信息和指标、将响应从微服务发送给客户端等。

ERROR：在其他阶段发生错误时执行该过滤器。

三、实现方案

架构(图三)

 

1.      全链路的日志记录：

1)  在一个系统特别是公共网关系统是非常的重要，大大提供排查的效率和准确性；80%的问题都能通过网关日志分析定位，20%的问题通过基础系统分析定位。

2)  网关要实现不仅从入口到出库的日志记录，相应的filter也需要日志记录

3)  日志记录格式为：接口url+RequestId+手机号+终端+入参+出参

4)  错误详细信息不抛出到终端，但需记录与日志中

2.      黑名单：

1)  实现IP段的限制访问

2)  实现全局黑名单和接口黑名单

3)  针对攻击者IP自动设置为黑名单

4)  实现用户级别的限制访问，暂不实现

3.      终端授权：

1)  每一个终端都需要在网关系统中进行配置授权后才能访问

2)  网关后台为每个应用分配应用id(appkey唯一)和应用密钥(appSecret)

3)  接口与终端建立关系，只有终端授权的接口，才能被此终端访问

4.      签名：

1)  通过请求参数、时间搓、请求ID等通过appsecret密钥进行加密签名

2)  防止有人恶意篡改请求数据以达到恶意攻击的目的

3)  防止有人会不断恶意或欺诈性地重复一个有效的数据传输

5.      token校验：

Token主要用于身份认证，简单的说就是控制用户是否已经登录有效,Token按照各终端独立生成。

1.      实名校验：

1)  此校验模式，用于校验用户是否是认证授权，及实名认证

2)  判断方式为通过token获取用户信息，判断是否实名

3)  通过接口配置后，主要用于前端统一拦截，进行实名认证界面

2.      流量控制：

1)  API全局流量控制:用于API接口在单位时间内被调用的次数不能超过设定值，单位时间可选分钟、小时、天，如1000次/分钟

2)  API终端流量控制:用于终端调用API接口在单位时间内的调用次数不能超过设定值，如500次/分钟，不能大于全局流控

3)  终端全局流量控制:针对终端在单位时间内调用的次数

4)  用户或终端流量控制:针对单个用户在单位时间内调用的次数

3.      协议适配：

现有服务主要以HTTP和RPC(RemoteService)模式

HTTP模式：

zuul本身已经实现httpclient的调用

RPC模式：

结合公司的模式，目前都是通过封装的RemoteService模式，集成spring 的rpc方式进行调用。

4.      路由及封装：

1)  支持单个业务服务和多个业务服务的调用组装数据模式

2)  单个：一个请求接口，调用后端一个api业务服务进行处理

3)  多个：一个请求接口，调用后端多个api业务服务，并根据配置进行组装合并处理

4)  多个模式下支持同步和异步方式调用

5)  支持版本控制，通过X-Version路由不同的业务服务

 

四、效果

1.  网关层对外部和内部进行了隔离，保障了后台服务的安全性

2.  对外访问控制由网络层面转换成了运维层面，减少变更的流程和错误成本

3.  减少客户端与服务的耦合，服务可以独立发展。通过网关层来做映射

4.  通过网关层聚合，减少外部访问的频次，提升访问效率

5.  节约后端服务开发成本，减少上线风险

6.  为服务熔断、降级，灰度发布，线上测试提供简单方案

7.  简化了客户端开发复杂度，降低了客户端与服务端交互

8.  整体降低了硬件成本，提示了系统的效率和稳定性

9.  方便全链路的监控、日志的分析

10.便于扩展