开放网关架构演进

这篇具有很好参考价值的文章主要介绍了开放网关架构演进。希望对大家有所帮助。如果存在错误或未考虑完全的地方,请大家不吝赐教,您也可以点击"举报违法"按钮提交疑问。

作者:庄文弘(弘智)

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

开放网关诞生于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上部署,并开启对奇门组件即可,服务接口无需暴露到公网,整个访问链路走内网通道,节省服务商网络带宽同时提升网络访问链路的整体稳定性。

开放网关架构演进,架构

九、总结与展望

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

到了这里,关于开放网关架构演进的文章就介绍完了。如果您还想了解更多内容,请在右上角搜索TOY模板网以前的文章或继续浏览下面的相关文章,希望大家以后多多支持TOY模板网!

本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若转载,请注明出处: 如若内容造成侵权/违法违规/事实不符,请点击违法举报进行投诉反馈,一经查实,立即删除!

领支付宝红包 赞助服务器费用

相关文章

  • 【架构师】零基础到精通——架构演进

    博客昵称:架构师Cool 最喜欢的座右铭:一以贯之的努力,不得懈怠的人生。 作者简介:一名Coder,软件设计师/鸿蒙高级工程师认证,在备战高级架构师/系统分析师,欢迎关注小弟! 博主小留言:哈喽!各位CSDN的uu们,我是你的小弟Cool,希望我的文章可以给您带来一定的帮

    2024年02月02日
    浏览(90)
  • 《凤凰架构》第一章——服务架构演进史

    前言 刚开始决定弄懂文中所提到的所有东西,就像我写ByteByteGo呢几篇文章一样,把每一句话都弄懂。但是对于《凤凰架构》来说,这有点太费时间了,并且没有必要,有些东西可能永远都不会用到,但文章为了全面的介绍一个内容,会提到那些东西。所以我还是针对一些自

    2024年02月14日
    浏览(46)
  • 【架构】互联网应用开发架构演进历程

    首先我们了解下计算机软件的发展历史,大概总结概括,分为c/s时代,web1.0时代和web2.0时代。 c/s时代:富客户端方案。卖软件可赚钱。​例如 qq、影音、游戏。 1.0时代:主要是单向信息的发布,即信息门户—广大浏览器客户端​ ,互联网内容是由少数编辑人员(或站长)定制的

    2023年04月26日
    浏览(66)
  • 大型网站架构演进过程

    大型网站的技术挑战主要来自于庞大的用户,高并发的访问和海量的数据,任何简单的业务一旦需要处理数以P计的数据和面对数以亿计的用户,问题就会变得很棘手。大型网站架构主要就是解决这类问题。 架构选型是根据当前业务需要来的,在满足业务需求的前提下,既要

    2024年02月08日
    浏览(43)
  • 合约广告平台架构演进实践

    作者 | 王悦凯 导读 从事B端业务系统研发多年,不免会有这样的思考:B端系统的技术挑战是什么?什么样的业务架构算好架构?本文结合百度合约广告业务的发展历程,介绍广告投放平台从单体架构到微服务架构演进过程中碰到的问题和思考。希望通过本文的介绍,让大家更

    2024年02月02日
    浏览(39)
  • 淘宝技术架构演进

    看了《淘宝技术这十年》,总结于此。 从无到有 2003年,eBay 和易趣在资本方面正打得不可开交,那怎么在最短的时间内把一个网站从零开始 建立起来呢? 淘宝为了尽快上线,仅花了一个月把买来的LAMP(Linux+ Apache+MySQL+PHP)改造上线。主要的改造是:从一个数据库进行所有的

    2024年02月06日
    浏览(46)
  • 电商系统架构演进

    具体以电子商务网站为例, 展示web应用的架构演变过程。 这个时候是一个web项目里包含了所有的模块,一个数据库里包含了所需要的所有表,这时候网站访问量增加时,首先遇到瓶颈的是应用服务器连接数,比如tomcat连接数不能无限增加,线程数上限受进程内存大小、CPU内

    2024年02月08日
    浏览(37)
  • Docker前置背景:架构演进

       \\\"但人类都环绕星球,我更愿追随彗星漂流~\\\"          在正式引入架构演进之前,本小节会对一些比较重要、常见的概念进行介绍。 (1)应用(application)/系统(system)          为了完成一整套服务的一个程序或者一组相互配合的程序群。生活例子类比:为了完成一项任务

    2024年02月13日
    浏览(45)
  • 八种架构演进

    日升时奋斗,日落时自省 目录 1、单机架构 2、应用数据分离架构 3、应用服务集群架构 4、读写分离/主从分离架构 5、冷热分离架构 6、垂直分库架构 7、微服务架构 8、容器编排架构 9、小结 特征:应用服务和数据库服务器公用一台服务器 出现场景:访问量较小,单机可以满

    2024年02月12日
    浏览(32)
  • 架构的演进

    单体架构也称之为单体系统或者是单体应用。就是一种把系统中所有的功能、模块耦合在一个应用中的架构方式。 存在的问题: 代码耦合:模块的边界模糊、依赖关系不清晰,整个项目非常复杂,每次修改代码都心惊胆战 迭代困难:每次功能的变更或bug的修复都会导致重新

    2024年01月20日
    浏览(32)

觉得文章有用就打赏一下文章作者

支付宝扫一扫打赏

博客赞助

微信扫一扫打赏

请作者喝杯咖啡吧~博客赞助

支付宝扫一扫领取红包,优惠每天领

二维码1

领取红包

二维码2

领红包