您的位置:  首页 > 技术杂谈 > 正文

一看即会:Serverless 应用开发的 7 个实战小技巧(文末附好礼)

2022-04-25 18:00 https://my.oschina.net/u/3874284/blog/5519250 阿里巴巴云原生 次阅读 条评论

image

作者:刘宇(花名:江昱)

作者说: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 平台之间传递的数据包有大小限制,所以一般使用这种上传方法的通常是上传头像等小文件的业务场景;
  • 第二种上传方法是,通过对象存储等平台来上传,因为客户端直接通过密钥等信息,来将文件直传到对象存储是有一定风险的。所以通常情况是客户端发起上传请求,函数计算根据请求内容进行预签名操作,并将预签名地址返回给客户端,客户端再使用指定的方法进行上传,上传完成之后,可以通过对象存储触发器等来对上传结果进行更新,详情如下图所示:

image

文件读写与持久化方法

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

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

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

慎用部分 Web 框架的特性

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

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

image

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

要注意应用组成结构

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

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

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

image

通过上表,我们可以明确看出,当合理的、适当地把业务进行拆分之后,会在一定程度上更节约成本,以上述例子来看,成本节约近 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
  • 通过开发者工具快速迁移/部署

image

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

image

详情可以参考:​​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 进行项目部署
🏄‍ Thanks for using Serverless-Devs
👉 You could [cd /Users/jiangyu/Desktop/fc-custom-lua-event/image-prediction-app/start-express] and enjoy your serverless journey!
🧭️ If you need help for this example, you can use [s -h] after you enter folder.
💞 Document ❤ Star:https://github.com/Serverless-Devs/Serverless-Devs

完成之后,可以进入项目并部署:

$ s deploy
framework: 
  region:   cn-beijing
  service: 
    name: web-framework
  function: 
    name:       express
    runtime:    custom
    handler:    index.handler
    memorySize: 128
    timeout:    60
  url: 
    system_url:    https://1583208943291465.cn-beijing.fc.aliyuncs.com/2016-08-15/proxy/web-framework/express/
    custom_domain: 
      - 
        domain: http://express.web-framework.1583208943291465.cn-beijing.fc.devsapp.net
  triggers: 
    - 
      type: http
      name: httpTrigger

此时可以通过浏览器打开页面:

image

此时,可以根据案例提供的 Bootstrap 以及 s.yaml 进行参考,并将自身的项目部署/迁移到阿里云 Serverless 架构。其中 Bootstrap 为:

#!/bin/bash
node index.js
其中 s.yaml 为:
# ------------------------------------
#   欢迎您使用阿里云函数计算 FC 组件进行项目开发
#   组件仓库地址/帮助文档:https://github.com/devsapp/fc
#   Yaml参考文档:https://github.com/devsapp/fc/blob/jiangyu-docs/docs/zh/yaml.md
#   关于:
#      - Serverless Devs和FC组件的关系、如何声明/部署多个函数、超过50M的代码包如何部署
#      - 关于.fcignore使用方法、工具中.s目录是做什么、函数进行build操作之后如何处理build的产物
#   等问题,可以参考文档:https://github.com/devsapp/fc/blob/jiangyu-docs/docs/zh/tips.md
#   关于如何做CICD等问题,可以参考:https://github.com/Serverless-Devs/Serverless-Devs/blob/master/docs/zh/cicd.md
#   有问题快来钉钉群问一下吧:33947367
# ------------------------------------
edition: 1.0.0          #  命令行YAML规范版本,遵循语义化版本(Semantic Versioning)规范
name: framework         #  项目名称
access: "default"       #  秘钥别名
services:
  framework: # 业务名称/模块名称
    component: fc  # 组件名称
    actions:
      pre-deploy: # 在deploy之前运行
        - run: npm install --production  # 要运行的命令行
          path: ./code # 命令行运行的路径
    props: # 组件的属性值
      region: cn-beijing
      service:
        name: web-framework
        description: 'Serverless Devs Web Framework Service'
      function:
        name: express
        description: 'Serverless Devs Web Framework Express Function'
        codeUri: './code'
        runtime: custom
        timeout: 60
        caPort: 9000
      triggers:
        - name: httpTrigger
          type: http
          config:
            authType: anonymous
            methods:
              - GET
      customDomains:
        - domainName: auto
          protocol: HTTP
          routeConfigs:
            - path: '/*'

可观测性

Serverless 应用的可观测性是被很多用户所关注的。可观测性是通过外部表现判断系统内部状态的衡量方式,在应用开发中,可观测性帮助判断系统内部的健康状况。在系统出现问题时,帮助定位问题、排查问题、分析问题;在系统平稳运行时,帮助评估风险,预测可能出现的问题。

在 Serverless 应用开发中,如果观察到函数的并发度持续升高,很可能是业务推广团队的努力工作导致业务规模迅速扩张,为了避免达到并发度限制触发流控,开发者就需要提前提升并发度,以阿里云函数计算为例,阿里云函数计算就在可观测性层面提供了多种纬度,包括 Logging、Metrics 以及 Tracing 等内容。

image

如图,在控制台监控中心,可以查看到整体的 Metrics,服务级 Metrics 以及每个函数的 Metrics。除此之外,还可以看到当前函数的请求记录:

image

根据不同的请求记录,我们可以查看到函数的详细信息:

image

除了在控制台的监控中心处可以查看到函数的日志等信息,在函数详情页面,也可以看到函数的详细日志信息:

image

以及 Tracing 相关信息:

image

当然,通过 Serverless Devs 开发者工具,以及函数计算组件也可以进行观测相关操作,下面我们来一起看一下是怎么进行的。

  • 通过工具进行 Metrics 查看

详情参考:

​https://github.com/devsapp/fc/blob/main/docs/zh/command/metrics.md​

  • 有资源描述文件(Yaml)时,可以直接执行 s metrics 查看函数的指标信息;
  • 纯命令行形式(在没有资源描述 Yaml 文件时),需要指定服务所在地区以及服务名称,函数名等,例如 sclifcmetrics--regionch-hangzhou--service-namemyService--function-namemyFunction;

上述命令的执行结果示例如下:

[2021-06-07T12:20:06.661] [INFO ] [FC-METRICS] - 请用浏览器访问Uri地址进行查看: http://localhost:3000

此时,通过浏览器打开地址,可以看到函数指标信息:

image

P.S.需要开启请求级别指标,才能查看函数指标信息,否则图表不展示数据。

关于如何开通请求级别指标:

1.​​https://fcnext.console.aliyun.com/​

2.服务及函数中-找到自己region-对应的服务名称-在操作栏点击配置开启请求级别指标

  • 通过工具进行 Logs 查看

详情参考:

​https://github.com/devsapp/fc/blob/main/docs/zh/command/logs.md​

  • 有资源描述文件(Yaml)时,可以直接执行s logs 进行线上函数的日志查询;
  • 纯命令行形式(在没有资源描述 Yaml 文件时),需要指定服务所在地区以及服务名称,函数名等,例如s cli fc logs --region cn-hangzhou --service-name fc-deploy-service --function-name http-trigger-py36

上述命令的执行结果示例:

FunctionCompute python3 runtime inited.

FC Invoke Start RequestId: 84d6ae81-02ff-4011-b3ca-45e65b210cc3
FC Invoke End RequestId: 84d6ae81-02ff-4011-b3ca-45e65b210cc3

FC Invoke Start RequestId: de4812be-9137-4a33-9869-370cb61ac427
FC Invoke End RequestId: de4812be-9137-4a33-9869-370cb61ac427

如果需要以 tail 模式进行日志的查询,可以增加 --tail 参数,例如 s logs --tail;

查询指定时间段的日志,可以通过增加 --start-time 和 --end-time 参数实现(例如 s logs -s 2021-11-04T15:40:00 -e 2021-11-04T15:45:00)

如何对应用进行调试

在应用开发过程中,或者应用开发完成,但是所执行结果不符合预期时,通常要进行一定的调试工作。但是在 Serverless 架构下,调试往往会受到极大的环境因素限制,有可能出现的情况是,所开发的应用在本地是可以比较健康的、符合预期的运行,但是在 FaaS 平台上,则会出现一些不可预测的问题;或者是在一些特殊的环境下,本地没有办法模拟线上环境,难以进行项目的开发和调试。

Serverless 应用调试被视为 Serverless 落地最大的痛点与挑战,但是各个云厂商并没有因此放弃在调试方向的不断深入探索。以阿里云函数计算为例目前就提供在线调试、本地调试等多种调试方案。一些具体的操作可参考 Serverless 公众号文章:<硬核调试实操 | 手把手带你实现 Serverless 断点调试>,这里就不再赘述啦。

结语

以上就是我在 Serverless 应用开发中的一些经验分享,Forrester 曾提出:Serverless 架构的兴起,让 FaaS (Function As A Service) 成为继 IaaS、PaaS、SaaS 之后一种新的云计算能力提供方式。未来也将会有大量主流企业的核心应用,从原来的主机架构迁移到 Serverless 架构。

Serverless 架构正当时,其已然开启从概念到实践的大规模落地之路,正如 Gartner 报告中的预测:到 2025 年,全球一半的企业将采用 FaaS 部署;

Serverless 不仅可以做到让开发者无需再管理服务器,无需再对资源做预估并考虑扩展;发挥降本提效,按量付费的优势,它能让你进入只专心在业务逻辑的状态,从而全面提升工作中的研发效能。

好啦,今天是世界读书日,感谢收听(阅读),希望我的分享能够对你有所帮助。 发布云原生技术最新资讯、汇集云原生技术最全内容,定期举办云原生活动、直播,阿里产品及用户最佳实践发布。与你并肩探索云原生技术点滴,分享你需要的云原生内容。

关注【阿里巴巴云原生】公众号,获取更多云原生实时资讯!

展开阅读全文
  • 0
    感动
  • 0
    路过
  • 0
    高兴
  • 0
    难过
  • 0
    搞笑
  • 0
    无聊
  • 0
    愤怒
  • 0
    同情
热度排行
友情链接