一文读懂 Serverless，将配置化思想复用到平台系统中

简介： 搭建一个 aPaaS 平台是需要很长时间的，当然也可以基于一些公有云产品的 Serverless 方案实现现有系统的灵活性与扩展性，从而实现针对于不同客户的定制。

在 SaaS 领域 Salesforce 是佼佼者，其 CRM 的概念已经扩展到了 Marketing、Sales、Service 等领域。那么 Salesforce 靠什么变成了这三个行业的解决方案呢？得益于 Salesforce 强大的 aPaaS 平台。

ISV、内部实施、客户均可以从自己的维度基于 aPaaS 平台构建自己的行业，实现业务定制，甚至是行业定制。因为在此之前只有在 Sales 方向有专门的 SaaS 产品，而 Marketing 和 Service 都是由ISV 在各自行业的解决方案。所以 Salesforce 已经从一家 SaaS 公司变成了一家 aPaaS 平台公司了。

搭建一个 aPaaS 平台是需要很长时间的，当然也可以基于一些公有云产品的 Serverless网站网站监控 方案网站实现现有系统的灵活性与扩展性，从而实现针对于不同客户的定制。

什么是 Serverless

Serverless 由两部分组成，Server 和 Less。

前者可以理解为其解决方案范围处在服务端；

后者可以译为少量的；

组合起来就是较少服务端干预的服务端解决方案。

与 Serverless 相对的是 Serverfull，比较下对应的概念可能更便于理解。

在 Serverfull 时代，研发交付流程一般有三个角色：RD，PM，QA。

RD 根据 PM 的 PRD 进行功能开发，交付到 QA 进行测试，测试完成之后发布到服务器。由运维人员规划服务器规格、数量、机房部署、节点扩缩容等，这种更多由人力处理的时代就是 Serverfull 时代。

之后进入了 DevOps 时代。这个时代运维自己开发一套运维控制台，可以让研发同学在控制台上自己进行服务观测、数据查询、运维处理等，运维同学的工作轻松了不少，这个阶段主要释放了运维同学的人力。

而到了 Serverless 时代，这套运维控制台能力越来越丰富，可以实现按配置的自动扩缩容、性能监控、DevOps 流水线等，同时侵入到研发流程侧，比如自动发布流水线、编译打包、代码质量监测、灰度发布、弹性扩缩等流程基本不需要人力处理了，这就是 Serverless 时代。

抽象来说，前端只需要将代码片段和编程语言的标识传给 Server 端即可，等待响应结果。Server 端可以针对于不同编程语言进行 runtime 分类、预处理等工作。

Serverless 怎么做

很多人把 Serverless 看做是 FC（function compute：函数计算），使用函数计算，无需业务自己搭建 IT 基础设施，只需要编码并上传代码。函数计算会按需为你准备好计算资源，弹性、可靠地运行，并提供 trace、日志查询、监控告警等治理能力。

在 FC 中有服务和函数之分。一个服务可以包含多个函数。我们可以用微服务理解，我们通过 golang 或 java 搭建了一个微服务架构，而 FC 服务就是其中的类，类比理解之后，我们再看下如何调用 FC 的函数，一般的 FC 解决方案里面都有一个触发器的概念。比如 HTTP 触发器、对象存储触发器、日志服务触发器、定时任务触发器、CDN 触发器、消息队列触发器等。触发器是对于 FC 函数调用的抽象收口，比如 HTTP 触发器一般都类比网关的一个 http 请求事件，或是指定对象存储路径下上传了一个图片，这些触发事件的入口都可以是触发器。触发器产生事件之后可以调用 FC 函数，函数执行的逻辑可以是下载一张图片或是注册一个用户。

这样从触发器到 FC 函数逻辑处理就是一个 FC 的生命周期了。

那么 FC 是如何实现高可用的呢？

其实每个函数底层代码都是运行在一套 IaaS 平台上，使用 IaaS 资源，我们可以为每个函数设置运行代码时需要的内存配置即可，比如最小 128M，最大 3G 等。研发人员不需要关心代码运行在什么样的服务器上，不需要关心启动了多少函数实例支持当前场景，不需要关注背后的弹性扩缩问题，这些都被收敛在 FC 之后。那么 Serverless 如何提效呢？

效率高：如果新加了语言，只需要创建一个对应的 Runtime 的 FC 函数即可；

高可用：通过多线程、多实例两种方式保障高可用，且函数实例扩缩容完全由 FC 自助处理，不需要运维做任何配置；

成本低：在没有触发器请求时，函数实例不会被拉起，也不会计费，所以在流量低谷期间或者夜间时，FC 消耗的成本是非常低的。