6 岁！是时候重新认识下 Serverless 了

Posted 2022-08-12 阿里云开发者

简介：Serverless 首先是一个理念，不是某一种具体的技术，当未来某一天，99% 的云产品都有 Serverless 化的形态时，云计算也就 Serverless 化了，这种变化我认为不是非黑即白的，不是推翻重来这种革命性的，而是全面地降低用户使用云的成本，全面地提升开发者的研发效率。

来源 | Serverless 公众号

背景

Serverless 概念从 2012 年开始提出，真正推出相关云产品是 2014 年 AWS 推出 Lambda。如果我们将 Serverless 比作一个婴儿，那么它已经 6 岁了。

虽然业界对 Serverless 尚无一致认可的定义，但是我相信大部分开发者在听到  Serverless 时，会联想到 Lambda，并且冒出“函数”、“按需（调用次数）收费”、“事件驱动”等关键词。确实当年刚刚诞生的 Serverless 就像下面可爱的“紫薯人”，紫色充满神秘感（当年刚推出的时候绝对是黑科技），让人印象深刻。

刚刚出生的 Serverless

AWS 的巨大影响力以及本身携带的一身黑科技，确实让人记住了 Serverless，但是也正因为诞生的时候太印象深刻，以至于现在提到已经 6 岁的 Serverless，很多人的印象还是停留在Serverless=Lambda或者Serverless=FC（Function Compute），这不得不说是某种遗憾。

现在的 Serverless

今天企业都在全面数字化转型，整个技术架构体系都渴望依托云原生来获取巨大技术红利，Serverless 从诞生的第一天起就是云原生的，所以我们有必要再系统地认识一下 Serverless 的理念以及这些年诞生的相关产品，相信不管你是前端、后端、架构师、SRE、CTO，都会有所收获，并且在未来能更好地发挥 Serverless 的技术价值助力商业成功。

定义

业界一直在尝试定义 Serverless，比如 CNCF 给出的定义是：NoOps 和 Pay as You Run，还有伯克利说 Serverless = FaaS + BaaS。但是我想说，Serverless 其实无需再去定义，他本身就已经非常清晰明确：“Server + less”，他是一个理念，核心思想就是你不再需要关注 Server，作为对比的是 IaaS 时代，购买服务器，安装各种工具，再在上面开发自己的业务。

Server 不会消失，而是让一般的开发者不需要再关注 Server，这意味着【智能弹性】、【快速交付】、【更低成本】，这也是 Serverless 相关产品的典型特性。

所以没必要再去给 Serverless 做什么定义，他本身已经描述得很清晰。我们抛开概念，看看在各个具体技术领域的产品，相信你会有更直观的认识。

PaaS 在 Serverless 时代的重生

PaaS 本身的概念挺大，广义的说它处于 IaaS 和 SaaS 之间，我们先从一个具体的产品说起：GAE（Google App Engine）。2006 年 AWS 推出了 IaaS 的云计算，Google 认为云计算不应该是 IaaS 这样的底层形态，所以在 2008 年推出了自己的云计算代表产品 GAE（关于这里的发展缘由，可以参考张磊的这篇文章：容器十年 ，一部软件交付编年史）。

初推出的 GAE，也像 Lambda，让人眼前一亮，但是很快开发者就发现它的限制非常多，用今天的话说就是典型的“我不要你觉得，我要我觉得”，最后的结果就是大家都纷纷回到了 IaaS 的怀抱。

到后来的 PaaS 产品比如 Cloud Foundry，这类 PaaS 产品相对更实际一些，底层 IaaS 还是云厂商提供，上层提供一套应用管理生态，背后的思想还是不希望开发者通过 IaaS 这么底层的方式去使用云计算，而是从 PaaS 开始，不过它也不是 Serverless 化的，你还是要考虑服务器的维护、更新、扩展和容量规划等等。

SAE（Serverless App Engine）

到了现在，随着容器技术的成熟，以及 Serverless 理念的进一步发展，PaaS 和 Serverless 理念也开始融合，这样的产品既有 PaaS 为代表的【快速交付】，又有 Serverless 的特点【智能弹性】、【更低成本】，典型的产品代表就是阿里云在 2019 年推出的产品：SAE（Serverless App Engine）。

首先，它是一个 PaaS，再具体一点说，是一个应用 PaaS。这意味着大部分开发者使用起来都会非常自然，因为里面的概念你会非常熟悉，比如应用发布、重启、灰度、环境变量、配置管理等等。

同时，它也是 Serverless 化的。这意味着你不必再关心服务器，不用再申请机器，维护服务器，装一堆工具，而是按需使用，按分钟计费，结合强大的弹性能力（定时弹性、指标弹性）实现极致成本。

最后，得益于 Docker 为代表的容器技术的发展，SAE 解决了经典 PaaS 的突出问题（各种限制和强绑定），依托于容器镜像，在上面可以跑任意的语言的应用。

看到这里，我相信大部分开发者对于 PaaS 和 Serverless 结合的产品已经有了一个轮廓，在中国云原生用户调研报告中（2020 年） ，这种形态的 Serverless 产品开始被越来越多的开发者采用。

在这个基础上，还有另外一个话题值得再讨论一下，那就是微服务和 Serverless。

微服务和 Serverless

现在业界关于微服务和 Serverless，会有部分这样的认知：认为当前云计算典型代表技术是微服务，下一代的代表技术是 Serverless，这会让你觉得 Serverless 比微服务要先进，甚至会觉得未来有了 Serverless 就没有微服务了，类似下面这张图：

个人认为产生这一认知还是因为将 Serverless 的理念具象化到函数计算（FaaS）这样的产品。现在我们聊到微服务，会想到背后的技术框架，比如 Spring  Cloud、Dubbo，但是其实微服务这个词已经远远超出了纯技术框架的范畴，它背后也有核心的支撑思想，包括：

1. 微服务虽然一定程度上增加了技术复杂度，但是在一定规模下它会降低系统复杂度和组织复杂度。
2. 现代业务系统越来越复杂，很多业务系统会基于领域驱动设计（DDD），微服务其实是 DDD 背后的支撑技术。

单体、微服务和复杂度

所以如果到了 Serverless 时代就没法用微服务，我相信很多开发者会觉得不知所措，或者会“抵触未来”，因为他们会觉得有人给我描绘了一个未来，但是完全不知道怎么走过去。

抛开各种具体的技术实现，回到背后的理念，Serverless 代表的是一种无需关注服务器，降低使用云计算服务的理念，所以它和微服务其实不冲突，完全可以共存。在阿里云的 SAE 中，集成了微服务的能力（依托于阿里云产品 MSE），这意味着：

1. 部署在 SAE 这类 Serverless 平台上的应用，完全可以继续使用微服务开发，不需要经过任何改造。
2. 在 SAE 上甚至提供了很多微服务能力增强，包括了注册中心托管、服务治理等等，进一步降低开发者使用微服务的门槛和负担。

所以在 Serverless 类的 PaaS 产品上，Serverless 和微服务不再是对立的，开发者完全可以继续使用微服务技术开发，同时也可以享受 Serverless 理念所带来的【智能弹性】、【更低成本】等。

函数计算 FC

讲完 Serverless Application（应用），我们再来看看 Serverless Function（函数），FC 作为”根正苗红“的 Serverless 产品，相信大家都对它不陌生，经过这么些年的发展，它已经在前端 Serverless、多媒体处理、AI、事件类的场景（云产品事件、数据库变更事件等等）、物联网消息等场景得到了很好地应用，甚至也有越来越多的公司将业务完全构建在 FC 之上，比如：世纪联华的 Serverless 实践。

另外针对早期的很多技术限制，现在也已经有了解决方案：

1. 早期大多数的函数计算产品都对磁盘大小、代码包大小、运行时长、内存规格等有限制，阿里云函数计算推出了性能实例基本解决了这些限制。
2. 针对冷启动问题，可以使用预留性能实例解决。

下面我们就具体介绍部分使用 FC 的典型的场景。

前端 Serverless

前端经过了 Ajax、Nodejs、React 等技术迭代后，已经形成了相对成熟的技术体系，特别是 Nodejs，使前端和服务端产生了联系。

前端和后端的分工发挥了各个的优点，但是在协作的过程中也一直存在一个问题，后端同学通常是面向领域和服务提供接口，但是前端是面向用户具体的数据接口，有时候一个简单的需求会因为两边的定义和联调搞半天。所以也诞生了 BFF（Backends For Frontends）这样一层，谁使用谁开发，专门解决领域模型 - UI 模型的转换。

理想很美好，现实也很骨感，如果前端同学去做 BFF 这一层，发现要学习后端的 DevOps、高可用、容量规划等等，这些其实是前端同学不想关心的，这种诉求在 Serverless 时代得到了很好地解决，由 BFF 变为了 SFF（Serverless For Frontend）,让前端同学只要写几个 Function，其他都交给 Serverless 平台。

类似的还有服务端渲染 SSR（Server Side Rendering），本来前后端分工后，后端只需要写接口，前端负责渲染，但是在 SEO 友好以及快速首屏渲染等需求背景下，有时候会用到服务端渲染的方案，同样，使用 Serverless 前端同学又可以愉快地玩耍了。

其实现在很多偏前端产品里面（比如各类小程序以及语雀等产品），前端同学会全栈完成整体开发，越来越多地会用到 Serverless 相关技术。

当然，要用好 Serverless，需要完整的生态，包括相关的框架、运行时、工具链、配置规范等等，这方面可以参考阿里 Midway。

多媒体处理

现在在线教育、直播、短视频等行业都蓬勃发展，也催生了很多视频需求，包括视频的处理，例如视频剪辑、切分、组合、转码、分辨率调整、客户端适配等等，典型场景的比如：

• 每周五定期产生几百个 4G 以上的 1080P 大视频， 但是希望当天几个小时后全部处理完；
• 甚至您有更高级的自定义处理需求，比如视频转码完成后，需要记录转码详情到数据库，或者在转码完成后，自动将热度很高的视频预热到 CDN 上，从而缓解源站压力。

这些诉求在 Serverfull 的场景下，你可能需要搭建一套复杂的系统来支撑，但是如果使用 FC，那么你会发现一切都变得那么简单。

AI Serverless

AI Model Serving 是函数计算一个比较典型的应用场景。数据科学家训练好模型以后往往需要找软件工程师把模型变成系统或者服务，通常把这个过程称之为 Model Serving。函数计算无需运维和弹性伸缩的特性，正好符合数据科学家对高可用分布式系统的诉求。

Serverless 容器 - ASK

Kubernetes 作为生产级别的容器编排系统，现在已经成为了容器编排的事实标准，被广泛用于自动部署，扩展和管理容器化应用。它也有相应的 Serverless Kubernetes 产品，比如阿里云的 ASK、AWS Fargate 等。在这类产品中，你无需购买节点即可直接部署容器应用，无需对集群进行节点维护和容量规划，并且根据应用配置的 CPU 和内存资源量进行按需付费。ASK 集群提供完善的 Kubernetes 兼容能力，同时降低了 Kubernetes 使用门槛，让您更专注于应用程序，而不是管理底层基础设施。

如果您是 K8S 的重度用户，那么使用 Serverless Kubernetes 是一个不错的选择，典型客户场景包括：

• 微博：在 30s 之内可以极速扩容 500 个应用实例，应对跨年活动和热点事件；
• 旷视科技：基于 ASK 开发智能、免运维的 AI 应用平台；
• 趣头条：基于 ASK 构建 Serverless 大数据计算平台。

BaaS

上面提到的都是“计算类” Serverless 产品，FC、SAE、ASK 等，但是我们都知道，开发过程中不可能只有计算逻辑，还有很多其他依赖，比如存储、中间件等。BaaS（Backend-as-a-Service，后端即服务）类产品，提供基于 API 的服务，这些 API 一般都是按需使用、免运维、自动扩缩容的，所以他们也是 Serverless 的。

典型的比如阿里云的 OSS，具有与平台无关的 RESTful API 接口，可以在任何应用、任何时间、任何地点存储和访问任意类型的数据。

值得一提还有开发企业级应用时大家非常熟悉的中间件，以阿里为例当前也在进行 4.0 技术架构升级，全面 BaaS 化，统一运维、交付、计费、支持模式，开箱即用，产品化程度持续提升。

总结

总结一下，上面提到的一系列 Serverless 的产品，覆盖了前端、后端、容器、BaaS 各个领域，包括很多上面没有提到的（比如 CDN）其实也算是 Serverless 的产品，所以我不认同伯克利的 Serverless = BaaS + FaaS 的观点，但是我非常认可他的另一个观点：“Serverless will dominate cloud computing”。

Serverless 首先是一个理念，不是某一种具体的技术，当未来某一天，99% 的云产品都有 Serverless 化的形态时，云计算也就 Serverless 化了，这种变化我认为不是非黑即白的，不是推翻重来这种革命性的，而是全面地降低用户使用云的成本，全面地提升开发者的研发效率。

作者简介：陈涛，10 年软件开发经验，4 年创业经历，曾在淘宝、滴滴任职，关注云原生、微服务、Serverless 等技术领域，积累了在云计算、电商、从 0 到 1 创业等方面的研发、管理和业务经验。目前就职阿里云，在云原生应用平台从事 Serverless 应用引擎（SAE）的设计和研发。

原文链接：https://developer.aliyun.com/article/778597?

版权声明：本文内容由阿里云实名注册用户自发贡献，版权归原作者所有，阿里云开发者社区不拥有其著作权，亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容，填写侵权投诉表单进行举报，一经查实，本社区将立刻删除涉嫌侵权内容。