1.6　无服务时代

人们研究分布式架构，最初是因为单台机器的性能无法满足系统的运行需求，尽管在后来架构演进过程中，容错能力、技术异构、职责划分等各方面因素都成为架构需要考虑的问题，但获得更好的性能在架构设计需求中依然占很大的比重。对软件研发而言，不去做分布式无疑是最简单的，如果单台服务器的性能可以是无限的，那架构演进的结果肯定会与今天有很大差别，分布式也好，容器化也好，微服务也好，恐怕都未必会如期出现，最起码一定不是今天这个样子。

绝对意义上的无限性能必然是不存在的，但在云计算落地已有十余年的今天，相对意义的无限性能已经成为现实。

在工业界，2012年Iron.io公司率先提出了“无服务”（Serverless，应该翻译为“无服务器”才合适，但现在称“无服务”已形成习惯了）的概念；2014年，亚马逊发布了名为Lambda的商业化无服务计算平台，并在后续的几年里逐步得到开发者认可，发展为目前世界上最大的无服务运行平台；到了2018年，中国的阿里云、腾讯云等厂商也开始跟进，发布了旗下的无服务产品，“无服务”成为近期技术圈里的“新网红”之一。

在学术界，2009年，云计算概念刚提出的早期，在加州大学伯克利分校曾发表的论文“Above the Clouds:A Berkeley View of Cloud Computing”[1]中预言的云计算的价值、演进和普及在接下来的十年里一一得到验证。2019年，加州大学伯克利分校发表的第二篇有着相同命名风格的论文“Cloud Programming Simplified:A Berkeley View on Serverless Computing”[2]再次预言“无服务将会发展成为未来云计算的主要形式”。由此来看，“无服务”也同样是被主流学术界所认可的发展方向之一。

额外知识

我们预测无服务将会发展成为未来云计算的主要形式。

——Cloud Programming Simplified:A Berkeley View on Serverless Computing,2019

无服务现在还没有一个特别权威的“官方”定义，但它的概念并没有前面提到的各种架构那么复杂，本来无服务也是以“简单”为主要卖点的，它只涉及两块内容：后端设施（Backend）和函数（Function）。

·后端设施是指数据库、消息队列、日志、存储等这类用于支撑业务逻辑运行，但本身无业务含义的技术组件，这些后端设施都运行在云中，在无服务中将它们称为“后端即服务”（Backend as a Service，BaaS）。

·函数是指业务逻辑代码，这里函数的概念与粒度都已经很接近于程序编码角度的函数了，其区别是无服务中的函数运行在云端，不必考虑算力问题，也不必考虑容量规划（从技术角度可以不考虑，从计费的角度还是要掂量一下的），在无服务中将其称为“函数即服务”（Function as a Service，FaaS）。

无服务的愿景是让开发者只需要纯粹地关注业务：不需要考虑技术组件，后端的技术组件是现成的，可以直接取用，没有采购、版权和选型的烦恼；不需要考虑如何部署，部署过程完全托管到云端，由云端自动完成；不需要考虑算力，有整个数据中心支撑，算力可以认为是无限的；不需要操心运维，维护系统持续平稳运行是云计算服务商的责任而不再是开发者的责任。在UC Berkeley的论文中，把无服务架构下开发者不再关心这些技术层面的细节，类比成当年软件开发从汇编语言踏进高级语言的发展过程，开发者可以不去关注寄存器、信号、中断等与机器底层相关的细节，从而令生产力得到极大解放。

无服务架构的远期前景看起来是很美好的，但笔者自己对无服务架构短期内的发展并没有那么乐观。与单体架构、微服务架构不同，无服务架构有一些天生的特点决定了它现在不是，以后如果没有重大变革的话，估计也很难成为一种普适性的架构模式。无服务架构确实能够降低一些应用的开发和运维环节的成本，譬如不需要交互的离线大规模计算，又譬如多数Web资讯类网站、小程序、公共API服务、移动应用服务端等都契合于无服务架构所擅长的短链接、无状态、适合事件驱动的交互形式。但另一方面，对于那些信息管理系统、网络游戏等应用，或者说对于具有业务逻辑复杂、依赖服务端状态、响应速度要求较高、需要长链接等特征的应用，至少目前是相对不那么适合的。这是因为无服务天生“无限算力”的假设决定了它必须要按使用量（函数运算的时间和占用的内存）计费以控制消耗的算力的规模，因而函数不会一直以活动状态常驻服务器，请求到了才会开始运行，这就导致了函数不便依赖服务端状态，也导致了函数会有冷启动时间，响应的性能可能不太好。目前无服务的冷启动过程大概是在数十到百毫秒级别，对于Java这类启动性能差的应用，甚至是接近秒的级别。

无论如何，云计算毕竟是大势所趋，今天信息系统建设的概念和观点，在（较长尺度的）明天都是会转变成适应云端的，笔者并不怀疑Serverless+API的设计方式会成为以后其中一种主流的软件形式，届时无服务还会有更广阔的应用空间。

如果说微服务架构是分布式系统这条路当前所能做到的极致，那无服务架构，也许就是“不分布式”的云端系统这条路的起点。虽然在顺序上笔者将“无服务”安排到了“微服务”和“云原生”时代之后，但它们并没有继承替代关系，强调这点是为了避免有读者从两者的名称与安排的顺序中产生“无服务就会比微服务更加先进”的错误想法。笔者相信软件开发的未来不会只存在某一种“最先进的”架构风格，多种具有针对性的架构风格并存，是软件产业更有生命力的形态。笔者同样相信在软件开发的未来，多种架构风格将会融合互补，“分布式”与“不分布式”的边界将逐渐模糊，两条路线将在云端的数据中心中交汇。今天已经能初步看见一些使用无服务的云函数去实现微服务架构的苗头了，将无服务作为技术层面的架构，将微服务视为应用层面的架构，把它们组合起来使用是完全合理可行的。以后，无论是物理机、虚拟机、容器，抑或是无服务云函数，都会是微服务实现方案的候选项之一。

本节是架构演进历史的最后一节，如本章引言所说，我们谈历史，重点不在考古，而是借历史之名，理解每种架构出现的意义与淘汰的原因，为的是更好地解决今天的现实问题，寻找出未来架构演进的发展道路。

对于架构演进的未来发展，2014年，Martin Fowler与James Lewis在“Microservices”的结束语中曾写到，他们对于微服务日后能否被大范围推广，最多只持有谨慎乐观的态度。在无服务方兴未艾的今天，与那时微服务的情况十分相近，笔者对无服务日后的推广同样持谨慎乐观的态度。软件开发的最大挑战就在于只能在不完备的信息下决定当前要处理的问题。时至今日，依然很难预想在架构演进之路的前方，微服务和无服务之后还会出现何种形式的架构风格，但这也契合了图灵的那句名言：尽管目光所及之处，只是不远的前方，即使如此，依然可以看到那里有许多值得去完成的工作在等待我们。

额外知识

尽管目光所及之处，只是不远的前方，即使如此，依然可以看到那里有许多值得去完成的工作在等待我们。

——Alan Turing，Computing Machinery and Intelligence，1950

[1] 论文地址：https://www2.eecs.berkeley.edu/Pubs/TechRpts/2009/EECS-2009-28.pdf。

[2] 论文地址：https://arxiv.org/abs/1902.03383。