简介： 本篇旨在介绍 Serverless 如今应用到应用（非病句）的各种困境，以及帮助用户如何去规避一些问题，提前了解方向。

浪潮

从 2014 年 Serverless 冒头至今，已经有无数的勇士在前面探路，阿里、腾讯、亚马逊、百度、华为等都不断推出自己的云服务，想要在这一浪潮中分一杯羹。除了最早的亚马逊，国内的战争一直在不温不火地进行，除了抢占市场外，还在不断寻求新的解决方案，期待有朝一日，能够凭着新方案，吸引大波用户。

从全球来看，Serverless 整体的趋势还算不错，特别是国内腾讯阿里的推动，热潮不断。对比其他的关键字，我们发现 Serverless 和微服务都在持续增长中，总体说，轻量化、分布式、可维护是一个趋势，这符合当下的编码习惯。

▲数据来源于 Google Trends

阿里云借由原有的首发优势，同时，加上首个支持预留/按量实例混合伸缩和预付费模式这些能力，不断扩大用户基数，同时在每年的双十一双十二活动中应用落地，使得稳定性整体又上了一个台阶。同时在 2020 年 7 月信通院可信云大会上，阿里云函数计算 FC 以 21 项测试全部满分的成绩首批通过可信云函数即服务认证。

▲图片来自阿里云 2020 线上峰会

腾讯借由现有的小程序体系，结合小程序云开发，和 Serverless 绑定，让用户迅速增长起来，这步棋还是下得恰到好处，能让很多开发者无缝地享受到云的能力，既便利又能扩大影响力。

▲图片来源于腾讯云

在一年的营销和推广之下，不断有人尝试和使用，在国内激起了不小的水花，其中不乏有整体将业务迁移到 Serverless 体系的，也有胆小的，在远处观望。

好在有大公司的不断推动，阿里淘宝、飞猪、高德、考拉，以及京东、滴滴、字节等等，越来越多的企业开始逐步尝试把业务迁移到 Serverless 环境，一方面给其他观望的人打了样，也促进了整个生态的正循环。

抛开这些大企业，中小型企业、个人开发者依旧是科技领域的大多数，除开观望的，剩下的，都是跃跃欲试，想用但是摸不着门道的人群，现在各家云厂商在发力争取的，也正是这部分人。而现有问题最大的，正也是这部分用户。

困境

很久之前，我们开发的软件由 C/S 和 MVC 的架构，转变为 SOA，从单体架构，到服务化，再到更细粒度的微服务化，应用开发之初就是为了应对业务特有的高并发、容错等特性，需要很高的性能及可扩展性。

几十年前（1975 年）Fred Brooks 就在 The Mythical Man-Month 中就写到了这句话。

那么，Serverless 会是解决软件开发复杂度和效率之间的那颗银弹吗？

从 CNCF Cloud Native Interactive Landscape 中，我们可以发现，做基建（托管平台）的企业有不少，我们了解的阿里云、腾讯、华为、Amazon 等都在其中，而 Framework 以及更上层的业务工具场景其实不算很多，抛开 aws 的几个工具，只有 Python、JavaScript 和 Java 的工具，比较出名的 Serverless Framework 加上 Spring Cloud Fucntion，基本上能涵盖全球的很大一部分场景。

对于 Python、JavaScript 这种天生支持 Lambda 的开发语言，和 FaaS 简直是完美结合。Serverless Framework 的调研报告也很好地说明了这一点。NodeJS、Python 是 FaaS 使用率前二的语言。

▲图片来源于阿里云技术博客

我们知道，因为 JVM 占用的内存比较大，所以 Java 应用的启动会有点慢，不太适合 FaaS 这个场景，这也是 Java 在使用率上偏低的原因。

所以在整个 Serverless 架构上，语言适合度占了非常大的部分。这也带来了一个最大的问题：用户人群和基数。
身为前端，大部分的场景都在前台页面展示、渲染，跟 JavaScripts/HTML/CSS 打交道，很少涉及服务端的部分，唯一有交集的则是 Node.js 开发者，在前后端领域都有着不错的输出。

而 JavaScript 在各家云平台占优的趋势下，是否在使用的，正是这部分人群。这部分人群隶属于前端，自前端分化而来，但是基数相比传统后端，还是难以快速增加。

如何尽可能满足原有已经满足的人的需求，同时还要扩大使用人群，收割市场，这正是各家云平台争相角逐之处，也是当前的困境之处。

抉择

为了解决当前的人群问题，只有不断地尝试，至少国内的云厂商在这一方面一直在突破。我们能看到的，这一年，一直在做的：

• 满足不同层面，不同场景的用户需求；
• 尝试用新技术，打破现有的语言困境。

阿里云上的 Serverless 产品更是帮助微博、石墨文档、跟谁学、Timing、联合利华等数万家企业客户成功落地 Serverless，覆盖前端全栈、小程序、新零售、游戏互娱、在线教育等全行业应用场景。可以看到，在企业的业务落地方面，阿里云还是非常快速的。

除了函数计算 FC 和 SAE 两款产品之外，阿里云 Serverless 产品矩阵还包括面向容器编排的 Serverless Kubernetes、以及面向容器实例的 ECI 等，它们构成了当前所有云厂商中最完整的 Serverless 产品家族。

基本上，阿里云已经将现有各种场景迁移到 Serverless 的路子打通，从应用迁移、容器化、函数化等几个方面都包含了，同时也在弹性的角度，用实际的商业价值（钱）来吸引客户。很明显，阿里云已经认识到当前的桎梏，在尝试不同场景、不同语言的突破。

相对的，腾讯云在这个层面，更偏向于体验，一站式，极速部署，让用户以极低的成本切入，以体验为粘度去吸引用户。下面的广告我们在访问公众号/网站时经常会看到。

这一年，我们收到腾讯云的培训推送很多，从年初的 Serverless Framework 集成，到后面的 Serverless Days，以及 CloudBase Serverless 云端一体化产品方案等等。

从容器层 Custom Runtime 方案，到应用层平台方案，腾讯云也都有一一对应，甚至在去年底，还发布了国内首个 Serverless Mysql 数据库（有意思）。

这些林林总总的变化，都是源自于不同用户层面的需求，都是在争一个用户群，以及未来的商业化体系。

云计算正在各领域持续深化其影响力，同样，各领域下日益变化的需求，也在倒逼云计算不断进行自我优化。
反观用户侧，除了下定决心吃螃蟹的企业们，剩下的更多的是听着免费就来入场的羊毛党（别小看他们，只要是不花钱，什么奇怪的事情都会做），以及抱着学习的心态和部署个人服务的用户。

云平台更想吸引的是后者。这部分人群的问题依旧没有解决。我们会发现，现有的云平台，还处在一个吸引用户，让用户自行摸索的阶段，并没有做出对比，或是 Serverless 和传统的区别之处。

棒槌

去年一年，阿里双促使用 Serverless 扛下了大流量，也有其他公司纷纷使用 Serverless 应用到业务的案例，这些，其实都是建立在足够强的保障体系下的实践，如何应用到自己或者企业的业务身上，才是真正的难点。

对一个企业很简单的事情，比如要求提供几台虚拟机，对个人开发者可能就是非常困难的。大公司有各种缓存服务，有各种兜底的能力，而小公司或是个人开发者，只能听听，一笑而之。之前 Netflix 实行业务微服务化，拆开了非常多的接口模型，并做了足够的分布式架构和管理体系，也不是所有的公司都能学习并落地的。沉淀下来的只有经验。

对于用户来说，在这些纷繁的宣传中，需要去选择最适合自己的方案，其实是比较困难的，一般会先行熟悉，然后从自己比较了解的平台入手。核心会有几个疑问：

• 我有一个应用，我怎么用上 Serverless？
• 我有一个应用，是否要变为函数才能上 Serverless？
• 上了 Serverless 之后，我的业务如何保持稳定？
• 最关键的，Serverless，我的业务怎么付钱？

比如传统应用如何上 Serverless，现有平台提供的迁移已存在的业务上 Serverless 方案，基本使用的是 Custom Runtime 方案，通过 HTTP 协议通信完成事件的响应处理（即开发一个特定端口，由容器内部做转发的方案）。

▲图片来自于阿里云 Custom Runtime 方案

这样将应用迁移到 Serverless 平台是现在的主流方式，也是云平台推荐的方式。但是这样做，是否真的没有后遗症？

答案肯定是有的，最明显的就是启动时间。容器的冷启动 + 业务的启动时间，如果是函数，那么基本能在 2s 内启动完毕，提供服务，而应用包含了太多的逻辑，导致启动时间可能长达 2~10s，这还是我们使用 Node.js 业务估算的平均时间，如果是其他语言，时间还要大幅增加。

函数的整体可访问时间会控制在比较小的范围，而应用启动，一般会比较久。

这就导致了，整体应用的体验如果纯使用弹性的模式，是不太能接受的。当然，我们可以用预留模式（固定一些容器）来解决冷启动的问题，不过大家可以去算算价格，是否 ECS 会更便宜一些。

第二个问题是包大小，现有函数部署，云平台一般控制在 50M，这不仅仅是因为存储的问题，也是因为函数在启动时会下载包，解压，为了极速启动，减少网络开销，必然是希望包越小越好。应用的包，如果是纯 Node.js 应用还好，资源往往能卡在 100M 内，但是加上前端资源（传统的服务端渲染等），整个包体积就会上到几百 M，要知道前端可能不太关心引入包的大小（毕竟 webpack 打包会自动剔除），但是这可能是上到 Serverless 环境的较大隐患。

第三个问题是开发方式，很多由于 Serverless 本身的限制导致业务代码的写法需要一些变化，这不仅需要理解 Serverless 环境的运作机制，也需要有相应的解法。比如文件上传，传统应用可以完成表单上传，但是在 Serverless 网关的拦截下，需要通过不同的方式来做，这使得传统应用开发和 Serverless 应用开发的代码不够统一，导致一些维护成本。

还有固定的网络环境可能会导致网络隔离，无法连接特定的服务。定制的容器环境，以往的修改 nginx 支持特定协议，路由转发都无法实现了。乃至 Serverless 最为美好的弹性行为，也会使得代码跟原先预想的不一致，比如本地的缓存、固定 ip 代理等等，这些都是和原有应用不同的。

种种可能的问题，你是否还能简单地将业务迁移到 Serverless ？

冷静下来，经过我们整体的实践，Serverless 的确能带给我们好处。上个月有个客户跟我讲，以前纯用阿里云 ECS，每个月要花好几千，现在上了 Serverless，每个月只要 8 块钱（真实场景），可以说，这个吸引力是非常巨大的。

这点，对于个人用户，特别是学生/独立开发者特别有吸引力，能够以极低的价格，来完成功能交付。

虽然 Serverless 有一些问题，但是，真的省钱，只要业务没有状态，也没什么严苛的启动要求（可以有一定优化减少启动时间），能理解 Serverless 基础的原理，就能规避我上面描述的问题。

那，Serverless 一定是当前最省钱的方式，是你钱包最棒的伙伴。

趋势

在过去的一年里，我们发现了一个特点，前端用户分化为两极，一边是希望面向云原生更进一步，全配置的方式将编写代码的机会变的更低（nocode）；另一边希望以原有的应用模式逐步演进而来，以及希望以一个大而全的应用进行开发部署，从而减少开发协作成本。

比如 Serverless Framework，腾讯去年改了三个不同的 yml 版本，用来支持纯函数，面向场景的业务。

▲Serverless Framework 的 yml 配置

而下半年推出的腾讯云云开发，也有着类似的方式，只是配置从 yml 变成了 JSON，但是核心没有太多变化。

{
  "envId": "fx", "framework": { "plugins": { "server": { "use": "@cloudbase/framework-plugin-node", "inputs": { "entry": "./api/index.js", "path": "/api", "name": "github-stats-api", "wrapExpress": true } }, "pin": { "use": "@cloudbase/framework-plugin-node", "inputs": { "entry": "./api/pin.js", "path": "/api/pin", "name": "github-stats-pin", "wrapExpress": true } } } } }

▲腾讯云开发的全配置 JSON

阿里云的 template.yml 多年也变化不大。

倒是年底推出的 Serverless Devs 吸引了一波眼球，逐步把本地工具链的中心，慢慢移动到配套的管理平台，想必未来会有不同的变化。

和单独售卖的阿里云不同是，腾讯云开发出炉了打包售卖的方式（函数 + 存储 + 数据库资源）来满足用户。这点在小程序开发上有非常大的优势，工具 + 资源的整合上，腾讯做得很不错。

就像之前说的那样，云厂商在逐步弥补自身的不足，利用不同场景的来做差异化竞争，这是用户乐于看到的。

而用户的心智，则没有太多的变化，由于平台包裹得足够好（美好），我们发现，后一半人（应用开发）逐步占据了上风，业务不管如何上手，都是以应用的模式来进行开发，以应用开发的思路在开发、部署、调试，俨然只是把 Serverless 容器当作原有的服务器，充其量只是在原有的服务器上增加了一些限制，比如不能登录等等。

从方案的选择中，我们也发现，前端更希望以一体化开发的方式（前后端在一起）去开发业务，这就使得整个体系，和原来的设想偏离得非常之多。

不过这是阿里内部的情况，不得不说，这是一个复古的趋势（可能也是一个国内的趋势），可能也是一个最容易被开发者接受的未来。

希望

在此前 InfoQ 报道的一篇《2019 年 Serverless 应用报告：三分之二的落地实践都成功了？》的文章，其中提到了对于企业和开发者来说，促使他们使用 Serverless 最直接的因素有以下三点：

• 首先，“减少运营成本”是大家采用 Serverless 的第一大原因，应用 Serverless 之后，就无需为潜在的流量高峰购买大部分时间处于空闲状态的服务器机架；
• 第二，“自动按需扩展”，采用 Serverless 之后，可以随时扩展到当前的使用量，消除了意外或者季节性流量高峰的困扰；
• 第三，“无服务器维护”，由于企业中大部分开发人员都是软件工程师，并不是系统管理员，所以对于软件的修复、保护和管理并不擅长，而使用 Serverless 之后，这些工作都可以交给供应商，他们只需专注于软件开发。

每一点都足够吸引人，但在这蜜糖之中，有刺也有糖，在使用之前，我们最好能想一想，到底怎么用才是最好的。

希望未来的 Serverless 形态，能够足够满足业务的诉求，不管是函数态，还是应用态，都能在其之上赋予更强大的场景和能力，Serverless 国内厂商的独创能力，也能领先全球，为技术界添砖加瓦。

此文只是抛砖引玉，仅代表个人观点，不对平台做个人喜好选择。

作者：Harry Chen

原文链接

本文为阿里云原创内容，未经允许不得转载