每个接触过 Serverless 的人应该都听过这样一句话:“Serverless 是无状态的。”顾名思义,无状态就是没有状态,我们无法使用它来保存状态,用完即销毁。那么,在 Serverless 架构下(这里特指 FaaS 平台),函数的前一次运行和这一次运行,不会有联系呢?前一次运行的结果也不会影响这一次呢?
函数的无状态探索
首先,需要明确的是 Serverless 的关键特征:运行成本更低、自动扩缩容、事件驱动、无状态性。其中,无状态性是说开发者可以直接将服务业务逻辑代码部署,运行在第三方提供的无状态计算容器中。
那么,前一次运行情况是否会影响这一次呢?准确来说,只有在容器没有被复用的情况下是这样的。但是在实际的项目中,为了降低冷启动率,提高瞬时产生的高并发应对能力,往往会采用容器复用,而这可能会让“无状态性“变得比较复杂。
我们以腾讯云的 SCF 为例,在控制台创建一个函数,使用以下的代码测试一下具体情况:
# -*- coding: utf8 -*-
import json
def main_handler(event, context):
print("Test")
return("Hello World")
我们可以看到,通过点击测试按钮,输出了日志:Test
,接下来,多次点击:
可以看到,随着我们点击测试按钮,每次都在日志准确输出了Test
。接下来,我们变换一下代码:
# -*- coding: utf8 -*-
import json
print("Not in main_handler")
def main_handler(event, context):
print("Test")
return("Hello World")
同样的方法,连续点击三次测试,并且记录结果:
通过这一组测试,我们发现,这三个结果有点不太一样:只有第一次请求的时候,执行了这条语句:
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")
可以看到,在第一次测试的时候,这个程序先执行了:
print(" 此处给 tempNumber 赋值 ")
tempNumber = 100
执行完成之后,tempNumber
这个变量就会存在,在接下来的几次调用中,都直接取了这个值。
也就是说,函数在复用容器的情况下被执行(或者说是被触发),实际上可以认为是已经有一个进程被启动,每次触发是通过这个进程来调用入口方法,所以在方法之外的各种操作,实际上是冷启动的时候,在启动进程时会被执行。
因此,函数的无状态性并不是前一次操作对后一次被触发没有影响。那么,所谓的无状态到底指的是什么呢?
在 CNCF 发布的 Serverlss 白皮书中,是这样描述的:Serverless 架构通常是无状态、不可变和短暂的。每个函数都以指定的角色和明确定义有限的资源访问权限运行。什么样的程序或者服务适合 Serverless 架构?白皮书中是这样表述的:无状态,短暂的,对瞬间冷启动时间没有过多需求的程序适合使用 Serverless 架构。
所以,函数的无状态实际上可以认为是:函数是运行在第三方提供的无状态计算容器中的,并且在容器无复用、存在冷启动的情况下,函数可以认为是无状态;由于各个厂商的容器降低冷启动方案是不同的,容器复用方案也都是未公开的,所以什么时候可能会复用容器,怎么复用也是未知的,这就要求我们函数的功能本身要保证是无状态的。例如,在函数中,保存某些数据到缓存中,下次触发的时候从缓存中获得对应内容就是容易产生异常的操作,因为云厂商无法保证这次请求是否复用了已有容器,以及复用的已有容器是否就是上次进行缓存的容器。
拓展
根据上面讨论的内容,我们可以进行一些实践化的应用:
1. 通过容器复用,完成初始化操作
刚刚说过了,如果在容器复用的前提下,在函数外面执行的内容是可以直接使用的,所以我们实际上是可以在外层进行一些初始化的,例如:
以上图的代码为例,通过这样的初始化,就不用每次调用函数都进行一次数据库的初始化 / 链接等,而是可以复用已有的链接。如果是在 main_handler 中进行数据库的初始化 / 链接,会影响函数性能,在高并发的情况下更容易把数据库的链接打满,造成恶劣影响。
2. 小心容器复用,不要掉进坑里
我之前写过一个 SCF 打包 Python 依赖的小工具,运行在 SCF 中,测试的时候是好好的,但是项目上线之后,我发现了一个问题:只有冷启动的情况下,依赖是可以被打包的,如果出现容器复用的情况,就会出现依赖打包失败的问题。
经过仔细排查才发现,原来是因为一个对象在使用完成之后未被清理,由于容器是被复用,或者说是“这个对象也被复用了”,在执行指定方法的时候,看到对象已存在,就会直接用这个对象,导致本次函数的触发使用了上次残留的对象,发生异常。
所以说,当程序在云函数中连续执行多次的时候,开始成功后来失败,很可能就是由于某些资源复用,导致程序出错。
3. 我就想要一种状态
有的人在使用云函数的时候,可能真的需要有一种状态来记录某些事情,例如博客系统判断管理员用户是否登录,本来可以直接放到缓存中的操作,此时不能放进去,那应该怎么处理,如何记录管理员是否已经登陆了后台,或者说如何确定这个用户是否为管理员?
这种情况是很常见的,我们可以融合两套方案:
- 方案 1: 采用 Token 机制
- 方案 2: 采用缓存机制
所谓的采用 Token 机制和缓存机制融合方案,就是在管理员用户登陆之后,会生成一个 Token,这个 Token 就记录到数据库中,同时这个 Token 也会被写到缓存中。当用户请求发起后,函数会先尝试在缓存中获取结果,如果没获取到,就连接数据库进行获取。
总结
Serverless 架构可以被看成是一个新的技术,一种新的框架,很多时候,我们不能用已有的态度去衡量新鲜事物。同样,一个特性也很难直接用好坏去形容,就无状态性来说,真的是有几种钟爱,就有几种迷茫。
Serverless Framework 30 天试用计划
我们诚邀您来体验最便捷的 Serverless 开发和部署方式。在试用期内,相关联的产品及服务均提供免费资源和专业的技术支持,帮助您的业务快速、便捷地实现 Serverless!
详情可查阅:https://cloud.tencent.com/document/product/1154/38792
One More Thing
3 秒你能做什么?喝一口水,看一封邮件,还是 —— 部署一个完整的 Serverless 应用?复制以下链接至 PC 浏览器访问:
china.serverless.com/express
3 秒极速部署,立即体验史上最快的 Serverless HTTP 实战开发!
传送门:
- GitHub: github.com/serverless
- 官网:serverless.com
点击阅读原文,访问:Serverless 中文网,您可以在 最佳实践 里体验更多关于 Serverless 应用的开发!