利与弊-多个接口要分成多个函数还是写到一个函数中

anycodes4个月前日常分享4291

我们在做一个项目的时候,会有多个函数/方法,这个是一个很常见的事情,就算不按照函数/方法来划分,也通常会有多个功能,以一个简单的博客为例,可能拥有最基础的:

  • 获取分类列表
  • 获取文章列表(默认/通过标签/通过分类/通过推荐)
  • 获取标签列表
  • 获取文章详情
  • 获取评论列表
  • 文章评论接口

在传统的Web项目开发过程中,作为一个后台研发,我可能要做的事情是新建一个项目,然后在这个项目中实现不同的方法/功能,但是在Serverless架构下,可能就会让人有点疑惑:我是一个函数实现这些所有功能?还是每个函数实现其中一个功能?还是某几个功能用一个函数实现,另外几个功能用其他函数实现呢?

其实我个人认为,这并没有一个标准答案,或者更多的时候是应该根据项目本身的需求来制定。接下来,我就个人经验简单的说一下个人想法:函数过多,会导致管理困难;一个函数内功能过多,会导致后期定位问题困难(在指无额外的日志系统的情况下),同时也可能会因为不同函数所需资源不同导致成本增加。

所以我认为同类型的方法/功能,且资源消耗在同一水准的,放在一个函数中,例如上面的例子中:获取分类列表,获取文章列表(默认/通过标签/通过分类),获取标签列表,获取文章详情,获取评论列表等接口就可以放在一起,这类接口相对来说都是一个类型,且对资源消耗不大,如果想把文章评论接口放入其中,也是可以的。但是获取文章列表(通过推荐),就不是非常推荐和上面的接口放在同一个函数中,因为一般情况下通过推荐可能需要有一定机器学习算法,可能会对资源需求比较大。当然,我这个只是举了一个简单例子而已,如果有的人认为自己的博客获取文章列表(通过推荐)是通过分类/标签来实现的,那么也完全可以将上面的所有功能放在一个函数中实现,所以我一直在强调,更多根据业务需求而定,但是有一点可以肯定的是:资源消耗一定是值得考虑的一个因素。

那么就我个人的经验而言,对上面的个人观点进行细化就是:

在Serverless架构下,各个功能/函数分开放,和放一起都会有哪些区别呢?主要区别是:

  • 如果一个项目有100个方法,那么我们建立100个函数,每个函数对应1一个api网关,我们在后期维护的时候,是不是非常困难,甚至说,我们有好多代码要进行重复部署?除此之外,如果这100个方法都有数据库的操作,那么我先同时请求前50个接口,再同时请求后50个接口,如果说是100个方法放在了100个函数中,那么这个时候就要启动100个实例来应对,如果说这100个方法,完全可以放在一个函数中,那么我再用同样的方法请求,实际上50个实例就可以应对这先后一共100个请求。如果这些方法都需要对数据库进行相关操作,那么前者可能要就要与数据库存在100个链接对象,后者可能只需要50个。(当然,我这个分析是建立在一个前提条件:存在容器复用,且下一波请求过来的时候,前一波启动的容器并没有被释放,并且也顺利的复用了之前的容器;可能这个前提有一点极端/特殊,但是不可否认这个前提是合理的);

  • 对于部分厂商,函数拥有实力上限,以腾讯云的SCF为例,其函数上限默认为300(也可以通过提交工单增加),如果10个功能放在一个函数中,那么这10个功能每个功能并发31,则会出现10个请求是超限的,如果是10个功能分开放,即使这10个功能每个功能并发200也不会超限,当然,这种情况更和厂商给予的某些特性/限制相关;

  • 如果我们有21个函数,20个函数资源消耗是64M一下,有一个函数资源消耗要1024M左右,如果这些函数都放在一起,每个函数并发1,被请求1次,并且计费时间都是1秒,则计费资源可能是(因为不同厂商计费算法不一致,此处仅以腾讯云SCF为例)21 * 1024 = 21504,如果按照同类资源消耗放在一起的原则,则是20 * 64 + 1 * 1024 = 2264,可以看到后者的实际资源消耗奖金前者的1/10,而资源消耗与计费相关,所以后者相对来说也会更加节约成本;

  • 日志相关的区别,如果多个功能放在同一个函数中,后期通过日志定位问题就比较困难,而不同方法放在不同函数中,出现问题定位的会相对容易;当然,如果接入到了日志系统会变得相对容易,这个区别可以忽略;

  • 如果多个功能放在一个函数中,在函数被复用的情况下,如果前一次执行有一些资源没被释放,可能会对本次请求中的部分资源造成污染;当然如果对这类资源处理不当,就算是一个功能一个函数,也可能出问题;

而针对这些区别,我个人认为的"中庸之道"即是采用最后一种方案:对功能进行分类,然后在这个基础上再对资源需求等级进行划分,在不同范围内的资源被编辑到一个函数中。当然,可能实际情况还要以也许需求/特性为主,但是这种方法,无疑是比较"优"和"折中"的。


作者简介:刘宇,毕业于浙江大学,硕士学历,目前在腾讯工作,著有《Serverless 架构》一书,是Serverless架构的热衷者,曾做一款叫Anycodes的软件,目前下载超过100万次。

相关文章

利与弊-传统框架要不要部署在Serverless架构上

利与弊-传统框架要不要部署在Serverless架构上

Serverless架构发展的速度可以说是非常的迅速,而且Serverless的发展也是有一套自己的独特的打法,这种打法在一定程度上,让很多开发者不适应,尤其是传统的Web框架无法在Serverles...

云函数中使用Python-ORM: Peewee

云函数中使用Python-ORM: Peewee

前言 ORM(Object Ralational Mapping,对象关系映射)用来把对象模型表示的对象映射到基于SQL的关系模型数据库结构中去。这样,我们在具体的操作实体对象的时候,就不需要再去和...

serverless-git和serverless-cicd

serverless-git和serverless-cicd

前言 传统情况下,我们写完代码,可能面对两个事情:发布到代码仓库以及部署到线上,传统的我们会手动实现这些操作,出现误操作的概率也是蛮高的,相对来说也是比较机械化的工作。CICD的引入,大大改善了持续...

用Serverlss部署一个基于深度学习的古诗词生成API

用Serverlss部署一个基于深度学习的古诗词生成API

第六篇:用Serverlss部署一个基于深度学习的古诗词生成API 前言 古诗词是中国文化殿堂的瑰宝,记得曾经在韩国做Exchange Student的时候,看到他们学习我们的古诗词,有中文的还有...

基于Serverless的验证码识别API

基于Serverless的验证码识别API

前言 之前和大家分享了很多的CV相关的例子,被很多小伙伴吐槽说我是调包侠,还连累了Serverless被很多人误以为也仅仅能"调包玩一玩",其实在Serverless中,开发者的自由度还是非常大的,...

基于Serverless架构的Git代码统计工具

基于Serverless架构的Git代码统计工具

前言 自己毕业也有一年多了,很想统计一下过去一年自己贡献了多少的代码。想了一下,可能要用git log,简单的做了一下,感觉不是很爽,正直自己想通过Serverless做一个工具合集,就想能不能...

2020年函数计算的冷启动怎么样了

2020年函数计算的冷启动怎么样了

前言 自从Serverless架构被提出,函数计算这个名词变得越发的火热,甚至在很多时候有人会认为Serverless就是函数计算。 作为Serverless架构中的一个重要组成部分,云函数确...

评论列表

ycp424c
2020-05-26 15:13:40

不考虑实现的情况下,感觉 每个方法一个函数+不同示例共享db连接池(比如一个调高并发的函数专门连db,其他函数调用他)+更先进的多函数管理方式 = 理想方案

发表评论    

◎欢迎参与讨论,请在这里发表您的看法、交流您的观点。
嘿,一起Serverless