学习笔记-架构的演进之Serverless-2月day07

引言

分布式架构出现的最初目的，是要解决单台机器的性能成为整个软件系统的瓶颈的问题。后来随着技术的演进，容错能力、技术异构、职责划分等其他因素，也都成了分布式架构要考虑的问题。但不可否认的是，获得更好的性能，仍然在架构设计中占有非常大的比重。分布式架构也会引入一些新问题比如服务的安全、容错，分布式事务的一致性。

对软件开发这件事儿来说，不去做分布式无疑是最简单的。如果单台服务器的性能可以是无限的，那架构演进的结果，肯定会跟今天不一样。当然，绝对意义上的无限性能肯定是不存在的，但相对意义上的无限性能其实已经实现了，云计算的成功落地就可以说明这一点。对基于云计算的软件系统来说，无论用户有多少、逻辑如何复杂，AWS、阿里云等云服务提供商都能在算力上满足系统对性能的需求，只要你能为这种无限的性能支付得起对应的代价。

Serverless

在工业界，2012 年iron.io 公司率先提出了“无服务”（Serverless，应该翻译为“无服务器”才合适，但现在用“无服务”已形成习惯了）的概念；2014 年开始，AWS 发布了命名为 Lambda 的商业化无服务应用，并在后续的几年里逐步得到了开发者的认可，发展成目前世界上最大的无服务的运行平台；到了 2019 年，中国的阿里云、腾讯云等厂商，也发布了无服务的产品。

在学术界，2019 年UC Berkeley 的论文“Cloud Programming Simplified: A Berkeley View on Serverless Computing”，预言“无服务将会成为日后云计算的主流方式”。

特征

虽然工业界和学术界在“无服务”这件事儿上都取得了些成果，但是到今天“无服务”也还没有一个特别权威的定义。与微服务、SOA 等各种架构相比，无服务最大的卖点竟然就是简单，只涉及后端设施（Backend）和函数（Function）：

1. 后端设施是指数据库、消息队列、日志、存储等这一类用于支撑业务逻辑运行，但本身无业务含义的技术组件。这些后端设施都运行在云中，也就是无服务中的“后端即服务”（Backend as a Service，BaaS）。
2. 函数指的就是业务逻辑代码。这里函数的概念与粒度，都已经和程序编码角度的函数非常接近了，区别就在于，无服务中的函数运行在云端，不必考虑算力问题和容量规划（从技术角度可以不考虑，但从计费的角度来看，你还是要掂量一下自己的钱包够不够用），也就是无服务中的“函数即服务”（Function as a Service，FaaS）。

无服务的愿景是让开发者只需要纯粹地关注业务：一是，不用考虑技术组件，因为后端的技术组件是现成的，可以直接取用，没有采购、版权和选型的烦恼；二是，不需要考虑如何部署，因为部署过程完全是托管到云端的，由云端自动完成；三是，不需要考虑算力，因为有整个数据中心的支撑，算力可以认为是无限的；四是，也不需要操心运维，维护系统持续地平稳运行是云服务商的责任，而不再是开发者的责任。

局限

与单体架构、微服务架构不同，无服务架构天生的一些特点，比如冷启动、 无状态、运行时间有限制等等，决定了它不是一种具有普适性的架构模式。
一方面，对一些适合的应用来说，使用无服务架构确实能够降低开发和运维环节的成本，比如不需要交互的离线大规模计算，又比如多数 Web 资讯类网站、小程序、公共 API 服务、移动应用服务端等，都跟无服务架构擅长的短链接、无状态、适合事件驱动的交互形式很契合。
但另一方面，对于那些信息管理系统、网络游戏等应用来说，又或者说对所有具有业务逻辑复杂、依赖服务端状态、响应速度要求较高、需要长连接等特征的应用来说，无服务架构至少在目前来看并不是最合适的。

这是因为，无服务天生“无限算力”的假设，就决定了它必须要按使用量（函数运算的时间和内存）来计费，以控制消耗算力的规模，所以函数不会一直以活动状态常驻服务器，只有请求到了才会开始运行。这导致了函数不便于依赖服务端状态，也导致了函数会有冷启动时间，响应的性能不可能会太好（目前，无服务的云函数冷启动过程大概是在百毫秒级别，对于 Java 这类启动性能差的应用，甚至能到秒级）。

演进

在云计算的大势所趋环境下，今天信息系统建设的概念和观念，在较长尺度的“明天”都是会转变成适应云端的。Serverless+API 的这种设计方式，随着云计算的持续发展，将会成为一种主流的软件架构形式，无服务到时候也应该会有更广阔的应用空间。

如果说微服务架构是分布式系统这条路当前所能做到的极致，那无服务架构，也许就是“不分布式”的云端系统这条路的起点。软件开发的未来，应该是多种架构风格的融合互补，“分布式”与“不分布式”的边界将会逐渐模糊，两条路线将会在云端的数据中心交汇。

今天，我们已经能初步看见一些使用无服务的云函数去实现微服务架构的苗头了，所以把无服务作为技术层面的架构，把微服务视为应用层面的架构，这样的组合使用也是完全合理可行的。比如，根据腾讯公开的资料，企业微信、QQ 小程序、腾讯新闻等产品，就是使用自己的无服务框架构成的微服务系统。以后，无论是通过物理机、虚拟机、容器，或者是无服务云函数，都会是微服务实现方案的一个候选项。

总结

时至今日，我们依然很难预想在架构演进之路的前方，微服务和无服务之后，还会出现什么形式的架构风格。这也正契合了图灵的那句名言：

We can only see a short distance ahead, but we can see plenty there that needs to be done.
尽管目光所及之处，只是不远的前方，即使如此，依然可以看到那里有许多值得去完成的工作在等待我们。
—— Alan Turing, Computing Machinery and Intelligence, 1950

附

此文章为2月Day7学习笔记，内容来源于极客时间《周志明的软件架构课》