起源 | 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，然而其实微服务这个词曾经远远超出了纯技术框架的领域，它背地也有外围的撑持思维，包含：
- 微服务尽管肯定水平上减少了技术复杂度，然而在肯定规模下它会升高零碎复杂度和组织复杂度。
- 古代业务零碎越来越简单，很多业务零碎会基于畛域驱动设计（DDD），微服务其实是 DDD 背地的撑持技术。
单体、微服务和复杂度
所以如果到了 Serverless 时代就没法用微服务，我置信很多开发者会感觉手足无措，或者会“冲突将来”，因为他们会感觉有人给我描述了一个将来，然而齐全不晓得怎么走过来。
抛开各种具体的技术实现，回到背地的理念，Serverless 代表的是一种无需关注服务器，升高应用云计算服务的理念，所以它和微服务其实不抵触，齐全能够共存。在阿里云的 SAE 中，集成了微服务的能力（依靠于阿里云产品 MSE），这意味着：
- 部署在 SAE 这类 Serverless 平台上的利用，齐全能够持续应用微服务开发，不须要通过任何革新。
- 在 SAE 上甚至提供了很多微服务能力加强，包含了注册核心托管、服务治理等等，进一步升高开发者应用微服务的门槛和累赘。
所以在 Serverless 类的 PaaS 产品上，Serverless 和微服务不再是对抗的，开发者齐全能够持续应用微服务技术开发，同时也能够享受 Serverless 理念所带来的【智能弹性】、【更低成本】等。
函数计算 FC
讲完 Serverless Application（利用），咱们再来看看 Serverless Function（函数），FC 作为”根正苗红“的 Serverless 产品，置信大家都对它不生疏，通过这么些年的倒退，它曾经在 前端 Serverless、多媒体解决、AI、事件类的场景（云产品事件、数据库变更事件等等）、物联网音讯等场景 失去了很好地利用，甚至也有越来越多的公司将业务齐全构建在 FC 之上，比方：世纪联华的 Serverless 实际。
另外针对晚期的很多技术限度，当初也曾经有了解决方案：
- 晚期大多数的函数计算产品都对磁盘大小、代码包大小、运行时长、内存规格等有限度，阿里云函数计算推出了性能实例根本解决了这些限度。
- 针对冷启动问题，能够应用预留性能实例解决。
上面咱们就具体介绍局部应用 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）的设计和研发。