简介：本篇旨在介绍 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
原文链接
本文为阿里云原创内容，未经容许不得转载