在创建函数时,提供其元数据作为函数创建的一部分,将对其进行编译使其-
- 具有可发布的特性。接下来可以启动、禁用函数。函数部署需要能够支持以下用例:事件流(Event streaming):在此用例中,队列中可能始终存在事件,但是可能需要通过请求暂停/恢复进行处理。
- 热启动(Warm startup) :在任何时候具有最少实例数的函数,使得所接收的“第一”事件具有热启动,因为该函数已经部署并准备好为事件服务(而不是冷启动),其中函数获得通过“传入”事件在第一次调用时部署。
用户可以发布一个函数,这将创建一个新版本(最新版本的副本),发布的版本可能会被标记或有别名。
用户可能希望直接执行/调用函数(绕过事件源或API网关)以进行调试和开发过程。用户可以指定调用参数,例如所需版本,同步/异步操作,详细日志级别等。
用户可能想要获得函数统计(例如调用次数,平均运行时间,平均延迟,失败,重试等)。
用户可能想要检索日志数据。这可以通过严重性级别、时间范围、内容来过滤。Log数据是每个函数级别的,它包括诸如函数创建和删除,警告或调试消息之类的事件,以及可选的函数的Stdout或Stderr。优选每次调用具有一个日志条目或者将日志条目与特定调用相关联的方式(以允许更简单地跟踪函数执行流)。
生产环境中开发Serverless应用的流程可以认为是,当开发者想要开发一个项目的时候,通常只需要根据FaaS提供商所提供的Runtime,选择一个所熟悉的编程语言,然后进行项目开发、测试(图中步骤1);
完成之后将代码上传到FaaS平台(图中步骤2);
上传完成之后,只需要通过API/SDK(图中步骤3)或者一些云端的事件源(图中步骤3)触发上传到FaaS平台的函数;
FaaS平台就会根据触发的并发度等弹性执行对应的函数(图中步骤4);
最后用户可以根据实际资源使用量进行按量付费(图中步骤5)。
在Serverless应用形态下,移除了最初应用中的身份验证逻辑,换用一个第三方的 BaaS 服务(步骤1);
允许客户端直接访问一部分数据库内容,这部分数据完全由第三方托管,这里会用一些安全配置来管理客户端访问相应数据的权限(步骤2);
前面两点已经隐含了非常重要的第三点:先前服务器端的部分逻辑已经转移到了客户端,如保持用户 Session、理解应用的 UX 结构、获取数据并渲染出用户界面等等。客户端实际上已经在逐步演变为单页应用(步骤3);
还有一些任务需要保留在服务器上,比如繁重的计算任务或者需要访问大量数据的操作。这里以“搜索”为例,搜索功能可以从持续运行的服务端中拆分出来,以 FaaS 的方式实现,从 API 网关(后文做详细解释)接收请求返回响应。这个服务器端函数可以和客户端一样,从同一个数据库读取产品数据。原先的搜索代码略作修改就能实现这个搜索函数(步骤4);
还可以把“购买”功能改写为另一个 FaaS 函数,出于安全考虑它需要在服务器端,而非客户端实现。它同样经由 API 网关暴露给外部使用(步骤5);