传统业务在开发上线的过程中，需要团队合作，每个人开发一部分，合并代码，开发联调，然后进行资源评估，测试环境搭建、线上环境搭建、测试上线、运维。但是在 Serverless 时代下，开发者只需要开发自己那部分功能/函数，然后部署到测试环境、线上环境即可，后期很大一部分运维工作都不用考虑和担心。
今天大家对是不是该用 Serverless 存在疑问，很大程度上是因为缺少成功的案例和最佳实践。今年双11，阿里云实现了国内首例 Serverless 在核心业务场景下的大规模落地，扛住了全球最大规模的流量洪峰，创造了 Serverless 落地应用的里程碑。
如何让更多企业和开发者将 Serverless 应用到业务场景中，也就是让 Serverless 从理念到落地，是一个棘手的问题。
例如传统项目如何迁移到 Serverless，同时保障迁移过程业务连续性，在 Serverless 架构下如何提供完善的开发工具、有效的调试诊断工具，如何利用 Serverless 做更好的节约成本等，每一个都是难题。尤其涉及到在主流场景大规模的落地 Serverless ，更是并非易事。正因为这样，业界对于核心业务场景规模化落地 Serverless 最佳实践的呼唤更加迫切。
接下来我们来看看 Serverless 在落地过程中会遇到的痛点。
Serverless 落地之痛
痛点1：冷启动耗时长
快弹是 Serverless 天然自带的属性，但是快弹的条件是要有极致的冷启动速度去支撑。在非核心业务上，毫秒级别的延时，对业务来说几乎不受影响。但是，对于核心业务场景，延时超过 500 毫秒已经会影响到用户体验。虽然 Serverless 利用轻量化的虚拟技术，不断的降低冷启动，甚至某些场景能降低到 200 毫秒以下。
但这也只是理想的独立运行场景，在核心业务链路上，用户不仅是运行自己的业务逻辑，还要依赖中间件、数据库、存储等后端服务，这些服务的连接都要在实例启动的时候进行建立连接，这无形中加大了冷启动的时间，进而把冷启动的时间加长到秒级别。对于核心在线业务场景来说，秒级别的冷启动是不可接受的。
痛点2：与研发流程割裂
Serverless 主打的场景是像写业务函数一样去写业务代码，简单快速即可上线，让开发者在云上写代码，轻松完成上线。然而在现实中，核心业务的要求把开发者从云上拉回到现实，面对几个灵魂拷问：如何做测试？如何灰度上线？如何做业务的容灾？如何控制权限？当开发者回答完了这些问题，就会变的心灰意冷，原来在核心业务上线中，“函数正常运行”只占了小小的一环，离上线的距离还有长江那么长。
痛点3：中间件的连通问题
核心在线业务不是独立函数孤立运行的，需要连接存储、中间件、数据中后台服务，获取数据后再计算，进而输出返回给用户。传统中间件客户端需要打通和客户的网络、初始化建连等一系列操作，往往会使函数启动速度下降很多。Serverless 场景下实例生命周期短、数量多，会导致频繁建连、连接数多的问题，因此针对在线核心应用常用的中间件的客户端进行网络连通优化，同时对调用链路进行监控数据打通，帮助 SRE （Site Reliability Engineer ）从业者更好的评估函数的下游中间件依赖情况，对于核心应用迁移上 Serverless 非常重要。
痛点4：可观测性差
用户大多数的核心业务应用多采用微服务架构，看核心业务应用的问题也就会带有微服务的特性，比如用户需要对业务系统的各种指标进行非常详尽的检查，不仅需要检查业务指标，还需要检查业务所在系统的资源指标，但是在 Serverless 场景中没有机器资源的概念，那这些指标如何透出？是否只透出请求的错误率和并发度，就可以满足业务方的需求？
实际上，业务方的需求远不止这些。可观测性做的好坏还是源于业务方是否信任你的技术平台。做好可观测性是赢得用户信任的重要前提。
痛点5：远程调试难度高
当核心业务出现线上问题时，需要立即进入调查，而调查的第一要素就是：现场的保留，然后登录进行调试。而在 Serverless 场景中没有机器层面的概念，所以如果用户想登录机器，在现有的 Serverless 基础技术之上是很难做到的。当然原因不仅限于此，比如 Vendor-lockin 的担心等。
上面几大类痛点的概括，主要是针对开发者的开发体验，对于实际的开发场景中，是否真的是"提效"，而不是新瓶装旧酒。目前仍有大部分核心应用开发者对 Serverless 还是持有观望状态，当然也不乏一些质疑观点，认为 FaaS 只适合小业务场景以及非核心业务场景。
果真如此吗？
Serverless 的双11 “大考”
2019 年 12 月咨询公司 O’Reill发布 Serverless 使用调研中，已有 40% 的受访者所在的组织采用了 Serverless。2020 年 10 月，中国信息通信研究院发布的《中国云原生用户调研报告》指出：“Serverless 技术显著升温，近 30%的用户已在生产环境中应用。”
2020 年，越来越多企业选择加入 Serverless 阵营，翘首以待更多 Serverless 规模化落地核心场景的案例。
面对 Serverless 开发者数量的稳步增长的现状，阿里巴巴年初就制定了“打造 Servrelss 双11”的策略，目的不只是单纯的去抗流量、打峰值，而是切实的降成本，提高资源利用率，通过“双11 技术炼金炉”把阿里云 Serverless 打造成更安全、更稳定、更友好的云产品，帮助用户实现更大的业务价值。
与过去 11 年的双11都不同的是，继去年天猫双11核心系统上云后，阿里巴巴基于数字原生商业操作系统，实现了全面云原生化，底层硬核技术升级带来了澎湃动力和极致效能。以支撑订单创建峰值为例，每万笔峰值交易的 IT 成本较四年前下降了80%，Serverless 也迎来了首次在双11 核心场景下的规模化落地。
场景一：前端多场景
2020双11，阿里巴巴集团前端全面拥抱云原生 Serverless，淘系、飞猪、高德、CBU、ICBU、优酷、考拉等，共同落地了以 Node.js FaaS 在线服务架构为核心的云端一体研发模式。今年双11在保障稳定性、高资源利用率的前提下，多业务线的重点营销导购场景实现了研发模式升级。前端 FaaS 支撑的云端一体研发模式交付平均提效 38.89%。依托 Serverless 的便利性和可靠性，淘宝、天猫、飞猪等 双11 会场页面快捷落地 SSR 技术，提高了用户页面体验，除了保障大促以外，日常弹性下也较以往减少 30% 计算成本。
场景二：个性化推荐场景
Serverless 天然的弹性伸缩能力，是“个性化推荐业务场景”选择由 Serverless 实现的最重要原因，数以千计的异构应用运维成本一直是这个场景下的痛点。
通过 Serverless 化进一步释放运维，让开发者专注于业务的算法创新。目前这个场景的应用范围越来越广，已经覆盖了几乎整个阿里系 APP：淘宝，天猫，支付宝，优酷，飞猪等等，因此我们可以对机器资源利用率方面做更多的优化，通过智能化的调度，在峰值时的机器资源利用率达到了 60%。
场景三：中、后台场景
2020年，世纪联华双11基于阿里云函数计算（FC）弹性扩容，在大促会场 SSR、线上商品秒杀、优惠券定点发放、行业导购、数据中台计算等多个场景进行应用，业务峰值 QPS 超过 2019 年 双11 的 230%，研发效率交付提效超过 30%，弹性资源成本减少 40% 以上。
当然，适用于 Serverless 的场景还有很多，需要更多行业的开发者们共同丰富。总的来说，今年 FaaS 的成绩单非常耀眼，在 双11 大促中，不仅承接了部分核心业务，流量也突破新高，帮助业务扛住了百万 QPS 的流量洪峰。
阿里云如何击破 Serverless 痛点？
那么，面对行业共有的Serverless落地之痛，阿里云是如何克服的呢？
- 预留模式 + 按量模式消除冷启动
在 2019 年的 Serverless 2.0 重大升级中，阿里云函数计算率先支持了预留模式，接着 AWS Lambda 几个月后，也上线了类似的功能。
为什么阿里云会率先要解决这一难题？
阿里云 Serverless 团队不断探索真实业务的需求，按量模式的按需付费模式，虽然非常的诱人，但是冷启动时间过长，因此把核心在线业务拒之门外。接下来阿里云着重分析了核心在线业务的诉求：延时小，保证资源弹性。那如何解决呢？
请看下图，这是一个非常典型的业务曲线图，用预留模式方式满足底部固定的量，用弹性能力去满足 burst 的需求。针对 burst 扩容，我们利用两种扩容方式结合进行满足：按资源扩容与按请求扩容，比如用户可以只设置 CPU 资源的扩容阈值为 60%，当实例的 CPU 达到阈值后就会触发扩容。此时的新请求并没有立即到扩容实例，而是等待实例准备好后再导流，从而避免了冷启动。同理，如果只设置了并发度指标的扩容阈值为 30（每一个实例承载的并发度），同样满足这个条件后，也会触发同样流程的扩容。如果两个指标都进行了设置，那么先满足的条件会先触发扩容。
通过丰富的伸缩方式，阿里云函数计算解决了 Serverless 冷启动的问题，很好的支撑了延时敏感业务。
- 核心业务研发提效 38.89%
“提升效率”本应该是 Serverless 的优势，但对于核心应用来说，“快” = “风险大”，用户需要经过 CI 测试，日常测试，预发测试，灰度部署等几个流程验证，才能确保函数的质量。这些流程是阻碍核心应用使用 FaaS 的绊脚石。
针对于这个问题，阿里云函数计算的策略是“被集成”，把研发平台的优势与阿里云函数计算进行结合，既能满足用户的 CI/CD 流程，又能享受到 Serverless 的红利，帮用户跨过使用 FaaS 的鸿沟。
阿里集团内部通过暴露标准的 OpenAPI 与各个核心应用的研发平台进行集成，经过双十一业务研发的验证，研发效率大大提高了 38.89 %。在公有云上与云效平台集成，把研发流程与 FaaS 结合的更紧密、更顺畅，帮助集团外的业务提高人效。
- 中间件连通
核心应用离不开上下游的配合，一旦核心应用使用了函数计算，又该如何与中间件相配合？
传统应用开发需要集成各类中间件的 SDK，进行打包上线，但对于 Serverless 的函数来说，代码包的大小就是一个硬伤，这个问题将将直接影响冷启动的时间。阿里云函数计算经过两个阶段的发展，第一个阶段我们通过搭建中间件 Proxy，通过 Proxy 去打通中间件，函数只用单一的协议与 Proxy 进行交互，从而 offload 掉中间件的 SDK 的包袱。
第二个阶段：随着中间件能力的下沉，一些控制类型的需求也被提上了议程，比如：命令下发，流量管理，配置拉取等等，期间阿里云拥抱了开源组件 Dapr，利用 Sidecar 的方式 Offload 中间的交互成本。上述的方案，是基于阿里云函数计算的 Custom Runtime，以及 Custom Container 功能完成的。
- 极致的开发体验
远程调试、日志查看、链路追踪、资源利用率，以及完善周边工具链是开发者的必备能力，阿里云函数计算同时启动了不同的攻关小组。
首先与 Tracing/ARMS 结合，打造清晰的链路追踪能力，与 SLS集成打造了全面的业务数据监控。因此，业务可以根据需求进行自定义，并且拥抱开源产品 Prometheus 暴露出资源利用率，支持远程调试能力的 WebIDE。
再加上阿里云近期刚开源的重磅武器：Serverless-Devs ，一个无厂商绑定的、帮助开发者在 Serverless 架构下实现开发/运维效率翻倍的开发者工具。开发者可以简单、快速的创建应用、项目开发、项目测试、发布部署等，实现项目的全生命周期管理。
Serverless 初始的痛点有很多，为什么阿里云却能把 Serverless 落地到各行各业？
首先，阿里云提供了所有云厂商中最完整的 Serverless 产品矩阵，包括函数计算 FC、Serverless 应用引擎 SAE、面向容器编排的 ASK、以及面向容器实例的 ECI。丰富的产品矩阵能够覆盖不同的场景，比如针对事件触发场景，函数计算提供了丰富的事件源集成能力和百毫秒伸缩的极致弹性；而针对微服务应用，Serverless 应用引擎能做到零代码改造，让微服务也能享受 Serverless 红利。
其次， Serverless 是一个快速发展的领域，阿里云在不断拓展 Serverless 的产品边界。例如函数计算支持容器镜像、预付费模式、实例内并发执行多请求等多个业界首创的功能，彻底解决了冷启动带来的性能毛刺等 Serverless 难题，大大拓展了函数计算的应用场景。
最后，阿里经济体拥有非常丰富的业务场景，可以进一步打磨 Serverless 的落地实践。今年，阿里经济体的淘系、考拉、飞猪、高德等都在双11核心业务场景使用了阿里云函数计算 FC，并顺利扛住了双11的流量高峰。
Serverless 引领下一个十年
“劳动生产力的最大激进，以及运用劳动时所表现的更大熟练、技巧和判断力，似乎都是劳动分工的结果。”
这是摘自《国富论》的一段话，强调的是“劳动分工” 的利害关系，任何一个行业，市场规模越大，分工将会越细，这也是著名的“斯密定理”。
同样，这一定理也适用于软件应用市场行业。随着传统行业进入了互联网化阶段，市场规模越来越大，劳动分工越来越细，物理机托管时代已经成为了历史，被成熟的 IaaS 层取代，随之而来的是容器服务，目前也已经是行业的标配。
那么，接下来的技术十年是什么呢？答案是：Serverless。
Serverless 抹平了研发人员在预算、运维经验上的不足，在对抗业务洪峰的情况下，绝大多数研发也能轻易掌控处理，不仅极大地降低了研发技术门槛，同时大规模提升了研发效率，线上预警、流量观测等工具一应俱全，轻松做到了技术研发的免运维。
可以说 Serverless 是更细粒度的分工，让业务开发者不再关注底层运维，只关注于业务创新，以此大大提高了劳动生产力，这就是“斯密定理”效应，也是 Serverless 成为未来必然趋势的内在原因。
当下，整个云的产品体系已经 Serverless 化，70% 以上的产品都是 Serverless 形态。对象存储、消息中间件、API 网关、表格存储等 Serverless 产品已经被广大开发者熟知。而下一个十年， Serverless 将重新定义云的编程模型，重塑企业创新的方式。
原文链接
本文为阿里云原创内容，未经允许不得转载。
