如果说，这两年在云计算的领域中那些名词zui热门，可能非“云原生”、“Serverless”等莫属了，现在在云计算领域聊天，中途不说一下云原生、Serverless，差不多就会“被落伍”。
在如今，在Serverless架构火热发展的过程中，我们不得不面对一个词：FaaS。
所谓的FaaS就是Functions as a Service的简称，翻译成国内各个云厂商的产品就是：函数计算、云函数等。
无疑，这里有一个共同点，那就是这些产品都与函数有着或多或少的“纠葛”，那么这里面的函数是什么？到底是不是我们曾经认识的“二狗子”，还是说“二狗子已经变了”？
定义对比
在百度百科中，传统编程领域的函数定义为：
函数是指一段可以直接被另一段程序或代码引用的程序或代码。也叫做子程序、（OOP中）方法。 一个较大的程序一般应分为若干个程序块，每一个模块用来实现一个特定的功能。所有的高级语言中都有子程序这个概念，用子程序实现模块的功能。在C语言中，子程序的作用是由一个主函数和若干个函数构成。由主函数调用其他函数，其他函数也可以互相调用。同一个函数可以被一个或多个函数调用任意多次。 在程序设计中，常将一些常用的功能模块编写成函数，放在函数库中供公共选用。要善于利用函数，以减少重复编写程序段的工作量。 函数分为全局函数、全局静态函数；在类中还可以定义构造函数、析构函数、拷贝构造函数、成员函数、友元函数、运算符重载函数、内联函数等。
关于函数计算中的函数，在各个云厂商中的定义：
- 阿里云
函数计算（Function Compute）是一个事件驱动的全托管 Serverless 计算服务，您无需管理服务器等基础设施，只需编写代码并上传，函数计算会为您准备好计算资源，并以弹性、可靠的方式运行您的代码。
腾讯云云函数（Serverless Cloud Function，SCF）是腾讯云为企业和开发者们提供的无服务器执行环境，帮助您在无需购买和管理服务器的情况下运行代码。您只需使用平台支持的语言编写核心代码并设置代码运行的条件，即可在腾讯云基础设施上弹性、安全地运行代码。SCF 是实时文件处理和数据处理等场景下理想的计算平台。
通过各个厂商的描述，“函数”这个词，貌似没有被单独解释，或者是被单独的描述，整体来看，“函数”在Serverless架构下，貌似是一个“函数即服务”的计算平台。
与传统的计算机编程中的函数对比，在Serverless架构下的Function，变得略微模糊。
函数就是函数
在zui开始，Serverless架构中的FaaS平台，通常都是针对编程语言提供对应的Runtime，例如Python3的运行时，Node.js12的运行时等，在这些FaaS平台中，针对这些运行时是有一个词汇叫做”函数入口“，所谓的函数入口指的就是我们一个相对明确的方法或者函数。
例如以Python为例，我们的函数入口可以定义成：文件名.方法名，具体来说可以是index.handler
此时对应的文件index.py就是：
handler(args1, args2):
pass
此时，当其被事件触发时，就会默认调用这个handler函数，并将对应的事件数据结构和上下文等作为参数传入。所以，在zui初的概念中，Function的概念或许真的就是指一个函数，这个函数有点类似于C语言中的main()
函数并不是函数
但是在实际发展过程中，我们会发现，真实情况下的Function，只是更加抽象的概念，并不是传统的函数概念，而是”对新鲜事物的一种特指“。
例如：
- 传统的某个语言Runtime为例，在其代码中不仅仅会有函数的入口，还可能存在初始化方法、结束方法，那么这里的函数到底是指的谁，这个事情就说不清楚了；
- 随着时间的发展，自定义运行时、自定义镜像等概念逐渐被提出，所谓的函数入口逐渐的变成了启动指令，例如阿里云的custom runtime的启动入口实际上是bootstrap中的启动命令，那么此时函数就不再是我们曾经说的函数了；
所谓的”一种特指“，实际上就是说他表示的一个服务，再或者说，他表示的是在Serverless架构下的计算平台中的”计算模块粒度“。这个模块的粒度：
- 它可以是一个单纯的函数，非常简单的一个方法；
- 它也可以是一个相对完整的功能，几个方法的结合，例如登录功能；
- 它还可以是几个功能的结合，形成一个简单的模块，例如登陆/注册模块；
- 它甚至可以是一个框架，例如在一个函数中，放下整个框架，如express、django等；
- 它甚至是一个完整的服务，例如某个blog系统（zblog，wordpress）等部署到一个函数中，对外提供服务；
“不求甚解”未尝不可
就我个人而言，在Serverless架构中，对函数的概念、定义，真的不能太较真。因为这个函数，有的时候或许和我们计算机编程的函数有些许类似，但是有的时候，这两者可能毫无关系，过分的纠结“我要将业务迁移到函数计算架构是不是要把业务打成函数的粒度”就太“得不偿失”了。
同样是函数，学习计算机编程的时候有函数，在接触Serverless架构的时候有函数，在学习数学的时候也有函数，此函数非彼函数，每个函数各有妙用，无需“强行对应”，更不必区分个所以然。
坦然面对“函数”
在Serverless架构下，我相对来说是比较推荐“具体情况具体分析、沉着面对”的思路。
往往有很多人在上Serverless架构的时候都在想“我应该如何面对函数“，是“一个服务对应一个函数”还是“一个功能对应一个函数”，再比如是“一个函数对应一个函数”？
其实站在我的角度来看，这个不用过分纠结，我们只需要遵循两个原则即可：
- 资源相似原则：所谓的资源相似指的是，当我们某个业务中，所对外暴露的接口是否对资源消耗类似。例如，某个后端服务，对外暴露10个接口，其中9个接口的内存只需要128M，超时只需要3秒；而另一个接口则需要2048M的内存与60秒的超时；此时我们可以认为前9个接口是资源相似的，可以放在“一个函数中实现”，zui后一个单独来放到一个函数中实现；
- 功能相似原则：所谓的功能相似指的是，当我们一个业务中，功能概念，定义相差非常大的时候，不太建议将这些功能放在一起。例如某个聊天系统，有一个聊天功能（Websocket），还有一套注册/登录功能，如果此时将两者融合到一起，其实在一定程度上会增加项目的复杂度，也不宜与后期管理；可以考虑拆分成聊天函数和注册/登陆函数；
如果说纠结如何面对“函数”，其实我觉得可以把他认为是一种哲学：
业务拆的太细：
- 函数太多，不易于管理；
- 业务出现问题，不便于排查具体情况；
- 会导致很多模块，配置重复使用；
- 在一定情况下会让冷启动变的比较频繁；
业务耦合的太严重：
- 现阶段下，容易产生比较大的资费问题；
- 在高并发的情况下，容易出现流量限制问题；
- 更新业务代码可能有较大的风险；
- 不便于调试等；
总结
zui不佳实践第一节：用函数要用到“不求甚解”，再到“了然于胸”。使用Serverless架构，不是较真能出效果的，往往“要根据业务具体情况”来进行处理，无论是目标为降低迁移/改造成本，还是说体验技术红利，再或者说是极客风。
Serverless架构没有明确的要求我们怎么做，所以适合自己的就是更好的。不求甚解，也许也是一种“zui佳”。
以上内容来源于网络，由“WiFi之家网”整理收藏！
评论