Serverless 下函数应用架构升级

1. SERVERLESS 函数应用架构升级 Upgrade methodology for next-generation function architecture

2. 陈仲寅（花名：张挺）就职于阿里巴巴淘系技术部前端架构团队负责制定集团 Serverless 规范，以及参与各个平台，工具链，在协议和 API 层面的一致性落地。

3. 所有人都在说 Serverless；几乎没人知道怎么落地 Serverless；但是大家都觉得其他人在大力做 Serverless；所以大家都宣称自己在做 Serverless；我没说过

4. 云厂商：我们在定义 Serverless 开发者：我们在做 Serverless 各用户：我们在用 Serverless

5. 为什什么给前端引进 Serverless 01 更更快的开发速度 03 按量量付费基于事件驱动模型，⽅方便便的快速迭代，快速部署，轻松上线。函数的计费模型和传统有着本质的区别，可以让轻量量服务减轻资⾦金金压⼒力力。 02 安全的隔离环境 04 ⾃自动扩展实例例请求隔离的运⾏行行时环境，⽆无状态的架构，不不需要再登录机器器，升级模块包依赖。⽐比传统应⽤用更更为弹性，不不需要提前预估流量量，评估分析。

6. Serverless 给前端带来价值 1 可以减少前端开发成本，弱化运维 2 前端可以更多的参与业务交付，提升发展空间 3 为前端跨技术栈提供研发效能提升

7. 我们希望在几年之后，所有的前端开发工程师，能够转变为互联网（前台）应用开发工程师。

8. 如果前端要尝试运行一些 Serverless 代码，那么他会？

9. 如果前端要尝试运行一些 Serverless 代码，那么他会？使用一些成熟的云厂商提供的服务，比如 AWS Lambda 或则国内的阿里云或者腾讯云。使用自己从头搭建的 Serverless 环境。

10. 现在的 Serverless ⼚厂商 1 业界有⾮非常多的云⼚厂商提供 Serverless 服务 2 每个云⼚厂商有⼀一套标准和参数规范 3 每个云⼚厂商都会在⾃自有的标准之上为了了吸引⽤用户做了了很多创新

11. AWS 两段式加载 hot reload initialize code 预热异步返回 GCF FC SCF

12. 前端用户诉求 1 简化平台选择成本，快速进入开发。 2 寻求跨平台方案，避免被厂商锁定。

13. 1 通过定义，一定程度上解决了跨平台问题 2 通过插件扩展，多平台的部署支持

14. 1 通过定义，一定程度上解决了跨平台问题 1 没有解决不同平台代码写法不一致的问题 2 通过插件扩展，多平台的部署支持 2 插件生态依靠各个厂家自觉，支持力度不一

15. 1 快速部署 Web 服务到云平台，多为前端 Web 页面，定位有差异

16. 我们希望什么样的 Serverless Framework 呢？

17. 我们的 Serverless Framework 所具备的能⼒力力 1 3 防厂商锁定 2 灵活性 Avoid Vendor Lock-in Flexibility 现在的 FaaS 还没有一个固定的标准，使用时会担心固化在特函数框架支持灵活的部署模式，可以在垂直和水平两方面进定平台，后续无法迁移，我们希望思考和解决这个问题。行按需拆分和组合。开发效率 4 生命周期扩展 Development Eﬃciency Lifecycle Extension 提升开发效率，在快速迭代业务的同时，尽可能标准在平台运行时和用户代码之间，设计一层通用的运行时扩展能化，易解耦，可扩展和复用。力，在统计埋点，提前加载模块等类似场景上提供支持。

18. 我们的 Serverless Framework 所具备的能⼒力力 1 3 防厂商锁定 2 灵活性 Avoid Vendor Lock-in Flexibility 现在的 FaaS 还没有一个固定的标准，使用时会担心固化在特函数框架支持灵活的部署模式，可以在垂直和水平两方面进定平台，后续无法迁移，我们希望思考和解决这个问题。行按需拆分和组合。开发效率 4 生命周期扩展 Development Eﬃciency Lifecycle Extension 提升开发效率，在快速迭代业务的同时，尽可能标准在平台运行时和用户代码之间，设计一层通用的运行时扩展能化，易解耦，可扩展和复用。力，在统计埋点，提前加载模块等类似场景上提供支持。

19. 1 防⼚厂商锁定 Avoid Vendor Lock-in req, res, context event, context, callback event, context, callback Aliyun 腾讯云 … event, context AWS 不同的云厂商有着不一致的标准。

20. 1 防⼚厂商锁定 Avoid Vendor Lock-in 社区云⼚厂商规范 Serverless 插件 Serverless 工具采用定义 serverless.yml 文件的形式来解决这个问题。受厂商的影响比较大，每个厂商的标准很难统一。 Serverless

21. 1 防⼚厂商锁定 Avoid Vendor Lock-in 标准化 serverless.yml Serverless 插件标准化平台参数在 Serverless 的插件基础上，进一步标准化和扩展。

22. 标准化 serverless.yml 以前，我们使⽤用不不同平台的 serverless.yml ⽂文件来部署，⾥里里⾯面的格式和内容是由云⼚厂商插件来定义的。这些云⼚厂商提供的能⼒力力有⼀一定相似性，我们希望尽可能⽤用同⼀一份 yml ⽂文件来定义这些内容。标准定义扩展⽤用⼀一份定义⽣生成不不同平台的 spec 的形式，并在其中尽可能固化相同的字段，并且扩展我们⾃自⼰己的字段。

23. 标准化 serverless.yml 以前，我们使⽤用不不同平台的 serverless.yml ⽂文件来部署，⾥里里⾯面的格式和内容是由云⼚厂商插件来定义的。这些云⼚厂商提供的能⼒力力有⼀一定相似性，我们希望尽可能⽤用同⼀一份 yml ⽂文件来定义这些内容。 Aliyun template.yml Tencent AWS spec.yml Serverless.yml spec.yml …

24. 标准化平台出⼊入参 callback Promise req, res FaaSContext context FaaSContext.originContext

25. 标准化平台出⼊入参 callback Promise req, res FaaSContext context FaaSContext.originContext Args Wrapper async ( FaaSContext, event ) 通过针对不同的入口，开发不同的 wrapper，让参数更标准，开发成本更低

26. 标准化平台出⼊入参 User Code 构建产物 serverless.yml Args Wrapper

27. 标准化平台出⼊入参构建产物

28. 产出标准定义通过标准化不同平台触发器，我们产出了一套可沉淀，可校验的 interface，帮助我们在支持多平台时走的更快更远。 1 基于开源的 Serverless ⼯工具开发，复⽤用现有 Serverless 插件能⼒力力和社区⽣生态 2 每个平台，相同的地⽅方保持⼀一致，不不同的触发器器上独⽴立扩展，有完整定义 3 扩展开发、调试、部署的⾃自有能⼒力力

29. 发布到多个平台

30. 我们的 Serverless Framework 所具备的能⼒力力 1 3 防厂商锁定 2 灵活性 Avoid Vendor Lock-in Flexibility 现在的 FaaS 还没有一个固定的标准，使用时会担心固化在特函数框架支持灵活的部署模式，可以在垂直和水平两方面进定平台，后续无法迁移，我们希望思考和解决这个问题。行按需拆分和组合。开发效率 4 生命周期扩展 Development Eﬃciency Lifecycle Extension 提升开发效率，在快速迭代业务的同时，尽可能标准在平台运行时和用户代码之间，设计一层通用的运行时扩展能化，易解耦，可扩展和复用。力，在统计埋点，提前加载模块等类似场景上提供支持。

31. 2 灵活性 Flexibility 所谓的 Flexibility，是我们对未来的一种美好愿景，这不仅仅体现在开发上，也体现在部署上。

32. 举例例：传统 Web 应⽤用场景 1 需要开发多个函数 2 每个函数可以绑定到一个或者多个路由 3 每个路由的调用频次不同按传统模型，这样的多个函数代码将部署到多个容器中。

33. 函数的计费模型总价 = 调用次数 + 资源消耗（CU) 资源的消耗跟 CPU，内存密切相关，很难控制。核心诉求：在一定程度上减少总成本。

34. 灵活性的诉求提升资源利用率每个函数的资源利用率不高，每次请求都会触发冷启动，影响体验。降低部署相对成本部署到云平台，云平台减少内部调度、发布的成本，进而影响总成本。未来的扩展性增加函数内部互调、热点函数迁移，代码逻辑复用的可能性。

35. 灵活性 Flexibility 2 传统 FaaS 部署模型 fn fn fn fn fn fn fn fn fn fn fn fn 所谓的 Flexibility，是我们对未来的⼀一种美好愿景，这不不仅仅体现在开发上，也在部署上提现。

36. 2 传统 FaaS 部署模型 fn fn fn 灵活性 Flexibility 理理想：资源复⽤用型 FaaS 部署模型 fn fn fn fn fn fn fn fn fn fn fn fn fn fn fn fn fn fn fn fn fn fn fn fn fn fn fn fn fn fn fn fn fn fn fn fn fn fn fn 所谓的 Flexibility，是我们对未来的⼀一种美好愿景，这不不仅仅体现在开发上，也在部署上提现。

37. 函数横向聚合能⼒力力云平台 Fn Fn Fn Fn Fn POD 1 POD 2 POD 3 POD 4 POD 5 按传统模型，这样的多个函数代码将部署到多个容器中。

38. 函数横向聚合能⼒力力云平台 Fn Fn Fn Fn POD 1 通过调整，我们的函数能够部署到同一个容器中。 Fn

39. 函数横向聚合能⼒力力云平台 Fn Fn POD 1 Fn Fn POD 2 通过调整，我们希望能随意拆分函数的部署结构，成本如何？？ Fn POD 3

40. Fn 1 Fn Fn POD 2 随意拆分函数的部署结构，成本如何？？ Fn POD 3 代码⽆无需变化

41.

42. 我们的 Serverless Framework 所具备的能⼒力力 1 3 防厂商锁定 2 灵活性 Avoid Vendor Lock-in Flexibility 现在的 FaaS 还没有一个固定的标准，使用时会担心固化在特函数框架支持灵活的部署模式，可以在垂直和水平两方面进定平台，后续无法迁移，我们希望思考和解决这个问题。行按需拆分和组合。开发效率 4 生命周期扩展 Development Eﬃciency Lifecycle Extension 提升开发效率，在快速迭代业务的同时，尽可能标准在平台运行时和用户代码之间，设计一层通用的运行时扩展能化，易解耦，可扩展和复用。力，在统计埋点，提前加载模块等类似场景上提供支持。

43. 3 开发效率 Development Eﬃciency } 函数入参入口方法 } } 函数逻辑传统开发模型

44. 开发效率和团队规模的对⽐比⼩小团队规模⼤大低协作复杂度⾼高

45. so IMPORT TYPESCRIPT context: FaaSContext 1 兼容多触发器器的⼊入参 2 定义 ctx 字段，降低开发成本

46. 多场景与传承 midway midway-faas 能⼒力力 midway Koa midway FaaS midway能⼒力力提供基于 egg 的 TypeScript 解决方案，结合 IoC 将用户代码彻底解耦，更在之上提供了更多灵活性支持。 midway core midway ORM midway Express 基于 IoC ，为 FaaS 场景提供业务逻辑复用等能力，并在跨平台，多终端集成等场景中提供标准化支持。

47. so 实现⼀一个⼩小⽽而美的 FaaS 框架 Midway For Egg 600 line Midway For Koa 220 line Midway For Express 240 line Midway For FaaS 160 line 符合全栈场景的框架，⽀支持 koa 作为基础框架，⽀支持 express 作为基础框极简的 for FaaS 场景⽀支持 egg 插件体系的完包含最简单单进程场景的架，包含最简单单进程场的⽀支持 IoC 的最⼩小框架整版本。 midway 适配版本。景的 midway 适配版本。版本。 Selected

48. USE DECORATOR 使⽤用装饰器器

49. 我们的 Serverless Framework 所具备的能⼒力力 1 3 防厂商锁定 2 灵活性 Avoid Vendor Lock-in Flexibility 现在的 FaaS 还没有一个固定的标准，使用时会担心固化在特函数框架支持灵活的部署模式，可以在垂直和水平两方面进定平台，后续无法迁移，我们希望思考和解决这个问题。行按需拆分和组合。开发效率 4 生命周期扩展 Development Eﬃciency Lifecycle Extension 提升开发效率，在快速迭代业务的同时，尽可能标准在平台运行时和用户代码之间，设计一层通用的运行时扩展能化，易解耦，可扩展和复用。力，在统计埋点，提前加载模块等类似场景上提供支持。

50. User claims 用户诉求 1 2 3 在不不同的函数调⽤用前执⾏行行相同的逻辑抹平函数执⾏行行前的初始化差异其他开发者需求（统⼀一治理理、监控⽇日志） Internal runtime ?? User Function Code

51. RuntimeStart Internal runtime ?? FunctionStart beforeInvoke Mounted Invoke beforeInvoke User Function Code Close End

52. 运行时扩展 RuntimeStart FunctionStart beforeInvoke Mounted Layer LightRuntime Invoke Runtime-engine beforeInvoke Close End

53. 运行时扩展 FC-runtime-adapter SCF-runtime-adapter AWS-runtime-adapter Layer LightRuntime … Runtime-engine LightRuntime 的上层实现用于处理不同平台的兼容性。

54. 运行时扩展 FC-runtime-adapter 传统场景兼容 SCF-runtime-adapter AWS-runtime-adapter Layer LightRuntime … Runtime-engine Layer 用于针对运行时做扩展，方便在多个运行时中复用能力。通⽤用能⼒力力复⽤用

55. 经历⼀一年年的研发模式升级 Now 完成了淘宝和飞猪两大 BU 导购链路，以及一些内部系统的升级。经历了双十一和双十二大促的考验，承载了千万级的流量。

56. 阿⾥里里的 Serverless

57. 阿⾥里里的 Serverless

58. ‣ ‣ ‣ ‣ ‣ Serverless plugin Midway-faas 框架防厂商锁定（fc，scf）水平 ﬂexibility 基于触发器的调试和测试 Roadmap Public Beta 2019.12 ‣ ‣ ‣ ‣ 更多平台支持 Runtime 完整示例 BFF 支持更多 2020~ Release 1.0 2020.1 ‣ ‣ ‣ ‣ AWS lambda 支持文档和示例垂直 ﬂexibility 完整的规范定义 2020.3 ‣ ‣ Web 一体化方案移动端一体化方案 midwayjs/midway-faas

59. THANKS & QA

60. 联系我交流 D2 演讲反馈