诱人却非万能，理性看待 Serverless 的落地

InfoQ 的使命是促进软件开发领域知识与创新的传播。对于 Serverless 这个技术概念，我们有必要给大家做更加细致、深入的科普。

1. 编者按

Serverless 通常被直译成“无服务器”，乍一看来，会让人立刻警觉到：这是不是一个“危险”的颠覆性技术？新技术的爱好者们会感到兴奋，而保守派可能会隐隐地担忧着是不是云计算的新炒作。在 Serverless 呼声渐起之时，InfoQ 采访了在云领域深耕十载的陈威，请他谈谈他对 serverless 的观点看法。

在陈威看来，Serverless 并非银弹，它只是云计算在逐渐成熟之后的一个细分技术。新的技术层出不穷，但是技术人不能狂热鼓吹也不要盲目跟从，要始终清醒地牢记“技术始终是为人服务的”。认知水平决定了一个技术人是能成为真正有效的推动者还是低效疲惫的跟风人。

2. 受访者简介

陈威， Pivotal 中国云计算资深架构师。加入 Pivotal 之前，曾先后就职于 IBM 中国研发中心，IBM 中国软件集团信息管理部。拥有超过 10 年的经验，熟悉主机平台、开放平台和三个世代的云平台。擅长大数据和应用云平台融合领域，参与设计过包括金融、电信、公共医疗等行业的大企业方案落地。各拥有一项 published 和 documented 的个人专利。

3. 不断演进的 Serverless 认知

Serverless 一词于 2012 年提出，AWS 在 2014 年推出了 Lamda 的 serverless 服务，2016 年伦敦举办了首届 Serverless 大会。在这几年的发展中，业界对 Serverless 的概念定义也逐渐清晰稳定下来。

最开始，Serverless 意在帮助开发者摆脱运行后端应用程序所需的服务器设备的设置和管理工作。Serverless 通常被直译成“无服务器”，其实并不是真的没有服务器，而是后端服务器的相关工作都交给第三供应商负责。彼时，大家对这个概念的认知是后端即服务（Backend-as-a-Service，BaaS），或移动后端即服务（Mobile Backend-as-a-service，MBaaS）。甚至有一种观点是，只要使用了第三方云服务就是 serverless 的一种。

但是，其实当初这种看法已经不准确了。第三方云服务的范畴很广，包含 IaaS, SaaS, PaaS 等三种，单纯认为使用第三方云服务就是 serverless 是错误的看法，serverless 是更精细化的一个方向，而不是更大的范畴。

Pivotal 云计算资深架构师陈威认同现在业界的观点，即 Serverless 是微服务更进一步的形式。现在看来，Serverless 处在技术曲线的早期阶段，尚未达到炒作期的峰值，市场应用上还处于初级阶段。但是，大则如同云、小则如同微服务，Serverless 将会是技术的未来趋势。云的进化有很多种方向，serverless 更是应用层面的进化方向。

4.Serverless 不是 PaaS 的威胁

Serverless 是 PaaS 的一种特殊情况，通常而言 Serverless 的主流表现形式是 FaaS，FaaS 也是一种平台，只不过处理的专门是 Function 类型。

下面是一张图片，可以帮助大家厘清 FaaS 与 PaaS 的关系

如图所示，这是我们理想中的 Serverless 的一种抽象架构，从左至右来看：

1. 最左边实际上是客户端的应用开发框架，例如 Spring Cloud Function 等相关体系，客户使用 Serverless 开发框架研发的应用应该和开发本地应用没有形式上的区别，也就是说具体后端使用哪个云服务提供商的 Serverless 服务对于应用逻辑开发是完全透明的
2. 中间部分是广义上的 PaaS，在 PaaS 之中，function as service，也即我们通常意义上的 FaaS 作为 PaaS 的一个 platform 提供给用户，比如 function 的注册，发现，容错，调度，数据流衔接，监控，日志处理等机制。当 Serverless 应用部署到 PaaS 平台上面，绑定 FaaS 服务之后，具体后端是用哪种中间件平台实现，就和最左端的应用开发没有关系了，具体的自动适配都由 FaaS 和 PaaS 解决。 例如排序这个基本的操作，究竟是基于 JVM 的应用级别实现，还是分配到 RDBMS 里面，甚至是到 Hadoop 里面，这个数据的流转以及任务的调度，理想情况下是无需应用开发人员关心的。
3. 最右边的部分，则是提供底层基础设施的云服务商，也就是我们传统意义上的 IaaS，包括他们也有可能提供整套的 Serverless 服务。接着上面第二点的描述，究竟这个 JVM 应用，或者 RDBMS 服务，是对接 AWS 的，还是 Azure 或者 Google GCP 的，这个就由 PaaS 层面来进行无缝的对接和运维管理等等了。

由此可见，将其视为 Backend-as-a-Service 是最早的定义，但是这个范畴太广了；现在已经更细化了，可以看成是后端基于事件的轻量级服务，而不是说只要 backend 就叫 Serverless。现在看来，当年的定义过于笼统。

5.Serverless 的技术优势和不足

Serverless 比微服务更诱人

Serverless 还是继承了微服务的优势，并且适用于无状态的、基于事件的处理，这是两者共同点。但是 Serverless 的粒度更细，弹性更好：微服务的迭代发布一般以天或周为单位，每个微服务代码量在几百行左右；如果采用了容器化微服务，可能秒或分钟量级。而对于 Serverless 业界一般会定义为毫秒级别的弹性指标，大部分都是基于内存存储或者事件处理。

但是 Serverless 不是普适的

相比于虚拟机等底层技术具有普适性，Serverless 靠近使用者、偏上层，这也就意味着 Serverless 有一定的局限性和适用范畴。Serverless 适用于轻量、事件驱动的技术框架，比如 Java 9 中类似与 React 的方式。传统三层架构，如大量文件处理、传统关系数据库的操作，体现不出来太多的优势。

那 Serverless 适合什么？

对于新兴的、事件驱动性的，类似于 IoT 等传感设备、金融交易类型等场景，比较适合 serverless。

Serverless 将会使得运维更加复杂化

Serverless 比微服务更细化了，管控起来会更麻烦，因此是不可能依靠人工去执行的，进行一个个函数的管理，一定需要借助平台，这也是为什么 Serverless 的落地最终要通过 FaaS，因为微服务要通过类似 Spring Cloud 的框架加上平台技术，例如 Pivotal Cloud Foundry 才能实现。

Serverless 也算作云原生的范畴。如果采用公有云 FaaS 服务（比如 Pivotal Web Service），就是将运维工作交出去了，这种做法很难界定是价钱更便宜还是更贵；而如果采用私有云 FaaS 服务，则需要借助程序框架、依赖 PaaS 平台。目前已经有一些先进的云计算厂商提供了 Serverless 服务能力，Pivotal 就是其中之一，他的公有云服务是 Pivotal Web Service，私有云服务基于 Cloud Foundry 平台，后者是其在国内落地次数最多、落地规模最大的平台。

6 如何实现？当 Spring 遇上 Serverless

Serverless 与 Docker 有很多相像的技术特色，但是两者所处的层面不同。Serverless 是从上往下看问题，而 Docker 还是处在基础架构层面。但是，即便两者有如此多的相同点，也没有强调说上层的 serverless 需要下层一定 Docker 实现，目前并没有哪家云厂商宣称其 serverelss 平台是基于 Docker 实现的。在陈威看来通过容器实现 Serverless 还是更重一些，容器更像是封装的一个简版操作系统；但是 serverless 的操作对象不是 Cgroups 或 LC 的方式，Serverless 涉及到的是进程、线程级别的开发，所以容器和 Serverless 不是很好的搭配。

那么怎样实现 Serverless 呢？陈威给出的答案是可以通过 Spring 的 serverless 编程框架。IT 界有目共睹的是，相比于略显疲态的 J2EE，Spring 技术派系的崛起并不断发展壮大。陈威认为目前 Pivotal 很重要的贡献是研发和推进了当今业界的微服务标准框架 Spring Cloud。而对于 serverless 的实现，Pivotal 也没有袖手旁观。Spring 框架中有一些项目可以为 Serverless 计算添砖加瓦，如 Cloud Foundry Tasks, Spring Cloud Task, Spring Cloud Data Flow,Spring Cloud Function 等，Spring Cloud Function 是 Serverless 的主要编程框架，已经研发半年多，由一支不足十人的精英团队负责，基本框架和路线图均已完成，初版还在研发磨合阶段。与 Spring 框架中已经存在的其他项目一样，Spring Cloud Function 也完全开源。

Spring Cloud Function 目前还属于孵化阶段，Pivotal 已经将其托管至 github，地址.

目前由 Spring Cloud 的创始项目人 Dave Syer 负责 lead 各位技术人员可以直接登录到上述的地址去查看相应的源代码，示例等等。

目前，Spring Cloud Function 有如下的几个设计原则

1、推行基于 Function 的业务逻辑实现的理念

2、将业务逻辑的开发生命周期与任何运行时平台解耦，使得代码能够以 web endpoint, 流处理器，或者 task 等的方式运行

3、支持统一的，跨各种 serverless 提供商的，统一的编程模型，同时也支持本地化的运行模式 (本地化或者在 PaaS 中)

4、在 serverless 提供商的平台上启用 Spring Boot 的能力 (auto-configuration,metrics,tracing)

Spring Cloud Function 有如下的几个主要的功能：

1、Wrappers for @Beans of type Function, Consumer and Supplier, exposing them to the outside world as either HTTP endpoints and/or message stream listeners/publishers with RabbitMQ, Kafka etc.

将以 @Beans 形式封装的 Function, Consumer, Supplier 暴露给外界环境，具体表现为 HTTP 端点，或者使用 RabbitMQ,Kafka 等以 listeners/publisher 实现的消息流的方式

2、Compiling strings which are Java function bodies into bytecode, and then turning them into @Beans that can be wrapped as above.

将纯字符串方式编写的 Java Function 编译成字节流，并转换成为 1 里面的 @Bean 封装

3、Deploying a JAR file containing such an application context with an isolated classloader, so that you can pack them together in a single JVM.

使用隔离的 classloader 部署上面步骤形成的 jar 包与相应应用上下文环境，打包到一个单独的 JVM 里面

4、Adapters for AWS Lambda, Apache OpenWhisk and possibly other “serverless” service providers.

适配 AWS Lambda, Apache OpenWhisk 或者有可能其他的“serverless”服务提供商

当然除了框架的采用，由于 serverless 粒度比微服务还细，因此其实施和落地意味着更多的挑战，这需要云服务商和用户的深度协作，比如 pair programming 的方式行一行一行代码编写。，技术文档可能会略显单薄，如果能有人力的参与会更加高效。

7. 未来，物联网会引燃 Serverless 吗？

如果单纯谈 IoT，陈威告诉 InfoQ 其实 Pivotal 已经有很多落地的客户案例了，均是通过 Pivotal Cloud Foundry 的 PaaS 平台和容器技术去实现的，比如奔驰的车联网、GE 工业互联网和西门子的工业联网平台。不过，坦白而言，相比容器和微服务技术，由于 Serverless 尚且比较新兴，Pivotal 内部尚无物联网领域的落地案例。

那么物联网是否适宜 serverless 呢？陈威认为主要是看是否基于事件，比如高速公路 ETC，事件触发频率可能很高，可以承受高并发、使用轻量并且弹性要求高的场景。公开场合中对人群人脸进行检测，工作量的多少与人群数量之间相关，因此需要弹性很好。还有如环境检测（空气、水），生产制造等情景会应用到大量传感器。传统的嵌入式系统软件可以在前端进行及时的处理，但是这些端要求高可靠，只执行简单工作（比如数据的采集），而 Serverless、PaaS 等技术则是在云端进行分析，进行真正的智能化、大规模分析。

8. 关于 Serverless 个人看法

云方面的技术近年是层出不穷，各种概念、框架令人眼花缭乱，但作为一个亲历了从 mainframe 主机时代到容器时代都变革技术人，其实已经没有了过多的新鲜感，也褪去了年少时接触新事物的兴奋激动。

正所谓阳光之下没有什么新鲜事物一样。IT 领域的技术或者发展一样遵循这个世界的基本发展规律，例如守恒定律与哲学逻辑。从上述的角度而言分析新生的事物或者技术而言，都会遵循一个哲学的规律和终极问题，我是谁，我从哪儿来，我要去哪儿。这些问题对应地“翻译”成六个技术的认识问题就是：

1. 这是什么技术？
2. 什么背景、什么问题促使这个技术的产生和发展？
3. 它有什么好处，有什么弊端？
4. 使用了它我会变成什么样子？
5. 我该怎么使用？怎么具体落地到我这里？怎么扬长避短与现有能力进行融合？
6. 它将会发展成什么样子，我会据此有什么发展和规划？

新的技术层出不穷，但是要知道技术始终是为人服务的。不解决人的问题，技术无法成长壮大，要正确地认识到上述六个问题都有哪些都到了解答，；对于不同的具体客户而言，技术又处在怎样的认知阶段。认清形势，有所为而有所不为至关重要。

就 Serverless 的目前发展而言，我认为第二个问题都还没有得到完全切实的答案，其他几个问题或多或少有一些偏技术层面的解释。我认识太多的客户或者专家，执着于研究和对比一个平台或者技术的某些不太重要细节参数，而 Serverlesss 技术对于业务、人的层面有什么价值却一无所知，只是人云亦云的跟风与追赶潮流，对于这样的人而言，认知水平决定了他永远只能是跟随从众的角色和级别。

其实，用简单的比喻而言，云就是一台庞大的机器，IaaS 是它的 BIOS，PaaS 是它的操作系统 OS，SaaS 是它的应用。

1. 在单机时代，为了跨 OS 平台不用重新开发应用，JVM 孕育而生，JVM 虚拟机作为各种 OS 的抽象机器，实现了应用的跨平台运行与一致性运维。
2. 但是后来单机的性能无法满足应用业务的需求，后来就诞生了各种强大的应用服务器与中间件平台能够支持有限度的集群应用管理与运维，例如大家熟知的 WebLogic, WebSphere，Oracle RAC 等，基于这些平台，应用做适当的改造，适配和配置就能够做到集群化运行。

而在云的时代，各种以 IaaS 为基础的服务商也纷纷演进出自己的 PaaS 平台技术，你可以理解为市面上也出现了很多种的云操作系统 OS。

那么，在当年 JVM 诞生的年代的上述两个问题又再一次的出现：

• 我的应用如何跨不同云 OS？
• 我的应用如何在云上集群化分布式处理?

我的答案是，Spring Cloud 即是为了解决云时代的第一个问题而设计，包括我们推出的 Spring Cloud Function，借由 Spring 的普适、整合与抽象能力，做到应用也能够跨不同的 PaaS 而无需做不同的开发。对于第二个问题，分为两个层面来应对，第一个层面是应用开发指导原则与最佳实践层面，例如十二要素、DDD、微服务等等。

第二个层面是技术中间件层面，Pivotal 推出了 Spring Cloud Netflix 为代表的一系列服务管控中间件，以及服务、微服务的运行管控云平台 Pivotal Cloud Foundry，为了最大程度简化应用的分布式处理架构以及之上的分布式应用开发。这也是技术守恒定律的体现，整体的 IT 复杂性不会因为使用了微服务、容器、或者 Serverless 而降低。我们只不过是将复杂性转移到了这些 PaaS/FaaS 的基础设施里，这些业务逻辑无关的纯 IT 架构部分。引用一句话“哪有什么岁月静好，只不过是有人替你负重前行”。

所以，就 Serverless 和 Spring Cloud Function 而言，对于大家的建议我归纳成一句话就是：积极关注与跟进，谨慎结合自己的实际需求使用，避免纯技术导向的盲目尝试。

感谢木环对本文的审校。

给InfoQ 中文站投稿或者参与内容翻译工作，请邮件至 editors@cn.infoq.com 。也欢迎大家通过新浪微博（ @InfoQ ， @丁晓昀），微信（微信号： InfoQChina ）关注我们。