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