网站建设市场调研,网店网站设计,wordpress 匿名投票,seo刷点击软件作者#xff1a;庄文弘#xff08;弘智#xff09; 淘宝开放平台是阿里与外部生态互联互通的重要开放途径#xff0c;通过开放的产品技术把阿里经济体一系列基础服务#xff0c;像水、电、煤一样输送给我们的商家、开发者、社区媒体以及其他合作伙伴#xff0c;推动行业的…作者庄文弘弘智 淘宝开放平台是阿里与外部生态互联互通的重要开放途径通过开放的产品技术把阿里经济体一系列基础服务像水、电、煤一样输送给我们的商家、开发者、社区媒体以及其他合作伙伴推动行业的定制、创新、进化, 并最终促成新商业文明生态圈。 开放网关诞生于07年到现在已经有15年的历史流量从日两千万到到现在几百亿支撑的业务也从淘系扩展到集团内多BU。随着流量上涨网关的技术架构也在持续升级迭代以支撑更大的流量和更广的业务。本文把网关近些年来的技术架构变迁做梳理和总结回顾下网关的发展过程。 一、系统架构
先简单浏览下网关整体的技术架构。网关的主要职责在于访问控制有权限控制、流量控制、映射打点等基础能力外通讯协议主要为http协议而服务协议支持HSF、http等。 二、从线程池隔离到全异步化与多集群
作为一个业务网关不可避免会遇到API质量参差不齐的情况高RT的API会占用较多的线程资源。为减少API调用占用线程导的互相影响最早网关使用了线程池分组的方式来维护但线程池分组也带来了问题 线程池分组维护成本较高。 分组内的api之间依旧会互相影响而api抖动是个高概率的事件当分组较大时候互相影响现象更明显。 为此网关做了全异步化的升级改造。全异步化包括两部分 容器层异步化避免了容器在业务处理过程处理线程一直被占用的情况提升容器的线程利用率。 请求后端异步化通过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接口上。 六、报表架构升级
开放平台每天能产生几百亿的数据而开放平台的报表是实时产生的告警也是基于实时产生的报告人来执行。原报表架构如下 该架构会带来如下问题 流量浪费从SLS拉取日志流量需要消耗大量带宽资源有高额的成本费用消耗 SLS出口瓶颈。目前虽然是自动扩容但之前出现过自动分裂后报表异常的情况同时在大促期间会会出现带宽不够用的情况。 由于数据量大每个任务需要计算的内容多高峰期容易出现资源升高以及可能出现任务瓶颈。 blink理论上支持对所有的报表进行合并多个任务变成单个任务但这样会导致报表异常复杂节点之间相互影响调优或者问题定位更不可控。为了解决这个问题对部分相关性高的报表做了合并但是这样只能缓解问题。 所以在此基础上我们对报表架构进一步优化合并部分报表同时添加Blink临时聚合节点以最细粒度的方式对blink资源做聚合即使以api*appkey方式聚合合并后的量级对比原始日志依旧是降低了好几个量级(每分钟千万级别压缩到3w左右)。所有blink节点不再依赖原始日志而是依赖聚合节点调整后的架构如下 调整后架构报表产出会延迟2~3分钟但延迟的成本在可接受范围内同时调整后带来的收益更大 减轻了每个blink子任务的压力并且对流量消耗也可以大大减轻 减轻运维成本只需要维护好上游的汇聚任务即可下游的任务因为数据量大幅减少导致运维起来特别轻松。 七、端侧调用
为保护消费者的隐私信息目前服务商从开放平台获取到的订单信息默认情况下无法获取获取到收货人的敏感信息。但商家在作业时查看订单收货人信息又是一个高频的场景为了同时能解决敏感信息不被服务商获取以及同时满足商家作业的诉求平台需要有一个方案能解决数据能直接从商家浏览器来获取消费者信息的能力。 为此开放平台与安全部展开合作共建了一套端侧查看消费者敏感数据的安全体系。 调用开放平台的所有接口都需要有服务商的业务身份也就是ak/sk但这种模式显然不适用于端直接调用模式容易存在sk泄露的风险。为此我们通过token模式来替代sk模式通过isv的服务端来换取平台token。 同时为了防止黑客通过该组件来刷数据我们还引入霸下等风控组件来完成人机识别的操作。 整个过程通过封装成js sdk方式透出给服务商使用降低服务商接入成本。 整体调用过程如下 八、探索打通阿里云售卖区与弹内的网络链路
目前与开放网关互通的服务商服务有很大一部分部署在聚石塔上为解决服务商的安全以及网络带宽问题开放网关与聚石塔尝试打磨一整套方案以奇门网关开放网关访问服务商链路为例服务商仅在聚石塔AppEngine上部署并开启对奇门组件即可服务接口无需暴露到公网整个访问链路走内网通道节省服务商网络带宽同时提升网络访问链路的整体稳定性。 九、总结与展望
过去网关在保持架构简单的基础上增加了安全、隐私保护等能力而架构的演进也是朝着简单化发展节点精简却带来了更大的收益。在云化的时代我们也跟会向云靠拢与聚石塔的基建、产品打通赋能塔内服务商同时降低服务商成本同时更好地服务业务。
