对数函数运算的性质，对数函数的基本运算例题

如果说近两年云计算领域最火的那些名词，可能非“云原生”和“无服务器”莫属。现在如果在云计算领域聊天，中间不谈云原生和无服务器，几乎会被“甩在后面”。

如今，随着无服务器架构的发展，我们不得不面对一个词：FaaS。

所谓FaaS是Functions as a Service的简称，翻译成国内云厂商的产品有：函数计算、云函数等。

毫无疑问，这里有一个共同点，就是这些产品或多或少与功能有“纠葛”。那么这里面有什么作用呢？是我们曾经认识的“二狗”，还是“二狗变了”？

定义对比在百度百科中，传统编程领域的函数定义为：

函数是指可以被另一个程序或代码直接引用的程序或代码。也称为子例程和方法。一般一个比较大的程序要分成几个程序块，每个模块用来实现一个特定的功能。所有的高级语言都有子程序的概念，模块的功能都是通过子程序来实现的。在C语言中，子程序的功能由一个主函数和几个函数组成。主函数调用其他函数，其他函数也可以互相调用。同一个函数可以被一个或多个函数调用任意次。在编程中，经常会把一些常用的功能模块写成函数，放在函数库中供公众选择。善于利用函数减少重复编写程序段的工作量。函数分为全局函数和全局静态函数；还可以定义构造函数、析构函数、复制构造函数、成员函数、友元函数、运算符重载函数、内联函数等。在一个班里。

关于函数计算中的函数，各个云厂商的定义是：

阿里云计算是一种事件驱动的完全托管的无服务器计算服务。你不需要管理服务器等基础设施，只需要编写和上传你的代码。函数计算将为您准备计算资源，并以灵活可靠的方式运行您的代码。

腾讯云云功能是腾讯云为企业和开发者提供的无服务器执行环境，帮助你运行代码，无需购买和管理服务器。你只需要用平台支持的语言编写核心代码，并设置代码运行的条件，就可以在腾讯云基础设施上灵活安全地运行代码。SCF是实时文件处理和数据处理场景中的理想计算平台。

根据各厂商的描述，“功能”二字似乎不用单独解释或描述。整体来看，“功能”似乎是无服务器架构下的“功能即服务”计算平台。

与传统计算机编程中的功能相比，无服务器架构中的功能变得有些模糊。

函数是函数的开始。无服务器架构的FaaS平台通常会为编程语言提供相应的运行时，比如Python3的运行时，Node.js12的运行时等。在这些FaaS平台中，对于这些运行时，有一个词叫做“函数入口”。所谓函数入口，是指相对明确的方法或函数。

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

此时，对应的文件index.py是：

Handler(args1，args2):此时传递，当被事件触发时，默认会调用这个Handler函数，相应的事件数据结构和上下文作为参数传入。所以在最初的概念中，函数的概念可能真的是指一个函数，有点类似于C语言中的main()。

函数不是函数，但在实际的开发过程中，我们会发现，真实情境中的函数只是一个更抽象的概念，不是传统的函数概念，而是“对某种新事物的具体指代”。

例如：

以传统语言Runtime为例。在它的代码中，不仅会有函数的入口，还会有初始化方法和结束方法。所以不清楚这里的函数指的是谁。随着时间的发展，自定义运行时、自定义镜像等概念。已经逐渐被提出来了，所谓的函数入口也逐渐变成了引导命令。比如阿里云自定义运行时的引导入口，其实就是bootstrap中的引导命令，所以函数不再是我们曾经说的函数；所谓“一个具体的引用”，其实就是他所代表的一个服务，或者说无服务器架构下的计算平台中的“计算模块粒度”。该模块的粒度：

它可以是一个简单的函数，一个非常简单的方法；也可以是比较完整的功能，几种方法的组合，比如登录功能；也可以是几个功能的组合，形成一个简单的模块，比如登录/注册模块；甚至可以是一个框架，比如在一个函数里，放下整个框架，比如express，dj

ango等；它甚至是一个完整的服务，例如某个blog系统等部署到一个函数中，对外提供服务；“不求甚解”未尝不可

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

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

坦然面对“函数”

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

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

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

资源相似原则：所谓的资源相似指的是，当我们某个业务中，所对外暴露的接口是否对资源消耗类似。例如，某个后端服务，对外暴露10个接口，其中9个接口的内存只需要128M，超时只需要3秒；而另一个接口则需要2048M的内存与60秒的超时；此时我们可以认为前9个接口是资源相似的，可以放在“一个函数中实现”，最后一个单独来放到一个函数中实现；功能相似原则：所谓的功能相似指的是，当我们一个业务中，功能概念，定义相差非常大的时候，不太建议将这些功能放在一起。例如某个聊天系统，有一个聊天功能，还有一套注册/登录功能，如果此时将两者融合到一起，其实在一定程度上会增加项目的复杂度，也不宜与后期管理；可以考虑拆分成聊天函数和注册/登陆函数；

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

业务拆的太细：

函数太多，不易于管理；业务出现问题，不便于排查具体情况；会导致很多模块，配置重复使用；在一定情况下会让冷启动变的比较频繁；

业务耦合的太严重：

现阶段下，容易产生比较大的资费问题；在高并发的情况下，容易出现流量限制问题；更新业务代码可能有较大的风险；不便于调试等；总结

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

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