作者：庄文弘（弘智）

淘宝开放平台是阿里与外部生态互联互通的重要开放途径，通过开放的产品技术把阿里经济体一系列基础服务，像水、电、煤一样输送给我们的商家、开发者、社区媒体以及其他合作伙伴，推动行业的定制、创新、进化, 并最终促成新商业文明生态圈。

开放网关诞生于 07 年，到现在已经有 15 年的历史，流量从日两千万到到现在几百亿，支撑的业务也从淘系扩展到集团内多 BU。随着流量上涨，网关的技术架构也在持续升级迭代，以支撑更大的流量和更广的业务。本文把网关近些年来的技术架构变迁做梳理和总结，回顾下网关的发展过程。

一、系统架构

先简单浏览下网关整体的技术架构。网关的主要职责在于访问控制，有权限控制、流量控制、映射打点等基础能力，外通讯协议主要为 http 协议，而服务协议支持 HSF、http 等。

二、从线程池隔离到全异步化与多集群

作为一个业务网关，不可避免会遇到 API 质量参差不齐的情况，高 RT 的 API 会占用较多的线程资源。为减少 API 调用占用线程导的互相影响，最早网关使用了线程池分组的方式来维护，但线程池分组也带来了问题：

1. 线程池分组维护成本较高。

2. 分组内的 api 之间依旧会互相影响，而 api 抖动是个高概率的事件，当分组较大时候互相影响现象更明显。

为此，网关做了全异步化的升级改造。全异步化包括两部分：

1. 容器层异步化：避免了容器在业务处理过程处理线程一直被占用的情况，提升容器的线程利用率。

2. 请求后端异步化：通过 HSF 请求后端异步化调用方式，提升 HSF 线程池利用率，避免出现 HSF 线程池打满的情况。

通过升级改造，释放网络等待引起的线程占用，线程数不再成为网关的瓶颈。彻底隔离 API 请求之间的影响，慢 API 不会引起网关的不稳定。

另外网关也在业务上整体对流量做了划分，把流量区分为不稳定的流量（可能带来安全风险）、重保业务流量以及公共流量，根据不同的流量类型划分了不同的业务集群。

三、元数据多级缓存演变

网关请求流量一个特点是元数据较少变更，流量却非常大。为此，网关的缓存设计成多级缓存模式，布隆过滤器过滤非法请求，接着经过本地缓存与 Tair 缓存，最后访问到 DB 的流量已非常少了。

3.1 Appkey 元数据存储去布隆过滤器

随着业务发展，Appkey 数据量快速上涨，目前的哈希算法构建 appkey bloomfilter 占用 60M 内存，在序列化时瞬间内存 byte copy 会有 100M 左右，经常引起 fgc 导致业务抖动，这个对服务端和客户端都是埋雷。另外富客户端在拉到 bloomfilter 完成一系列构建过程中如果有异常，会直接忽略 bloomfilter；这也导致前端时间用增依赖 TOP 去中心化包构建 bloomfilter 失败，从而部分流量直接击穿到元数据服务。

可以看到，布隆过滤器模式只适用于元数据没那么大的情况，否则过重模式会带来不可预期的其他问题。

由于 Appkey 规则固定，我们把非法请求逻辑从 bloomfilter 切换成规则校验模式，优化完后网关 fgc 抖动的现象消失。由于 API 元数据较少，所以 API 的布隆过滤器逻辑继续保留。

四、端侧异地多活

为配合菜鸟南通异地多活，网关提供了异地多活能力，支持 SDK 端侧灾备切换。服务商只需要使用多活 client 即可，SDK 保证了使用的透明性。为保证南通链路链路可用性，日常保持配置小流量切换状态。当某个机房不可访问时，SDK 支持从另一个机房拉取配置，同时支持把流量完全切到另一个存活机房上。

五、去中心化

随着业务发展，部分 API QPS 达到一二十万，这部分流量需要大量网关机器来支撑，另外大流量可能对线上集群稳定性带来一定挑战。所以，网关支持了去中心化，并对部分高 QPS 的 API 做去中心化改造。部分高流量的 API 在同意接入直接分流到业务服务的 HSF 扩展端口上，网关对 HSF 接口做了扩展，经过网关的一定校验逻辑后再打到业务 HSF 接口上。

六、报表架构升级

开放平台每天能产生几百亿的数据，而开放平台的报表是实时产生的，告警也是基于实时产生的报告人来执行。原报表架构如下：

该架构会带来如下问题：

1. 流量浪费，从 SLS 拉取日志流量需要消耗大量带宽资源，有高额的成本费用消耗；

2. SLS 出口瓶颈。目前虽然是自动扩容，但之前出现过自动分裂后报表异常的情况；同时在大促期间会会出现带宽不够用的情况。

3. 由于数据量大，每个任务需要计算的内容多，高峰期容易出现资源升高以及可能出现任务瓶颈。

blink 理论上支持对所有的报表进行合并，多个任务变成单个任务，但这样会导致报表异常复杂，节点之间相互影响，调优或者问题定位更不可控。为了解决这个问题，对部分相关性高的报表做了合并，但是这样只能缓解问题。

所以，在此基础上我们对报表架构进一步优化，合并部分报表同时添加 Blink 临时聚合节点，以最细粒度的方式对 blink 资源做聚合，即使以 api*appkey 方式聚合，合并后的量级对比原始日志依旧是降低了好几个量级(每分钟千万级别压缩到 3w 左右)。所有 blink 节点不再依赖原始日志，而是依赖聚合节点，调整后的架构如下：

调整后架构报表产出会延迟 2~3 分钟，但延迟的成本在可接受范围内，同时调整后带来的收益更大：

1. 减轻了每个 blink 子任务的压力，并且对流量消耗也可以大大减轻

2. 减轻运维成本，只需要维护好上游的汇聚任务即可，下游的任务因为数据量大幅减少导致运维起来特别轻松。

七、端侧调用

为保护消费者的隐私信息，目前服务商从开放平台获取到的订单信息默认情况下无法获取获取到收货人的敏感信息。但商家在作业时查看订单收货人信息又是一个高频的场景，为了同时能解决敏感信息不被服务商获取以及同时满足商家作业的诉求，平台需要有一个方案能解决数据能直接从商家浏览器来获取消费者信息的能力。

为此，开放平台与安全部展开合作，共建了一套端侧查看消费者敏感数据的安全体系。

调用开放平台的所有接口都需要有服务商的业务身份，也就是 ak/sk，但这种模式显然不适用于端直接调用模式，容易存在 sk 泄露的风险。为此，我们通过 token 模式来替代 sk 模式，通过 isv 的服务端来换取平台 token。

同时，为了防止黑客通过该组件来刷数据，我们还引入霸下等风控组件来完成人机识别的操作。

整个过程通过封装成 js sdk 方式透出给服务商使用，降低服务商接入成本。

整体调用过程如下：

八、探索：打通阿里云售卖区与弹内的网络链路

目前与开放网关互通的服务商服务有很大一部分部署在聚石塔上，为解决服务商的安全以及网络带宽问题，开放网关与聚石塔尝试打磨一整套方案，以奇门网关（开放网关访问服务商链路）为例，服务商仅在聚石塔 AppEngine 上部署，并开启对奇门组件即可，服务接口无需暴露到公网，整个访问链路走内网通道，节省服务商网络带宽同时提升网络访问链路的整体稳定性。

九、总结与展望

过去网关在保持架构简单的基础上增加了安全、隐私保护等能力，而架构的演进也是朝着简单化发展，节点精简却带来了更大的收益。在云化的时代，我们也跟会向"云"靠拢，与聚石塔的基建、产品打通，赋能塔内服务商同时降低服务商成本，同时更好地服务业务。