¤ 拓展阅读 ¤
从线程池隔离到全异步化与多集群
作为一个业务网关，不可避免会遇到API质量参差不齐的情况，高RT的API会占用较多的线程资源。为减少API调用占用线程导的互相影响，最早网关使用了线程池分组的方式来维护，但线程池分组也带来了问题：
线程池分组维护成本较高。
分组内的api之间依旧会互相影响，而api抖动是个高概率的事件，当分组较大时候互相影响现象更明显。
为此，网关做了全异步化的升级改造。全异步化包括两部分：
容器层异步化：避免了容器在业务处理过程处理线程一直被占用的情况，提升容器的线程利用率。
请求后端异步化：通过HSF请求后端异步化调用方式，提升HSF线程池利用率，避免出现HSF线程池打满的情况。
元数据多级缓存演变
▐ Appkey元数据存储去布隆过滤器
随着业务发展，Appkey数据量快速上涨，目前的哈希算法构建appkey bloomfilter占用60M内存，在序列化时瞬间内存byte copy会有100M左右，经常引起fgc导致业务抖动，这个对服务端和客户端都是埋雷。另外富客户端在拉到bloomfilter完成一系列构建过程中如果有异常，会直接忽略bloomfilter；这也导致前端时间用增依赖TOP去中心化包构建bloomfilter失败，从而部分流量直接击穿到元数据服务。
可以看到，布隆过滤器模式只适用于元数据没那么大的情况，否则过重模式会带来不可预期的其他问题。
随着业务发展，部分API QPS达到一二十万，这部分流量需要大量网关机器来支撑，另外大流量可能对线上集群稳定性带来一定挑战。所以，网关支持了去中心化，并对部分高QPS的API做去中心化改造。部分高流量的API在同意接入直接分流到业务服务的HSF扩展端口上，网关对HSF接口做了扩展，经过网关的一定校验逻辑后再打到业务HSF接口上。
-
流量浪费，从SLS拉取日志流量需要消耗大量带宽资源，有高额的成本费用消耗； SLS出口瓶颈。目前虽然是自动扩容，但之前出现过自动分裂后报表异常的情况；同时在大促期间会会出现带宽不够用的情况。
由于数据量大，每个任务需要计算的内容多，高峰期容易出现资源升高以及可能出现任务瓶颈。
blink理论上支持对所有的报表进行合并，多个任务变成单个任务，但这样会导致报表异常复杂，节点之间相互影响，调优或者问题定位更不可控。为了解决这个问题，对部分相关性高的报表做了合并，但是这样只能缓解问题。
减轻了每个blink子任务的压力，并且对流量消耗也可以大大减轻
减轻运维成本，只需要维护好上游的汇聚任务即可，下游的任务因为数据量大幅减少导致运维起来特别轻松。
端侧调用
目前与开放网关互通的服务商服务有很大一部分部署在聚石塔上，为解决服务商的安全以及网络带宽问题，开放网关与聚石塔尝试打磨一整套方案，以奇门网关（开放网关访问服务商链路）为例，服务商仅在聚石塔AppEngine上部署，并开启对奇门组件即可，服务接口无需暴露到公网，整个访问链路走内网通道，节省服务商网络带宽同时提升网络访问链路的整体稳定性。
总结与展望
过去网关在保持架构简单的基础上增加了安全、隐私保护等能力，而架构的演进也是朝着简单化发展，节点精简却带来了更大的收益。在云化的时代，我们也跟会向"云"靠拢，与聚石塔的基建、产品打通，赋能塔内服务商同时降低服务商成本，同时更好地服务业务。
大淘宝技术开放平台，是阿里与外部生态互联互通的重要开放途径，通过开放的产品技术把阿里经济体一系列基础服务，像水、电、煤一样输送给我们的商家、开发者、社区媒体以及其他合作伙伴，推动行业的定制、创新、进化, 并最终促成新商业文明生态圈。
我们是一支技术能力雄厚，有着光荣历史传统的技术团队。在历年双十一战场上，团队都表现着优异的成绩。这里承载着每秒百万级的业务处理，90%的订单通过订单推送服务实时地推送到商家的ERP系统完成电商作业，通过奇门开放的ERP-WMS场景已经成为仓储行业标准。随着新零售业务的持续探索与快速发展，我们渴求各路高手加入，参与核心系统架构设计、性能调优，开放模式创新等富有技术挑战的工作。
本文分享自微信公众号 - 大淘宝技术（AlibabaMTT）。
如有侵权，请联系 support@oschina.cn 删除。
本文参与“OSC源创计划”，欢迎正在阅读的你也加入，一起分享。
