一看即会：Serverless 应用开发的 7 个实战小技巧（文末附好礼）

作者：刘宇（花名：江昱）

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

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

关于应用开发的 7 个心得

如何上传文件

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

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

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

• 一些云平台的 API 网关触发器会将二进制文件转换成字符串；不便直接获取和存储；
• 此外，API 网关与 FaaS 平台之间传递的数据包有大小限制，很多平台被限制在 6M；
• FaaS 平台大都是无状态的，即使存储到当前实例中，也会随着实例释放而导致文件丢失；

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

• 一种是 BASE64 后上传，持久化到对象存储或者是 NAS 中，这种做法可能会触及到 API 网关与 FaaS 平台之间传递的数据包有大小限制，所以一般使用这种上传方法的通常是上传头像等小文件的业务场景；
• 第二种上传方法是，通过对象存储等平台来上传，因为客户端直接通过密钥等信息，来将文件直传到对象存储是有一定风险的。所以通常情况是客户端发起上传请求，函数计算根据请求内容进行预签名操作，并将预签名地址返回给客户端，客户端再使用指定的方法进行上传，上传完成之后，可以通过对象存储触发器等来对上传结果进行更新，详情如下图所示：

文件读写与持久化方法

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

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

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

慎用部分 Web 框架的特性

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

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

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

要注意应用组成结构

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

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

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

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

传统框架迁移方案与策略

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

• 传统框架迁移案例

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

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

# index.pyp
import 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.py
import bottle
@bottle.route('/hello/<name>')
def index(name):
    return "Hello world"
app = bottle.default_app()
if __name__ == '__main__':
    bottle.run(host='localhost', port=8080, debug=True)

此时，在阿里云函数计算平台，创建函数时，将函数入口设置为：index.app 即可。除了 Bottle 之外，其他的 Web 框架的操作方法是类似的，再以 Flask 为例：

# index.py
from flask import Flask
app = Flask(__name__)
@app.route('/')
def hello_world():
    return 'Hello, World!'
   
if __name__ == '__main__':
    app.run(
        host="0.0.0.0",
        port=int("8001")
)

在配置函数的时候写上入口函数为：index.app 即可，就可以保证该 Flask 项目运行在函数计算平台上。

当然，除了使用已有的语言化的 Runtime，还可以考虑使用 Custom Runtime 和 Custom Container 来实现，例如，一个 Web 项目完成之后，可以编写一个 Bootstrap 文件（在 Bootstrap 文件中写一些启动命令即可），例如我要启动一个 Express 的项目，我把我的 Express 项目准备完成之后，可以直接通过 Bootstrap 为：

#!/usr/bin/env bash
export PORT=9000
npm run star

• 通过开发者工具快速迁移/部署

如果通过开发者工具进行传统框架的支持，可以直接通过 Serverless Devs 的命令，进行案例的项目的创建。目前 Serverless Devs 已经支持以下框架：

详情可以参考：​​https://github.com/devsapp/start-web-framework​​

以 Express 项目为例，可以在命令行工具执行：

s init start-express

即可进行项目的初始化：

_____                             
    |  ___|                            
    | |____  ___ __  _ __ ___  ___ ___ 
    |  __\ / / '_ | '__/ _ / __/ __|
    | |___>  <| |_) | | |  __/__ __ \
    ____/_/_\ .__/|_|  ___||___/___/
              | |                      
              |_|                      
                                        
? please select credential alias default
    Welcome to the start-express application
     This application requires to open these services: 
         FC : https://fc.console.aliyun.com/
     Express development docs: https://www.expressjs.com.cn/4x/api.html
     * 额外说明：s.yaml中声明了actions：
        部署前执行：npm install --production
       如果遇到npm命令找不到等问题，可以适当进行手动项目构建，并根据需要取消actions内容 
     * 项目初始化完成，您可以直接进入项目目录下，并使用 s deploy 进行项目部署
标签：Serverless,__,架构,函数,框架,附好,文末,name	

来源： https://www.cnblogs.com/alisystemsoftware/p/16191210.html