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

如果说，这两年在云计算的领域中那些名词最热门，可能非“云原生”、“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就是：

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 架构没有明确的要求我们怎么做，所以适合自己的就是最好的。不求甚解，也许也是一种“最佳”。