每个接触过 Serverless 的人应该都听过这样一句话:“Serverless 是无状态的。”顾名思义,无状态就是没有状态,我们无法使用它来保存状态,用完即销毁。那么,在 Serverless 架构下(这里特指 FaaS 平台),函数的前一次运行和这一次运行,不会有联系呢?前一次运行的结果也不会影响这一次呢?
函数的无状态探索
首先,需要明确的是 Serverless 的关键特征:运行成本更低、自动扩缩容、事件驱动、无状态性。其中,无状态性是说开发者可以直接将服务业务逻辑代码部署,运行在第三方提供的无状态计算容器中。
那么,前一次运行情况是否会影响这一次呢?准确来说,只有在容器没有被复用的情况下是这样的。但是在实际的项目中,为了降低冷启动率,提高瞬时产生的高并发应对能力,往往会采用容器复用,而这可能会让“无状态性“变得比较复杂。
我们以腾讯云的 SCF 为例,在控制台创建一个函数,使用以下的代码测试一下具体情况:
复制代码
# -*- coding: utf8 -*-importjsondefmain_handler(event, context):print("Test")return("Hello World")
![3d8dd0ffb911867f00cfed36c5ad478b.png](https://i-blog.csdnimg.cn/blog_migrate/3a33425a16ebe3de596a266acb059cce.jpeg)
我们可以看到,通过点击测试按钮,输出了日志: Test ,接下来,多次点击:
![3e60be0ecd7b0bb27bca43230eabc4c4.png](https://i-blog.csdnimg.cn/blog_migrate/e098e39b87330e055d6f06b867318cf3.jpeg)
![dc6d354e6dfbd38c126c5903a1e08ca3.png](https://i-blog.csdnimg.cn/blog_migrate/c9733f84386e4f93357394c6727d98b6.jpeg)
可以看到,随着我们点击测试按钮,每次都在日志准确输出了 Test 。接下来,我们变换一下代码:
复制代码
# -*- coding: utf8 -*-importjsonprint("Not in main_handler")defmain_handler(event, context):print("Test")return("Hello World")
同样的方法,连续点击三次测试,并且记录结果:
![ba1da12027d6e519a8b189cd3d29721d.png](https://i-blog.csdnimg.cn/blog_migrate/38a44c9bbd705567bc67d554c5fb524f.jpeg)
![243f22fb491da070b6bdad5379f207ca.png](https://i-blog.csdnimg.cn/blog_migrate/94d4df6f6acaefe1d984810ea2886757.jpeg)
![afce32b659b49f16e8c92a57d6ab9a96.png](https://i-blog.csdnimg.cn/blog_migrate/44e66f05205793cac3feddf89795047c.jpeg)
通过这一组测试,我们发现,这三个结果有点不太一样:只有第一次请求的时候,执行了这条语句:
复制代码
print("Not in main_handler")
为什么后几次都没有执行这条语句呢?是没执行到这里?还是因为容器复用的原因,在接下来的几次跳过了这个步骤?为什么会跳过这个步骤?为了搞清楚具体情况,我们再来做个测试:
复制代码
# -*- coding: utf8 -*-importjsonprint(" 此处给 tempNumber 赋值 ")tempNumber =100defmain_handler(event, context):print("temp number: ", tempNumber)return("Hello World")
![c2979dde4d93e0bee74d41363b1e0682.png](https://i-blog.csdnimg.cn/blog_migrate/666bc06e0da6e45dec583fd55feaf968.jpeg)
![5d7cc10a5999f44955981ecf1f5d5be2.png](https://i-blog.csdnimg.cn/blog_migrate/efe9babb2d619fe8fbc9d08f6ee8f624.jpeg)
![f37f1586a1a761b8b44309ee39b72a12.png](https://i-blog.csdnimg.cn/blog_migrate/8fe8828412ce448eebafaea5d385ddf0.jpeg)
可以看到,在第一次测试的时候,这个程序先执行了:
复制代码
print(" 此处给 tempNumber 赋值 ")tempNumber =100
执行完成之后, tempNumber 这个变量就会存在,在接下来的几次调用中,都直接取了这个值。
![8d0dd8143ac0bc87267030ef4b2f010b.png](https://i-blog.csdnimg.cn/blog_migrate/285f26dc9c5d6f4bc808f70b16d34374.jpeg)
也就是说,函数在复用容器的情况下被执行(或者说是被触发),实际上可以认为是已经有一个进程被启动,每次触发是通过这个进程来调用入口方法,所以在方法之外的各种操作,实际上是冷启动的时候,在启动进程时会被执行。
因此,函数的无状态性并不是前一次操作对后一次被触发没有影响。那么,所谓的无状态到底指的是什么呢?
在 CNCF 发布的 Serverlss 白皮书中,是这样描述的:Serverless 架构通常是无状态、不可变和短暂的。每个函数都以指定的角色和明确定义有限的资源访问权限运行。什么样的程序或者服务适合 Serverless 架构?白皮书中是这样表述的:无状态,短暂的,对瞬间冷启动时间没有过多需求的程序适合使用 Serverless 架构。
所以,函数的无状态实际上可以认为是:函数是运行在第三方提供的无状态计算容器中的,并且在容器无复用、存在冷启动的情况下,函数可以认为是无状态;由于各个厂商的容器降低冷启动方案是不同的,容器复用方案也都是未公开的,所以什么时候可能会复用容器,怎么复用也是未知的,这就要求我们函数的功能本身要保证是无状态的。例如,在函数中,保存某些数据到缓存中,下次触发的时候从缓存中获得对应内容就是容易产生异常的操作,因为云厂商无法保证这次请求是否复用了已有容器,以及复用的已有容器是否就是上次进行缓存的容器。
拓展
根据上面讨论的内容,我们可以进行一些实践化的应用:
1. 通过容器复用,完成初始化操作
刚刚说过了,如果在容器复用的前提下,在函数外面执行的内容是可以直接使用的,所以我们实际上是可以在外层进行一些初始化的,例如:
![8b1222092b01bcb0126283c632896655.png](https://i-blog.csdnimg.cn/blog_migrate/ca9601faa8ece151994de265905d8396.jpeg)
以上图的代码为例,通过这样的初始化,就不用每次调用函数都进行一次数据库的初始化 / 链接等,而是可以复用已有的链接。如果是在 main_handler 中进行数据库的初始化 / 链接,会影响函数性能,在高并发的情况下更容易把数据库的链接打满,造成恶劣影响。
2. 小心容器复用,不要掉进坑里
我之前写过一个 SCF 打包 Python 依赖的小工具,运行在 SCF 中,测试的时候是好好的,但是项目上线之后,我发现了一个问题:只有冷启动的情况下,依赖是可以被打包的,如果出现容器复用的情况,就会出现依赖打包失败的问题。
经过仔细排查才发现,原来是因为一个对象在使用完成之后未被清理,由于容器是被复用,或者说是“这个对象也被复用了”,在执行指定方法的时候,看到对象已存在,就会直接用这个对象,导致本次函数的触发使用了上次残留的对象,发生异常。
所以说,当程序在云函数中连续执行多次的时候,开始成功后来失败,很可能就是由于某些资源复用,导致程序出错。
3. 我就想要一种状态
有的人在使用云函数的时候,可能真的需要有一种状态来记录某些事情,例如博客系统判断管理员用户是否登录,本来可以直接放到缓存中的操作,此时不能放进去,那应该怎么处理,如何记录管理员是否已经登陆了后台,或者说如何确定这个用户是否为管理员?
这种情况是很常见的,我们可以融合两套方案:
- 方案 1: 采用 Token 机制
- 方案 2: 采用缓存机制
所谓的采用 Token 机制和缓存机制融合方案,就是在管理员用户登陆之后,会生成一个 Token,这个 Token 就记录到数据库中,同时这个 Token 也会被写到缓存中。当用户请求发起后,函数会先尝试在缓存中获取结果,如果没获取到,就连接数据库进行获取。
总结
Serverless 架构可以被看成是一个新的技术,一种新的框架,很多时候,我们不能用已有的态度去衡量新鲜事物。同样,一个特性也很难直接用好坏去形容,就无状态性来说,真的是有几种钟爱,就有几种迷茫。
作者介绍:刘宇,腾讯 Serverless 团队后台研发工程师。