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

时间  2020-11-21 标签 前端 数据库 小程序 后端 服务器 架构 框架 less 运维 dom

头图.jpg

来源 | Serverless 公众号前端

背景

Serverless 概念从 2012 年开始提出，真正推出相关云产品是 2014 年 AWS 推出 Lambda。若是咱们将 Serverless 比做一个婴儿，那么它已经 6 岁了。数据库

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

图片1.png

刚刚出生的 Serverless后端

AWS 的巨大影响力以及自己携带的一身黑科技，确实让人记住了 Serverless，可是也正由于诞生的时候太印象深入，以致于如今提到已经 6 岁的 Serverless，不少人的印象仍是停留在Serverless=Lambda或者Serverless=FC（Function Compute），这不得不说是某种遗憾。服务器

2.png
如今的 Serverless架构

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

定义

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

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

因此不必再去给 Serverless 作什么定义，他自己已经描述得很清晰。咱们抛开概念，看看在各个具体技术领域的产品，相信你会有更直观的认识。dom

PaaS 在 Serverless 时代的重生

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

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

3.jpg

到后来的 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 产品开始被愈来愈多的开发者采用。

4.png

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

微服务和 Serverless

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

5.png

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

  1. 微服务虽然必定程度上增长了技术复杂度，可是在必定规模下它会下降系统复杂度和组织复杂度。
  2. 现代业务系统愈来愈复杂，不少业务系统会基于领域驱动设计（DDD），微服务实际上是 DDD 背后的支撑技术。

6.png
单体、微服务和复杂度

因此若是到了 Serverless 时代就无法用微服务，我相信不少开发者会以为不知所措，或者会“抵触将来”，由于他们会以为有人给我描绘了一个将来，可是彻底不知道怎么走过去。

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

  1. 部署在 SAE 这类 Serverless 平台上的应用，彻底能够继续使用微服务开发，不须要通过任何改造。
  2. 在 SAE 上甚至提供了不少微服务能力加强，包括了注册中心托管、服务治理等等，进一步下降开发者使用微服务的门槛和负担。

7.png

因此在 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 模型的转换。

8.png

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

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

其实如今不少偏前端产品里面（好比各种小程序以及语雀等产品），前端同窗会全栈完成总体开发，愈来愈多地会用到 Serverless 相关技术。

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

多媒体处理

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

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

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

9.png

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）的设计和研发。

联系我们 沪ICP备13005482号-10