4.2 FaaS函数运行时架构设计
基于Nomad的边缘计算平台的FaaS函数运行时架构如图4.4所示，FaaS函数运行时围绕Docker，涉及三个核心组件：FaaS API网关，FaaS函数运行时和Watchdog。
图4.4 FaaS函数运行时架构图
基于OpenFaaS的框架，FaaS-Nomad-Provider实现了社区公开的faas-provider接口，接入Nomad的工作负载编排功能，将函数计算功能引入本文边缘计算平台；针对边缘应用使用存在波峰波谷的特点，设计和实现函数自动缩容到零，针对冷启动时延问题考虑和实现了函数预热；针对函数间的组合关系，设计和开发了函数工作流程。
由于设计上，要尽可能在不更改或少更改Nomad现有接口或工具的情况下实现函数运行时的管理功能。根据FaaS服务模型的思想，其中每个应用程序组件都被建模为服务，通过触发器执行，并仅在满足服务请求的持续时间内运行。可以FaaS函数运行时及OpenFaaS相应组件作为基于Nomad的边缘计算平台的工作负载，其中FaaS API网关、FaaS函数运行时、应用函数都会打包成Docker镜像，以容器的方式启动，并基于此使用Nomad的system调度器编排，对外提供函数计算功能。
参考社区和一些论文的思想，FaaS函数运行时设计上，根据正交原则，拆分为构建（Build）、服务（Serving）、事件（Eventing）三分部分。
在构建角度上，具体就是代码到容器的构建，涉及函数的定义和编写方式，构建镜像，部署函数的方式。用户发布函数设计为在Nomad上编排并通过API网关暴露的source-to-url的工作流程。镜像构建的设计之初，对照Knative发现有一些重要的区别，但是探索这些区别超出了本文的范围，关键区别之一是OpenFaaS设计提供了自己的一组类unix原语，允许任何容器编制器实现功能。从可移植可重用的角度考量，其实OpenFaaS构件的函数镜像无需修改，仅需修改为Knative的服务定义，即可在Knative中运行。因为OpenFaaS构建的是Docker或OCI格式的容器镜像。当然通过编写后端provider使用OpenFaaS原语构建，也可以用作其他专有平台（如AWS Lambda）的打包格式。
在事件角度上，具体就是函数触发的方式，涉及事件格式，事件和函数的绑定方式，订阅/发布机制。如图4.5所示，FaaS函数运行时的事件源触发器可以使用事件连接器模式（Event Connector Pattern），创建一个单独的代理或微服务即连接器，维护函数到事件主题的映射，并通过API网关调用函数。事件连接器模式使得不需要根据事件源修改FaaS函数运行时的代码，通过该模式支持各类第三方事件源和自定义触发器。
图4.5 事件连接器模式
在服务角度上，具体就是运行时管理能力，本文设计也是遵循的请求驱动计算，根据需求自动伸缩和调整工作负载大小。其中，冷启动时间和自动扩缩容效率是FaaS运行时的关键性能点。此外，本文针对边缘计算的应用场景做了一些设计，详见缩容到零和函数预热策略的实现。
