感谢大家抽出宝贵的时间参与今天下午的云原生论坛，今天我演讲的题目是函数即服务的标准解读，演讲内容主要分为四个部分：Serverless架构技术简介、产业发展近况、函数即服务的标准解读，还有就是下半年的工作方向。

首先来看Serverless技术架构，我们希望通过这部分的介绍让大家理解为什么会出现这项技术，Serverless是什么、包含哪些内容、都有哪些场景。

按照应用架构和基础设施架构一直都是处于交叉促进状态，应用分层给容器技术的发展提供了基础，容器化部署的改个则促进了微服务架构的发展，而微服务的逐渐成熟又为Serverless的出现提供了可能。如右边的应用部署方式示意图，计算抽象的进化越来越忽视下面的这些基础设施的相关内容，让我们的开发者更加专注于业务核心的开发，实现计算节耦和抽象加强。PaaS平台已经给开发者提供了很多便利，但是对与开发者来讲，如果想要享受纯粹的编程快乐，完全不需要关心底层的运维工作，PaaS还是是达不到的。这种需求推动了Serverless技术的出现。

2012年开始Serverless技术首次被提出，但是因为当时云基础技术没有那么成熟，Serverless概念缺乏具体落地实践的技术，因此没有引起太大的反响，直到2014年亚马逊发布Lambda服务，这项新的计算服务正式推出，真正开启Serverless商业化的时代。

随后两年当中，Google、IBM和微软也都看到了Serverless前景，陆续推出了自己的函数服务，国内推出稍微晚一些，2017年国内的巨头比如阿里、华为、腾讯、百度陆陆续续发布自己的函数计算产品，国内生态已经逐渐显现，但是国内Serverless生态还是比较小，也比较单薄。2017年开始，开源的serverless框架慢慢出现，整个Serverless生态呈现百花齐放的状态。

什么是Serverless其实现在业界并没有一个非常权威的定义，共识性的理解是Serverless包含了FaaS和BaaS两个部分，一个提供计算能力，一个提供后端服务。这些概念很难用一句话来解释清楚，我们总结了几个非常明确的特点，希望能够帮助大家有一个清晰的认识。因为没有一直存在的应用，也没有一直存在的服务器，只有触发才会调用，然后就会马上释放。实际上FaaS只是用于基础构建和业务部署，主要是面向开发我者来使用，后端的数据库、认证和通讯都是由第三方厂商来做维护。

Serverless的典型适用场景分为三类：首先是后端应用，包括移动后端、外部后端和IoT后端。电影应用包括微信小程序、图片和视频的剪辑，只要把素材上传到存储就可以自动触发函数，生成不同的格式，非常方便。大规模数据处理和计算，这种应用特点就是波峰波谷非常明显，可能一天会有两到三个小时集中处理，但是处理的过程当中需要的资源非常大，但是又不想一整天围绕计算需求占用资源，需求过来的时候可以自动把这项业务处理。基于事件的内容处理类应用，包括邮件验证，就是事件很随机，没有波峰波谷的现象，但是用户注册就需要验证，这种处理流程可以通过Serverless实现。

这些就是Serverless产业和技术发展的近况，包括Gartner发布的技术曲线，可以看到Serverless的 PaaS和基础设施处于快速上升周期，未来两到五年有可能会迎来爆发。下面就是市场增长情况，2017年全球公有云PaaS服务当中，Serverless PaaS已经占到3.8%，下面的具体数据当中可以看到2017年到2022年预估复合增长率已经达到38.6%，这是非常高的数据，也就是未来几年整个Serverless应该是发展非常迅速。

这是我们自己前面做的内部调查，因为Serverless国内的数据非常少，按照这种调查数据来看，目前还是以大中型公司为主，使用的是公有云部署，但是存在多云应用环境，业务是以公有云部署为主。目前36%的用户只是作为小规模的试用阶段，所以Serverless在国内还是小范围试水阶段，很多大型企业在进行Serverless服务的同时也在进行架构改造，外部用户应该不是很多。按照Serverless的构建环境来看，公有云和私有云均能部署，以后发展还是有一定的前景和空间。采用Serverless技术之前，大家考虑的主要还是部署成本，就是要把现有技术和现有应用完全迁移到Serverless上来，部署成本会不会真的降低？我们也在内部了解了一下，如果是小规模的用户迁移上去的话，这种成本减少是非常明显的，但是大中型业务完全迁到Serverless上去，相比传统架构是否会有很好的效果收益，可能需要具体评估。现在国内Serverless的生态并不是非常的好，相关的配套工具也不是非常健全，怎么才能快速地把这套技术学习应用起来，其实也是大家比较关注的热点。Serverless的测试和调试工具现在还是比较缺乏的，因为调试还是相对复杂，要求一些本地调试工具，现在各大厂商也都具备，但还没有达到一个非常完备的状态。

Serverless的概念逐渐被大家接受，在这种背景下信通院联合各大云服务商制定了函数即服务的标准，标准的能力要求涵盖了分为六个部分，包括函数基础能力要求、平台接入能力、工具完备性、函数性能、函数安全性、计量计费等。

首先看基础能力要求这部分，我们需要通过流程模板创建，整个函数启动之前会有一个基础配置，我们可以选择函数内存，也做一些运行限制，其实函数在创建的时候会有角色定义，包括函数的标签化，如果函数没有正常运行的话可以去做后续分析，我们详细来看一下运行的问题是什么，包括变量注入，可以把数据库的密码加入进去。后续可能会支持自己的后端服务，目前大家比较能够接受的部分都会有这样的产品。

触发方式需要做到同步触发、异步触发和定时触发，我们也需要进行管理，代码管理可以做到多种维度的代码上传，集中保存和提交，也可以把代码放在存储当中。现在函数支持多个版本共存，可以有多个函数版本同时在存储的云端，运行指定的版本进行控制，包括规模流量的控制。调试方面需要支持多种调试方式，包括在线调试、本地调试，便于我们进行函数管理。

网络接入能力包括两个部分：健全就是基于身份的管理，就是从用户层面访问决策控制，做到权限限制，也是用户可以划分的服务。然后基于资源的策略管理，很多函数可以访问的服务也是可以进行控制的。VPC网络接入部分，很多用户的数据库的应用都是跑在内网，函数可以和内网交互的话可能影响到正常的应用，所以我们要求函数服务正常和后端应用进行交互和访问。

工具完备性主要是保证函数更加好用，监控方面有些基础指标，比如函数错误次数和内存状态，计量相关统计目前都可以做到，高级版本可能需要单独购买，目前并没有形成标准，包括日志工具就是实现日志的采集和聚合，可以把所有函数系统，可能只需要看到函数的日志，告警工具就是针对采集的部分，其实可以实现多渠道的推送。

安全性应该是函数计算方面大家比较关心的部分，代码完全放到云端的话安全性应该怎么保证？主要通过四个方面：首先是租户隔离，包括容器级别的隔离和虚拟机级别的隔离。代码安全就是代码上传上去怎么存储，所有用户上传代码都是通过加密，存储之后会对用户代码鉴权管理，只有相应权限的人员才能访问。直接把代码放到对象存储当中，可能会在一定程度上保障我们的安全性，只是会消耗一些性能。函数运行过程当中针对程序的要求也有限制，或者函数本身是对后端资源有些限制。所以即便函数被攻破，也可以大限度保护不会侵袭虚拟机。

计量计费能力其实是函数比较新的模型，和传统的主机定量存储方式不太一样，因为函数计算需要支持三种基础模型，针对后端资源的需求差异是比较大的，针对不同的运营场景可能会有更多的需求，或者通过流量计算机费。除了计费模型以外，我们要求提供比较精细的函数资源统计。

函数性能也是用户非常关注的点，但是和多个因素有关系，比如代码语言不一样，选择内存不太一样，所以时间变化差距都非常大。我们可以进行函数单独测试，50M以内的代码包可以实现毫秒级的共享，系统调优可以做到用户能够接受的程度，不是首次调用的话需要函数调用30毫秒以内。

后续工作就是刚才提到的函数性能，包括不同的运行语言，不同的内存差别也比较大，如果没有产品化的验证，后续可以选择几个主要的代码语言，包括合适的内存去跑，然后放到真实的用户场景，通过一些参考数值给予大家参考。今年7月份开始，我们会做一些容器性能测试的框架研讨，希望感兴趣的朋友可以加入我们。