Serverless 开发速查手册 | Serverless 应用开发的 7 个实战小技巧

Serverless Devs /  上手实战 /  原作者: 江昱 /  来自: Serverless 开发速查手册 /  著作权归作者本人所有
  • 评论数

    0

  • 阅读数

    51

  • 收藏数

    0

作者:Shawhann 发表于 2022-4-24 11:39

前言:Serverless 架构下的应用开发,与传统架构的应用开发还是有比较大的区别点的,例如天然分布式架构会让很多框架丧失一定的 "便利性",无状态的特点又让很多 "传统架构下看起来再正常不过的操作" 变得异常风险。


所以本篇我会介绍一些在 Serverless 架构下,常见的应用开发注意事项,分享一些个人的实战经验心得。如果你在 Serverless 开发过程中遇到问题,不妨往下听听看吧。


关于应用开发的七个心得


1、如何上传文件


在传统 Web 框架中,上传文件是非常简单和便捷的,例如 Python 的 Flask 框架:


f = request.files['file']f.save('my_file_path')


但是在 Serverless 架构下,却不能直接上传文件,原因有以下几点:

  • 一些云平台的 API 网关触发器会将二进制文件转换成字符串;不便直接获取和存储;


  • 此外,API 网关与 FaaS 平台之间传递的数据包有大小限制,很多平台被限制在 6M;


  • FaaS 平台大都是无状态的,即使存储到当前实例中,也会随着实例释放而导致文件丢失;

因此,传统框架中常用的上传方案,是不太适合在 Serverless 架构中直接使用的。若是想在 Serverless 架构上传文件,可以尝试以下两种方法:

  • 一种是 BASE64 后上传,持久化到对象存储或者是 NAS 中,这种做法可能会触及到 API 网关与 FaaS 平台之间传递的数据包有大小限制,所以一般使用这种上传方法的通常是上传头像等小文件的业务场景;


  • 第二种上传方法是,通过对象存储等平台来上传,因为客户端直接通过密钥等信息,来将文件直传到对象存储是有一定风险的。所以通常情况是客户端发起上传请求,函数计算根据请求内容进行预签名操作,并将预签名地址返回给客户端,客户端再使用指定的方法进行上传,上传完成之后,可以通过对象存储触发器等来对上传结果进行更新,详情如下图所示:



2、文件读写与持久化方法


应用在执行过程中,可能会涉及到文件的读写操作,或者是一些文件的持久化操作。在传统的云主机模式下,通常情况下是可以直接读写文件,或者将文件持久化某个目录下,但是在 Serverless 架构下却并不是这样的。

由于 FaaS 平台是无状态的,并且用过之后会被销毁,所以文件如果需要持久化并不能直接持久化在实例中,可以选择持久化到其他的服务中,例如对象存储、NAS 等。

同时,在不配置 NAS 的情况下,FaaS 平台通常情况下之后 /tmp 目录具有可写权限,所以部分临时文件可以缓存在 /tmp 文件夹下。


3、慎用部分 Web 框架的特性


函数计算 FC 是请求级别的隔离,所以可以认为这个请求结束了,实例就有可能进入到一个 “静默” 的状态。在函数计算中,API 网关触发器通常是同步调用(以阿里云函数计算为例,通常只在定时触发器、OSS 事件触发器、MNS 主题触发器和 IoT 触发器等几种情况下是异步触发),这就意味着当 API 网关将结果返回给客户端的时候,整个函数就会进入 “静默” 状态,或者被销毁,而不是会继续执行完异步方法。

所以通常情况下像 Tornado 等框架就很难在 Serverless 架构下发挥其异步的作用。当然,如果使用者需要异步能力,可以参考云厂商所提供异步方法,还是以阿里云函数计算为例,阿里云函数计算为用户提供了一种异步调用能力,当函数的异步调用被触发后,函数计算会将触发事件放入内部队列中,并返回请求 ID,而具体的调用情况及函数执行状态将不会返回。如果用户希望获得异步调用的结果,可以通过配置异步调用目标来实现,详情如图中所示:



Serverless 架构下,应用一旦完成当前请求,就会进入到 “静默” 状态,实例甚至都会被销毁,所以这就导致一些自带定时任务的框架没有办法正常执行定时任务。因为函数计算通常是由事件触发,不会自主定时启动。例如 Egg 项目中设定了一个定时任务,但是在实际的函数计算中如果没有通过触发器触发该函数,那么该函数是不会被触发,函数也不会从内部自动启动来执行定时任务,所以此时可以使用各个云厂商为其 FaaS 平台提供的定时触发器,通过定时触发器触发指定方法,来替代定时任务。


4、要注意应用组成结构


在 Serverless 架构下,静态资源更应该在对象存储与 CDN 的加持下对外提供服务;否则所有的资源都在函数中,通过函数计算对外暴露,不仅仅会让函数的真实业务逻辑并发度降低,也会造成更多的成本支出。尤其是将一些已有的程序迁移到 Serverless 架构上,如 Wordpress 等,更是要注意将静态资源与业务逻辑进行拆分,不然在高并发的情况下,性能与成本都将会受到严格的考验。

在众多云厂商中,函数的收费标准都是依靠运行时间和配置的内存,以及产生的流量进行收费的。如果一个函数的内存设置不合理,会导致成本翻倍增加。因此我们既要保证内存设置合理,更要保证业务逻辑结构的可靠性。

以阿里云函数计算为例,当一个应用,有两个对外的接口,其中有一个接口的内存消耗在 128MB 以下,另一个接口的内存消耗稳定在 3000MB 左右。这两个接口,平均每天会被触发 10000 次,并且时间消耗均在 100ms。如果两个接口写到一个函数中,那么这个函数可能需要将内存设置在 3072MB,同时在用户请求内存消耗较少的接口时,在冷启动的情况下可能难以得到较好的性能表现;但是,如果两个接口分别写到两个函数中,那么两个函数内存分别设置成 128MB 以及 3072MB 即可:



通过上表,我们可以明确看出,当合理的、适当地把业务进行拆分之后,会在一定程度上更节约成本,以上述例子来看,成本节约近 50%!


5、传统框架迁移方案与策略


Serverless 的范围越来越广,它本质上来讲更像是一种设计理念,一种新的编程范式。在这种新的架构下,或者说新的编程范式下,使用全新的思路来做 Serverless 应用是再好不过的了。但是原生的 Serverless 开发框架是非常少的,以 Web 框架为例,目前的主流的 Web 框架 “均不支持 Serverless 模式部署”,一方面是要尝试接触 Serverless,一方面又没办法完全放弃传统框架,所以如何将传统框架更简单、更快速、更科学地部署到 Serverless 架构上是一个值得探讨的问题。下面我结合案例分享一下迁移思路:


  • 传统框架迁移案例


请求集成方案实际上就是把真实的 API 网关请求,直接透传给 FaaS 平台,而不在中途增加任何转换逻辑。以阿里云函数计算的 HTTP 函数为例,当开发者想要把传统框架(例如 Django,Flask,Express,Next.js 等)部署到阿里云函数计算平台上,并且体验 Serverless 带来的按量付费,弹性伸缩等便捷优势。

得益于阿里云函数计算的 HTTP 函数和 HTTP 触发器,开发者不仅可以快速、简单地将框架部署到阿里云函数计算,更可以保持和传统开发一样的体验。以 Python 的 Bottle 框架为例,当我们开发一个 Bottle 项目之后:

# index.pypimport bottle
@bottle.route('/hello/<name>')def index(name): return "Hello world"
if __name__ == '__main__': bottle.run(host='localhost', port=8080, debug=True)

可以直接在本地进行调试。当想要把该项目部署到阿里云函数计算上,只需要增加一个 default_app 的对象即可:

app=bottle.default_app()

整个项目:

# index.pyimport bottle
@bottle.route('/hello/<name>')def index(name): return "Hello world"
app = bottle.default_app()

路过

雷人

握手
1

鲜花

鸡蛋

刚表态过的朋友 (1 人)

收藏 分享 邀请

暂无相关评论

文明上网理性发言,全站可见,请文明发言 评论
Archiver|小黑屋|Serverless Devs
Powered by Discuz! X3.4  © 2014-2020 Comsenz Inc.