得物自研API网关最佳实践

分享内容

一、业务背景

二、技术痛点

三、方案调研

四、自研架构

五、核心设计

六、投产收益

七、思考总结

​

一、业务背景

老网关使用 Spring Cloud Gateway （下称 SCG）技术框架搭建，SCG 基于 webflux 编程范式，webflux 是一种响应式编程理念，响应式编程对于提升系统吞吐率和性能有很大帮助; webflux 的底层构建在 netty 之上性能表现优秀；SCG 属于 spring 生态的产物，具备开箱即用的特点，以较低的使用成本助力得物早期的业务快速发展；但是随着公司业务的快速发展，流量越来越大，网关迭代的业务逻辑越来越多，以及安全审计需求的不断升级和稳定性需求的提高，SCG 在以下几个方面逐步暴露了一系列的问题。

网络安全

从网络安全角度来讲，对公网暴露接口无疑是一件风险极高的事情，网关是对外网络流量的重要桥梁，早期的接口暴露采用泛化路由的模式，即通过正则形式（ /api/v1/app/order/** ）的路由规则开放接口，单个应用服务往往只配置一个泛化路由，后续上线新接口时外部可以直接访问；这带来了极大的安全风险，很多时候业务开发的接口可能仅仅是内部调用，但是一不小心就被泛化路由开放到了公网，甚至很多时候没人讲得清楚某个服务具体有多少接口属于对外，多少对内；另一方面从监控数据来看，黑产势力也在不断对我们的接口做渗透试探。

协同效率

引入了接口注册机制，所有对外暴露接口逐一注册到网关，未注册接口不可访问，安全的问题得到了解决但同时带来了性能问题，SCG 采用遍历方式匹配路由规则，接口注册模式推广后路由接口注册数量迅速提升到 3W+，路由匹配性能出现严重问题；泛化路由的时代，一个服务只有一个路由配置，变动频率很低，配置工作由网关关开发人员负责，效率尚可，接口注册模式将路由工作转移到了业务开发同学的身上，这就得引入一套完整的路由审核流程，以提升协同效率；由于路由信息早期都存在配置中心，同时这么大的数据量给配置中心也带来极大的压力和稳定性风险。

性能与维护成本

业务迭代的不断增多，也使得 API 网关堆积了很多的业务逻辑，这些业务逻辑分散在不同的 filter 中，为了降低开发成本，网关只有一套主线分支，不同集群部署的代码完全相同，但是不同集群的业务属性不同，所需要的 filter 逻辑是不一样的；如内网网关集群几乎没什么业务逻辑，但是 App 集群可能需要几十个 filter 的逻辑协同工作；这样的一套代码对内网网关而言，存在着大量的性能浪费；如何平衡维护成本和运行效率是个需要思考的问题。

稳定性风险

API 网关作为基础服务，承载全站的流量出入，稳定性无疑是第一优先级，但其定位决定了绝不可能是一个简单的代理层，在稳定运行的同时依然需要承接大量业务需求，例如 C 端用户登录下线能力，App 强升能力，B 端场景下的鉴权能力等；很难想象较长一段时间以来，网关都保持着双周一次的发版频率；频繁的发版也带来了一些问题，实例启动初期有很多资源需要初始化，此时承接的流量处理时间较长，存在着明显的接口超时现象；早期的每次发版几乎都会导致下游服务的接口短时间内超时率大幅提高，而且往往涉及多个服务一起出现类似情况；为此甚至拉了一个网关发版公告群，提前置顶发版公告，让业务同学和 NOC 有一个心里预期；在发布升级期间尽可能让业务服务无感知这是个刚需。