0

打造更稳定的 Serverless 业务 | D2 分享视频+文章

 1周前 阅读数 2
以下为 快照 页面,建议前往来源网站查看,会有更好的阅读体验。
原文链接: https://mp.weixin.qq.com/s?__biz=Mzg4MjE5OTI4Mw%3D%3D&%3Bmid=2247486899&%3Bidx=1&%3Bsn=825dcb3453f3465e8ce384586b2a4f9a

Hi,大家好,在 2020.12 月的 D2,我为大家做了一场紧凑的微分享,话题为《打造更稳定的 Serverless 业务》。时间关系,大约只有 20 分钟,为在 Serverless 世界中踟躇的同学们抛砖引玉,让大家了解下我们在做什么。

从大促说起

除了开发和维护 MidwayJS 这一框架体系,提供应用、函数、一体化解决方案外,我们也在 Serverless 的 Runtime 层面有所涉猎。

在 2020 年,我们开放了 Midway Serverless 框架和一体化方案,弥补了 Midway 在 Serverless 方面的缺失,也朝着多场景框架又迈出了一步。

除了社区,阿里内部的 Serverless 业务也蓬勃发展,淘系,飞猪,考拉,高德等 BU 的业务都已经扬帆起航,整体达到规模比去年增长了 10 倍,承接的流量也比同期翻了 6 倍,可以说,Node.js Serverless 已经真正的站稳了脚跟,和原有的 Node.js 应用体系共同支撑起了阿里的前端业务。

BFvQNzn.png!mobile

高德也在” 十一出行节 “再创新记录,提前达到了目标。

Nzae2ee.png!mobile

稳定性保障

去年这个时期,我们 Node.js Serverless 还处在一个起步的阶段,还在做研发保障,平台基建的事情。经历了去年的 ”研发模式升级“ 战役之后,整个发布平台,构建体系,以及开发、调试的能力都经过了重塑,已经达到了可以研发业务上线的要求。

随着使用 BU 的不断增多,业务对稳定性也提出了更高的要求,这迫使我们对此需要提供更多的能力。” 稳定性 “就是随之而来的最大的考验。

对此,我们在 2020 年大促做好了大考准备。针对双促,除了传统的压测,盘点之外,今年由于加入了 Serverles 场景,额外增加了针对 Node.js Serverless 的稳定性保障。

整个额外保障分为如下三块,我们将一一阐述。

uaYnIjy.png!mobile

强弱依赖分析

第一块是强弱依赖分析。利用 技术手段 将业务调用的下游依赖分析出来,明明白白的展示给业务开发,让其清楚的知道,哪些是 ” 强依赖 “,哪些是 ” 弱依赖 “。

所谓的强依赖,是业务直接依赖的下游,如果该下游出现问题,会直接反应到业务本身,造成不可预估的影响,而弱依赖,则是下游出现问题,业务本身不影响或者只影响少许。

如图上的业务依赖,当业务 B 出现问题,依赖 C 包含了一部分业务 B 的数据,业务 A 的系统可以继续稳定的运行,这样子业务 B 对于业务 A 来说就是一个 ”弱依赖”,而业务 C 则是一个强依赖(单条链路)。

当然这是一个理想情况,业务本身会相对复杂,数据接口可能业务非常繁杂,随着时间的推移,还会经常更新迭代,无法人肉沉淀。

这个时候,我们使用了一种依赖分析手段,这套技术,是监控的副产物,由 Alinode 提供的底层带来的能力,详细不久大家就会看到一个全新的 Alinode。

Ainode 是阿里 Node.js 架构组维护的 Node.js 运行时,在社区的 Node.js 运行时之上提供了一系列监控、诊断优化能力。

j2MfAbM.png!mobile

在拿到强弱依赖之后,我们会推进业务的改进,当然,这个改进本质上是一个自我梳理的过程, 并不一定 需要把强依赖都变成弱依赖 ,是一个降低业务依赖风险的过程。

改进的方法也有不少,比如把数据降级,加缓存,或者增加新的数据源,做好不同的数据隔离和错误处理等等。

流量模型预估

第二块是流量模型的预估。

传统的流量模型是“流量(QPS + 机器数)的评估,在 Serverless 场景下,情况以然不同,这里主要有两点情况:

  • 1、容器的数量对业务来说可能已经不太关心,业务希望只需要提供总流量就可以上线

  • 2、平台的单容器承载单位为并发数,这不符合平常业务的换算单位

这导致了开发很难一次性将业务上线,需要 额外关心单个容器,能够承载多少流量 ,然后再将流量和并发度进行转换,这个过程很容易出错且不高效。

777rQva.png!mobile

这一层的含义是,对已知的流量做预估,而不是未知的流量。比如抢红包,是每个整点,那么每个整点的流量可能会有新高,真个流量就是已知的流量。未知的突然流量,是不应该被允许到达业务代码,尽可能在网关层之前就被拦截掉。

针对已经的流量,如何反向预估需要多少资源消耗,虽然用户不关心,但是我们的平台侧上线时还是需要计算,并给出推荐的值,这其中有两个方式。

一是计算出单个容器在单一接口符合业务要求的情况下,比如满足 RT 要求,计算出单容器合理的 QPS 和并发度,这个时候,我们已经可以拿这个值去设置函数的单容器并发以及容器数。

二是通过网关,在业务上线引入流量的时候进行流量测算,是否真的满足上述的场景,根据实际的流量,我们可以动态的调整预留的实例数和弹性的实例比率,以达到最佳的资源配比。

eQZvUb.png!mobile

并发度测算是基于”拥塞控制算法”来得出的,整套产品需要配套平台基建来做,后续我们会针对这个方案进行更细致的分享,欢迎关注 MidwayJS。

多层流量管控

前两项其实都是在业务上线前做的,而流量管控,则是运行时层面实时的处理。

在一般的场景下,我们有多个网关来管理所有的流量。以阿里内部为例,我们有两层网关,分别为通用网关和函数特有的网关,其之下,则是函数容器本身。

当流量来临时,先经过通用网关,路由到函数网关,再根据域名和路径,从函数网关查询特定的函数信息,将流量打入函数。

每一层都需要一定的流量管控。在特定的场景下,经过通用网关的流量是相对较大的(由于函数的数量不定,且为弹性),通用网关的流量限制一般为函数网关所能经过的最大流量。

feyIBnB.png!mobile

当流量到达函数网关时,网关才会相应的去计算到达函数的流量,进行更细粒度的流量控制。而函数网关层面的流量管控,指的则是面向单一函数容器(或是单一函数业务)的限制。

在函数网关的流量管控中,着重是希望将特定的流量打入到特定的函数中,防止不同的函数,使用不同的功能。

而在函数容器本身,我们还做了第三道防护,除了第二点的流量测算外,额外还有防雪崩的作用。

所谓的防雪崩,是防止当一个(或者多个)容器无法工作,所有流量打到其他容器,导致其他容器批量无法工作的情况。

在每个容器都做了这样的防护,才算是真正的将风险降到最低。

V7vEJrZ.png!mobile

这是一个微分享,也是我们这一年来的一些在 Serverless 稳定性方面的总结。其实整个都是出现问题,到解决问题的思考过程,希望大家能够有所收获。

最后:

BVreAnR.png!mobile


猜你喜欢

关于极客头条


聚合每日国内外有价值,有趣的链接。

AD