Serverless 一些探究（一）

当今社会技术热点，大家都在讨论的是区块链、AI、机器学习等等，但几年前大家追捧的 云计算 ，经历了多年的发展，已经有了长足的进步，只是目前格局逐渐明朗，商业上也形成了几个梯队，云计算在助力前面所说的热点方面起着非常重要的作用。 Serverless 作为云计算中逐渐崭露头角的一种方案，在圈中也是备受关注。

DevOps

互联网公司内面向C端用户应用的开发，DevOps 文化盛行依旧，相信大家一定都不陌生（Development 和 Operations）。

// TODO: 插图

维基百科上解释它实际是一种重视开发人员与运维人员紧密沟通的文化和方法，通过自动化的软件交付和架构演进的流程，来使得构建、测试、发布软件变得更快捷、频繁和可靠。大家可以看这张图，这样的方案在很多公司逐渐地演变成迫使开发人员也要具备一些运维方向的知识，来配合运维同事实现快速迭代，实现流程的自动化等等。这在流程完善的大厂感受可能不是很深，因为我们分工明确，但是在有快速产品迭代计划的小团队或者创业公司就会感受很深。

它的盛行导致一来是提高了对我们业务开发人员的要求，二来增加了整个软件应用交付的成本，尤其是现在的我们作为前端工程师，一旦开始写服务端代码，就要考虑机器成本，CPU占用，内存占用，数据存储，网络带宽，负载均衡等等问题。

那么有没有办法去规避呢？让专业的运维人员去做呢？

演进

云计算在不断演进的过程中，一步一步在提出解决的办法。

首先，我们先来了解几个缩写：

• IDC：Internet Data Center，自建互联网数据中心机房，自行维护硬件资源、物理机器、网络环境等等，开发完成阶段后，还需要进行繁重且耗时很长的部署过程。
• IAAS：Infrastructure as a Service，基础设施服务，租用公共数据中心的物理机器资源，节省了机器的成本
• PAAS：Platform as a service，平台即服务，云厂商提供一个平台，目前尤其火的是基于以 Docker 为主的容器技术的兴起来完成快速部署，比如某一个容器可以快速部署数据库、通过拉取代码快速部署应用；当业务量增加，容器扩容需要形成集群，管理这些容器就需要非常耗费人力；目前热度很高的由 Google 开源的 Kubernetes（K8S）就是用来自动编排容器的利器。
• DAAS：Data as a service，数据即服务，只对数据的采集、治理、分析、聚合等打包一起对外提供服务。
• SAAS：Software as a service 面向普通用户，用户只需要购买和使用软件就可以享受这种服务，比如传统的财务软件，办公自动化系统等等。

网上很多资料，大家都拿吃披萨来举例，如下图：

// TODO: 插图

受限与NodeJS

作为一名前端工程师，大家日常业务开发的工作内容是什么？

用 HTML / CSS去还原视觉稿、用 Javascript 去完成交互、调用 HTTP 数据接口，完成数据的展现和操作等等。最终测试完成，构建打包，部署CDN源站或者其他托管静态资源的系统完成上线。

整个过程中我们只关注脚本和样式是在客户端运行良好，性能和兼容性是否达到比较好的一个平衡，往往对于后台提供的服务和数据能做的非常有限，只需要关注接口容灾、数据兜底、异常处理错误跳转等情况就可以比较好的完成所谓的前端工程师的工作职责。

对于我们依赖使用的服务，我们一般话语权不高，包括UI层的数据结构设计并不能完全是我们自主地从前端角度出发去设计。

GragphQL 这类方案不在本次分享的范围内，它的出现使得数据更具有弹性，但 Serverless 更彻底。

现在请大家换一个角度思考，如果我们没有在京东这样的大厂的平台、如果我们正处创业初期的小公司、如果我们是一名独立开发人员、如果没有从开发到部署的完善流程、没有CDN没有数据接口，这时，我们要如何开发一个动态数据的网站或是一个独立的应用？而不单单是一个静态页面？要如何做？

我们可以写 Javascript ，NodeJS 帮助我们扩展了工作范围，笔者所在的前端部门内部基于 NodeJS 开发系统和应用都是很好的例子，NodeJS 给予了可以写Javascript 代码的人更大的空间，我们可以写越来越多的服务端业务逻辑来直接提供服务。

那么，开发好的 NodeJS 服务，放在哪里运行？这就又成了问题，有过自己开发类似系统经历的同学一定有这样的困惑，除了开发功能代码，还要纠结选什么样的机器，几核CPU，多大内存，网络带宽；如果开发独立的应用，需要购买云主机，去亚马逊、微软、Google、阿里云、腾讯云、京东云等等这样云厂商的选云主机的话更是纠结，超级多规格组合在一起，非常苦恼。

因为做选择的时候，既要为应用规模大小、扩容需求、安装哪一种操作系统、配合哪一种数据库、未来如何组成集群、如何做负载均衡、如何打通开发到部署流程等等等等问题而操心。即便是现在有 Docker、K8S 这样的容器技术和自动编排来辅助，他们虽然可以帮助你做到应用秒级部署，快速重复部署，也依然麻烦，仍然需要付出高昂地运维技术的学习成本，即便你是一个全能达人，你也需要花费大量的时间和精力去解决这些环境和资源的问题，这就对想快速实现一个点子开发出原型或者开发一个小型应用的你来说，像是拦在路上的不得不跨越的一座山，拖慢来你和你团队的行进速度。

还有一个问题，绝大部分应用上线云主机或虚拟机以后，主机或者容器的 CPU 利用率、内存使用率、网络带宽的利用率都非常低，因为你要为未来增加流量做 Buffer ，并且你需要为这些冗余的运行时自掏腰包，因为你的服务一旦上线就要 7X24 的运行。我们现如今公司内部的基于私有云架构开发和部署也是如此的问题，都是需要开发者为这些运维相关的技术债务来埋单。

那么既然有这么多困难，我们前端工程师还有机会成为服务的生产者，而不单单是消费者吗？

转变

Serverless 架构的出现，为我们提供了一个窗口。目前还没有一个普遍公认的权威定义，最新的一个定义是这样描述的。

“无服务器架构是基于互联网的系统，其中应用开发不使用常规的服务进程。相反，它们仅依赖于第三方服务，客户端逻辑与托管远程服务之间的调用过程的组合。”

首先提出这个概念的是在2012年iron.io提出，而在2014年由AWS发布Lambda时正式商业化使用，目前AWS在云计算市场占有率高达44%（2017年数据），同时Microsoft、Google、IBM 都有对应的云产品，在国内，像 JDCloud、Aliyun、Tencent Cloud 也都提供了基础的功能，并且据说阿里内部正在力推适合的场景从旧框架向 Serverless 架构转变，从几个阿里前端的 BLOG 可以看到大家在关注和讨论这项技术对于前端会有什么影响。

Serverless

支持Serverless架构的云厂商，允许我们可以开发服务端逻辑放在无状态的云计算容器中，由事件来进行触发，其他完全交给云来管理。

Serverless 目前分为两种：

BAAS（Backend as a Service后端即服务）
FAAS（Functions as a Service 函数即服务）

FaaS

FaaS 本质上是一种事件驱动的由消息触发的服务，FaaS厂商一般都会集成各种同步或者异步的事件源，通过订阅这些事件，从而达到触发或者定时触发来运行函数。FaaS 允许我们上传一个完整函数的代码片段，这个函数提供单一的无状态的服务，当事件触发执行这个函数的时候，它就会启动并开始执行，完成后等着被销毁，不存在上下文信息和状态。换言之，就是如果函数不运行，这个实例就不存在，比如你购买的云服务实际就并没有进行计费，只有当你执行的时候才会按照函数运行次数收费。

事件触发，给大家举一个例子，有一款网络应用：

IFTTT：汇聚了世界各种有趣的 API ，通过触发一件、一件事来形成链式的调用完成功能。

场景

AWS Lambda 官网文档 和 Google Cloud Functions 官网文档 ，举了几个很贴切的例子。物联网IoT、独立应用、游戏后台服务引擎、数据报表（定时）等等。

貌似看上去离前端有些远，再举一个例子，去年微信小程序提出的云开发，就是一次 Serverless 的尝试，让可以写小程序的开发，不必等服务端，而自己利用云存储、云数据库、云函数来自给自足。

客户端开发，可以自行将数据、文件、信息同步到云端，而又不需要过于操心运维。

函数优势

举例 AWS Lambda 支持 Python 、 Java 、 Go 、 Ruby 、.Net、NodeJS 和自建环境，因为这些服务端语言有很多擅长的场景和成熟的库，可以更方便地去助力完成数据计算、机器学习、图像处理等等工作。

优势

• 降低成本（开发、运营成本）
• 计费方式按价值付费，不再为 7x24 埋单（即使遇到网络攻击，也可以设定阈值做到合理防护，不至于收到天价账单）
• 灵活自动拓展，无需关心扩容缩容问题
• 开发人员更专注核心业务

看上去万能？

No silver bullet. - The Mythical Man-Month

任何解决方案都不是万能的，一定是有它适合的场景，解决适合的问题而存在。

缺陷

• 启动延迟、不适合长时间运行，支持语言版本更新不及时（AWS NodeJS 8.10）
• 没有上下文环境，离线调试（serverless offline）
• 完全依赖云，貌似是一条无法回头的路

是否一切都要部署到云端，这个一直处在争论的，本文也是持中立态度，要分场景适用。

总结

Serverless 架构带来的价值和挑战是并存的，国内的 Serverless 发展也在初期阶段，它改变了我们开发模式，也改变软件系统的一部分设计，未来发展的好坏，我们无法控制，但是我们可以保持关注，适当尝试。