Serverless 2.0，鸡蛋仍是银弹？

做者 | Harry Chen
来源 | Serverless 公众号

导读：本篇旨在介绍 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 国内厂商的首创能力，也能领先全球，为技术界添砖加瓦。

此文只是抛砖引玉，仅表明我的观点，不对平台作我的喜爱选择。