Serverless 架构中的无状态性指的是什么?

发布于:2020 年 5 月 29 日 08:46

Serverless 架构中的无状态性指的是什么?

每个接触过 Serverless 的人应该都听过这样一句话:“Serverless 是无状态的。”顾名思义,无状态就是没有状态,我们无法使用它来保存状态,用完即销毁。那么,在 Serverless 架构下(这里特指 FaaS 平台),函数的前一次运行和这一次运行,不会有联系呢?前一次运行的结果也不会影响这一次呢?

函数的无状态探索

首先,需要明确的是 Serverless 的关键特征:运行成本更低、自动扩缩容、事件驱动、无状态性。其中,无状态性是说开发者可以直接将服务业务逻辑代码部署,运行在第三方提供的无状态计算容器中。

那么,前一次运行情况是否会影响这一次呢?准确来说,只有在容器没有被复用的情况下是这样的。但是在实际的项目中,为了降低冷启动率,提高瞬时产生的高并发应对能力,往往会采用容器复用,而这可能会让“无状态性“变得比较复杂。

我们以腾讯云的 SCF 为例,在控制台创建一个函数,使用以下的代码测试一下具体情况:

复制代码
# -*- coding: utf8 -*-
import json
def main_handler(event, context):
print("Test")
return("Hello World")

Serverless 架构中的无状态性指的是什么?

我们可以看到,通过点击测试按钮,输出了日志:Test,接下来,多次点击:

Serverless 架构中的无状态性指的是什么?

Serverless 架构中的无状态性指的是什么?

可以看到,随着我们点击测试按钮,每次都在日志准确输出了Test。接下来,我们变换一下代码:

复制代码
# -*- coding: utf8 -*-
import json
print("Not in main_handler")
def main_handler(event, context):
print("Test")
return("Hello World")

同样的方法,连续点击三次测试,并且记录结果:

Serverless 架构中的无状态性指的是什么?

Serverless 架构中的无状态性指的是什么?

Serverless 架构中的无状态性指的是什么?

通过这一组测试,我们发现,这三个结果有点不太一样:只有第一次请求的时候,执行了这条语句:

复制代码
print("Not in main_handler")

为什么后几次都没有执行这条语句呢?是没执行到这里?还是因为容器复用的原因,在接下来的几次跳过了这个步骤?为什么会跳过这个步骤?为了搞清楚具体情况,我们再来做个测试:

复制代码
# -*- coding: utf8 -*-
import json
print(" 此处给 tempNumber 赋值 ")
tempNumber = 100
def main_handler(event, context):
print("temp number: ", tempNumber)
return("Hello World")

Serverless 架构中的无状态性指的是什么?

Serverless 架构中的无状态性指的是什么?

Serverless 架构中的无状态性指的是什么?

可以看到,在第一次测试的时候,这个程序先执行了:

复制代码
print(" 此处给 tempNumber 赋值 ")
tempNumber = 100

执行完成之后,tempNumber这个变量就会存在,在接下来的几次调用中,都直接取了这个值。

Serverless 架构中的无状态性指的是什么?

也就是说,函数在复用容器的情况下被执行(或者说是被触发),实际上可以认为是已经有一个进程被启动,每次触发是通过这个进程来调用入口方法,所以在方法之外的各种操作,实际上是冷启动的时候,在启动进程时会被执行。

因此,函数的无状态性并不是前一次操作对后一次被触发没有影响。那么,所谓的无状态到底指的是什么呢?

在 CNCF 发布的 Serverlss 白皮书中,是这样描述的:Serverless 架构通常是无状态、不可变和短暂的。每个函数都以指定的角色和明确定义有限的资源访问权限运行。什么样的程序或者服务适合 Serverless 架构?白皮书中是这样表述的:无状态,短暂的,对瞬间冷启动时间没有过多需求的程序适合使用 Serverless 架构。

所以,函数的无状态实际上可以认为是:函数是运行在第三方提供的无状态计算容器中的,并且在容器无复用、存在冷启动的情况下,函数可以认为是无状态;由于各个厂商的容器降低冷启动方案是不同的,容器复用方案也都是未公开的,所以什么时候可能会复用容器,怎么复用也是未知的,这就要求我们函数的功能本身要保证是无状态的。例如,在函数中,保存某些数据到缓存中,下次触发的时候从缓存中获得对应内容就是容易产生异常的操作,因为云厂商无法保证这次请求是否复用了已有容器,以及复用的已有容器是否就是上次进行缓存的容器。

拓展

根据上面讨论的内容,我们可以进行一些实践化的应用:

1. 通过容器复用,完成初始化操作

刚刚说过了,如果在容器复用的前提下,在函数外面执行的内容是可以直接使用的,所以我们实际上是可以在外层进行一些初始化的,例如:

Serverless 架构中的无状态性指的是什么?

以上图的代码为例,通过这样的初始化,就不用每次调用函数都进行一次数据库的初始化 / 链接等,而是可以复用已有的链接。如果是在 main_handler 中进行数据库的初始化 / 链接,会影响函数性能,在高并发的情况下更容易把数据库的链接打满,造成恶劣影响。

2. 小心容器复用,不要掉进坑里

我之前写过一个 SCF 打包 Python 依赖的小工具,运行在 SCF 中,测试的时候是好好的,但是项目上线之后,我发现了一个问题:只有冷启动的情况下,依赖是可以被打包的,如果出现容器复用的情况,就会出现依赖打包失败的问题。

经过仔细排查才发现,原来是因为一个对象在使用完成之后未被清理,由于容器是被复用,或者说是“这个对象也被复用了”,在执行指定方法的时候,看到对象已存在,就会直接用这个对象,导致本次函数的触发使用了上次残留的对象,发生异常。

所以说,当程序在云函数中连续执行多次的时候,开始成功后来失败,很可能就是由于某些资源复用,导致程序出错。

3. 我就想要一种状态

有的人在使用云函数的时候,可能真的需要有一种状态来记录某些事情,例如博客系统判断管理员用户是否登录,本来可以直接放到缓存中的操作,此时不能放进去,那应该怎么处理,如何记录管理员是否已经登陆了后台,或者说如何确定这个用户是否为管理员?

这种情况是很常见的,我们可以融合两套方案:

  • 方案 1: 采用 Token 机制

  • 方案 2: 采用缓存机制

所谓的采用 Token 机制和缓存机制融合方案,就是在管理员用户登陆之后,会生成一个 Token,这个 Token 就记录到数据库中,同时这个 Token 也会被写到缓存中。当用户请求发起后,函数会先尝试在缓存中获取结果,如果没获取到,就连接数据库进行获取。

总结

Serverless 架构可以被看成是一个新的技术,一种新的框架,很多时候,我们不能用已有的态度去衡量新鲜事物。同样,一个特性也很难直接用好坏去形容,就无状态性来说,真的是有几种钟爱,就有几种迷茫。

作者介绍:

刘宇,腾讯 Serverless 团队后台研发工程师。毕业于浙江大学,硕士研究生学历,曾在滴滴出行、腾讯科技做产品经理,本科开始有自主创业经历,是 Anycodes 在线编程的负责人(该软件累计下载量超 100 万次)。目前投身于 Serverless 架构研发,著书《Serverless 架构:从原理、设计到项目实战》,参与开发和维护多个 Serverless 组件,是活跃的 Serverless Framework 的贡献者,也曾多次公开演讲和分享 Serverless 相关技术与经验,致力于 Serverless 的落地与项目上云。

阅读数:2 发布于:2020 年 5 月 29 日 08:46

评论

发布
暂无评论