函数计算对业务进行优化的思路

函数计算简介

函数计算（Function as a Service，FaaS）是一种云计算服务模型，它将应用程序的开发和部署从基础设施管理中解放出来，开发者只需关注代码的编写，而无需担心服务器的运维。

以上为比较官方的理解，我的理解就是 一次性的容器（运维不用操心），代码传上去就行，一般来说就是单一功能的处理。实践了阿里云的 fc 之后，发现其实也是要操心一些基础的运维参数，比如超时时间，cpu跟磁盘用多少合适。但相对于传统运维，已经算是精简了不少。

fc 的主要特点

优点还挺多的

• 付费规则基本就是，按量付费，特别适合突发，量少，但是特别耗费资源的一些任务，比如（大批量的图片打包压缩）…
• 运维省心，自动横向扩展，根据厂商开发实力，基本能做到快速启动
• 事件/http 驱动、接入现有系统很方便

缺点同样突出

• 无法避免的冷启动延迟；
• 因为 执行时间的限制 （阿里 fc 最高10分钟），长时间 job 与定时任务不适合使用。
• 函数计算是无状态的，无法共享本地资源。
• 开发环境不友好，语言以及版本依赖会有限制。
• 项目整体迁移上去，要考虑每一个请求对于资源的要求，比较麻烦。
• 监控跟调试就看云厂商的能力了，大批量使用成本不一定会低。

fc 的应用场景

我认为主要应用场景，就是事件驱动的任务，各类耗资源的轻量级 job 都可以转为 fc 执行

fc 在项目中的实践

• 需求：需要将客户当月的照片/视频，根据各种属性，打包成特定目录 zip 并发送给客户邮箱
  • 第一版本的思路，开启 job ，将 下载，打包的工作交给 job,问题就出现了，
    1. 服务器与oss 不在同一网络内，使用外网下载，速度慢，耗费网络资源
    2. 打包出来的文件高达几百M，磁盘读写压力大，多用户执行就更慢了
    3. php 单进程的网络请求处理，加上 laravel job 的 超时时间控制，整个功能的体验就很差
• 后续的方案思考
  • 第一个就是做 任务拆分，多 job 执行，启动一个定时 job 去控制整体的进度，解决了中断与超时问题，但是资源耗费解决不了，执行起来写代码也麻烦。
  • 第二个就是上 fc ，把网络下载打包，交由fc 执行，上传后响应 链接给 job,改动最小，fc 选用了golang 来写，并发下载，选择同一网络部署，减少网络消耗。

很显然，在这种场景下，fc 完美的解决了，时间慢与资源消耗的问题，最终的结果就是，任务执行时间缩短到原来的 1/10 , cpu&磁盘 资源消耗也没了。因为调用次数有限，所以费用也非常低。

总结

架构这个东西，还是要看业务，需要什么用什么。
软件开发没有银弹/(ㄒoㄒ)/~~