无服务时代是“不分布式”云端系统的起点

目录

无服务架构兴起

无服务特点

无服务意义

无服务利弊

总结

无服务架构兴起

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

无服务特点

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

无服务意义

无服务的愿景是让开发者只需要纯粹地关注业务：

一是，不用考虑技术组件，因为后端的技术组件是现成的，可以直接取用，没有采购、版权和选型的烦恼；

二是，不需要考虑如何部署，因为部署过程完全是托管到云端的，由云端自动完成；

三是，不需要考虑算力，因为有整个数据中心的支撑，算力可以认为是无限的；

四是，也不需要操心运维，维护系统持续地平稳运行是云服务商的责任，而不再是开发者的责任。

无服务利弊

与单体架构、微服务架构不同，无服务架构天生的一些特点，比如冷启动、 无状态、运行时间有限制等等，决定了它不是一种具有普适性的架构模式。

一方面，对一些适合的应用来说，使用无服务架构确实能够降低开发和运维环节的成本，比如不需要交互的离线大规模计算，又比如多数 Web 资讯类网站、小程序、公共 API 服务、移动应用服务端等，都跟无服务架构擅长的短链接、无状态、适合事件驱动的交互形式很契合。

但另一方面，对于那些信息管理系统、网络游戏等应用来说，又或者说对所有具有业务逻辑复杂、依赖服务端状态、响应速度要求较高、需要长连接等特征的应用来说，无服务架构至少在目前来看并不是最合适的。

总结

• 微服务架构是分布式系统这条路当前所能做到的极致
• 无服务架构是“不分布式”的云端系统这条路的起点