vlambda博客
学习文章列表

【最不佳实践】函数计算的函数是什么意思

如果说,这两年在云计算的领域中那些名词最热门,可能非“云原生”、“Serverless”等莫属了,现在在云计算领域聊天,中途不说一下云原生、Serverless,差不多就会“被落伍”。

在如今,在Serverless架构火热发展的过程中,我们不得不面对一个词:FaaS。

所谓的FaaS就是Functions as a Service的简称,翻译成国内各个云厂商的产品就是:函数计算、云函数等。

无疑,这里有一个共同点,那就是这些产品都与函数有着或多或少的“纠葛”,那么这里面的函数是什么?到底是不是我们曾经认识的“二狗子”,还是说“二狗子已经变了”?

定义对比

在百度百科中,传统编程领域的函数定义为:

函数是指一段可以直接被另一段程序或代码引用的程序或代码。也叫做子程序、(OOP中)方法。
一个较大的程序一般应分为若干个程序块,每一个模块用来实现一个特定的功能。所有的高级语言中都有子程序这个概念,用子程序实现模块的功能。在C语言中,子程序的作用是由一个主函数和若干个函数构成。由主函数调用其他函数,其他函数也可以互相调用。同一个函数可以被一个或多个函数调用任意多次。
在程序设计中,常将一些常用的功能模块编写成函数,放在函数库中供公共选用。要善于利用函数,以减少重复编写程序段的工作量。
函数分为全局函数、全局静态函数;在类中还可以定义构造函数、析构函数、拷贝构造函数、成员函数、友元函数、运算符重载函数、内联函数等。

关于函数计算中的函数,在各个云厂商中的定义:

  • 阿里云

    函数计算(Function Compute)是一个事件驱动的全托管 Serverless 计算服务,您无需管理服务器等基础设施,只需编写代码并上传,函数计算会为您准备好计算资源,并以弹性、可靠的方式运行您的代码。

  • 腾讯云

    云函数(Serverless Cloud Function,SCF)是腾讯云为企业和开发者们提供的无服务器执行环境,帮助您在无需购买和管理服务器的情况下运行代码。您只需使用平台支持的语言编写核心代码并设置代码运行的条件,即可在腾讯云基础设施上弹性、安全地运行代码。SCF 是实时文件处理和数据处理等场景下理想的计算平台。

通过各个厂商的描述,“函数”这个词,貌似没有被单独解释,或者是被单独的描述,整体来看,“函数”在Serverless架构下,貌似是一个“函数即服务”的计算平台。

与传统的计算机编程中的函数对比,在Serverless架构下的Function,变得略微模糊。

函数就是函数

在最开始,Serverless架构中的FaaS平台,通常都是针对编程语言提供对应的Runtime,例如Python3的运行时,Node.js12的运行时等,在这些FaaS平台中,针对这些运行时是有一个词汇叫做”函数入口“,所谓的函数入口指的就是我们一个相对明确的方法或者函数。

例如以Python为例,我们的函数入口可以定义成:文件名.方法名,具体来说可以是index.handler

此时对应的文件index.py就是:

1
2
handler(args1, args2):
pass

此时,当其被事件触发时,就会默认调用这个handler函数,并将对应的事件数据结构和上下文等作为参数传入。所以,在最初的概念中,Function的概念或许真的就是指一个函数,这个函数有点类似于C语言中的main()

函数并不是函数

但是在实际发展过程中,我们会发现,真实情况下的Function,只是更加抽象的概念,并不是传统的函数概念,而是”对新鲜事物的一种特指“。

例如:

  • 传统的某个语言Runtime为例,在其代码中不仅仅会有函数的入口,还可能存在初始化方法、结束方法,那么这里的函数到底是指的谁,这个事情就说不清楚了;

  • 随着时间的发展,自定义运行时、自定义镜像等概念逐渐被提出,所谓的函数入口逐渐的变成了启动指令,例如阿里云的custom runtime的启动入口实际上是bootstrap中的启动命令,那么此时函数就不再是我们曾经说的函数了;

所谓的”一种特指“,实际上就是说他表示的一个服务,再或者说,他表示的是在Serverless架构下的计算平台中的”计算模块粒度“。这个模块的粒度:

  • 它可以是一个单纯的函数,非常简单的一个方法;

  • 它也可以是一个相对完整的功能,几个方法的结合,例如登录功能;

  • 它还可以是几个功能的结合,形成一个简单的模块,例如登陆/注册模块;

  • 它甚至可以是一个框架,例如在一个函数中,放下整个框架,如express、django等;

  • 它甚至是一个完整的服务,例如某个blog系统(zblog,wordpress)等部署到一个函数中,对外提供服务;

“不求甚解”未尝不可

就我个人而言,在Serverless架构中,对函数的概念、定义,真的不能太较真。因为这个函数,有的时候或许和我们计算机编程的函数有些许类似,但是有的时候,这两者可能毫无关系,过分的纠结“我要将业务迁移到函数计算架构是不是要把业务打成函数的粒度”就太“得不偿失”了。

同样是函数,学习计算机编程的时候有函数,在接触Serverless架构的时候有函数,在学习数学的时候也有函数,此函数非彼函数,每个函数各有妙用,无需“强行对应”,更不必区分个所以然。

坦然面对“函数”

在Serverless架构下,我相对来说是比较推荐“具体情况具体分析、沉着面对”的思路。

往往有很多人在上Serverless架构的时候都在想“我应该如何面对函数“,是“一个服务对应一个函数”还是“一个功能对应一个函数”,再比如是“一个函数对应一个函数”?

其实站在我的角度来看,这个不用过分纠结,我们只需要遵循两个原则即可:

  1. 资源相似原则:所谓的资源相似指的是,当我们某个业务中,所对外暴露的接口是否对资源消耗类似。例如,某个后端服务,对外暴露10个接口,其中9个接口的内存只需要128M,超时只需要3秒;而另一个接口则需要2048M的内存与60秒的超时;此时我们可以认为前9个接口是资源相似的,可以放在“一个函数中实现”,最后一个单独来放到一个函数中实现;

  2. 功能相似原则:所谓的功能相似指的是,当我们一个业务中,功能概念,定义相差非常大的时候,不太建议将这些功能放在一起。例如某个聊天系统,有一个聊天功能(Websocket),还有一套注册/登录功能,如果此时将两者融合到一起,其实在一定程度上会增加项目的复杂度,也不宜与后期管理;可以考虑拆分成聊天函数和注册/登陆函数;

如果说纠结如何面对“函数”,其实我觉得可以把他认为是一种哲学:

业务拆的太细:

  • 函数太多,不易于管理;

  • 业务出现问题,不便于排查具体情况;

  • 会导致很多模块,配置重复使用;

  • 在一定情况下会让冷启动变的比较频繁;

业务耦合的太严重:

  • 现阶段下,容易产生比较大的资费问题;

  • 并发的情况下,容易出现流量限制问题;

  • 更新业务代码可能有较大的风险;

  • 不便调试等;

总结

最不佳实践第一节:用函数要用到“不求甚解”,再到“了然于胸”。使用Serverless架构,不是较真能出效果的,往往“要根据业务具体情况”来进行处理,无论是目标为降低迁移/改造成本,还是说体验技术红利,再或者说是极客风。

Serverless架构没有明确的要求我们怎么做,所以适合自己的就是最好的。不求甚解,也许也是一种“最佳”。


New

Serverless工程实践

在大家的支持和鼓励下,我的新书《Serverless工程实践:从入门到进阶》已经在京东上架了,希望大家可以多多支持我的新书。








点“阅读原文”查看查看我的博客原文