传统业务在开发上线的过程中，需要团队合作，每个人开发一部分，合并代码，开发联调，然后进行资源评估，测试环境搭建、线上环境搭建、测试上线、运维。但是在 Serverless 时代下，开发者只需要开发自己那部分功能/函数，然后部署到测试环境、线上环境即可，后期很大一部分运维工作都不用考虑和担心。



今天大家对是不是该用 Serverless 存在疑问，很大程度上是因为缺少成功的案例和最佳实践。今年双11，阿里云实现了国内首例 Serverless 在核心业务场景下的大规模落地，扛住了全球最大规模的流量洪峰，创造了 Serverless 落地应用的里程碑。



如何让更多企业和开发者将 Serverless 应用到业务场景中，也就是让 Serverless 从理念到落地，是一个棘手的问题。



例如传统项目如何迁移到 Serverless，同时保障迁移过程业务连续性，在 Serverless 架构下如何提供完善的开发工具、有效的调试诊断工具，如何利用 Serverless 做更好的节约成本等，每一个都是难题。尤其涉及到在主流场景大规模的落地 Serverless ，更是并非易事。正因为这样，业界对于核心业务场景规模化落地 Serverless 最佳实践的呼唤更加迫切。



接下来我们来看看 Serverless 在落地过程中会遇到的痛点。

Serverless 落地之痛



快弹是 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%的用户已在生产环境中应用。”



面对 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% 以上。



image.png



当然，适用于 Serverless 的场景还有很多，需要更多行业的开发者们共同丰富。总的来说，今年 FaaS 的成绩单非常耀眼，在 双11 大促中，不仅承接了部分核心业务，流量也突破新高，帮助业务扛住了百万 QPS 的流量洪峰。

阿里云如何击破 Serverless 痛点？

那么，面对行业共有的Serverless落地之痛，阿里云是如何克服的呢？

1. 预留模式 + 按量模式消除冷启动

在 2019 年的 Serverless 2.0 重大升级中，阿里云函数计算率先支持了预留模式，接着 AWS Lambda 几个月后，也上线了类似的功能。



为什么阿里云会率先要解决这一难题？



阿里云 Serverless 团队不断探索真实业务的需求，按量模式的按需付费模式，虽然非常的诱人，但是冷启动时间过长，因此把核心在线业务拒之门外。接下来阿里云着重分析了核心在线业务的诉求：延时小，保证资源弹性。那如何解决呢？



请看下图，这是一个非常典型的业务曲线图，用预留模式方式满足底部固定的量，用弹性能力去满足 burst 的需求。针对 burst 扩容，我们利用两种扩容方式结合进行满足：按资源扩容与按请求扩容，比如用户可以只设置 CPU 资源的扩容阈值为 60%，当实例的 CPU 达到阈值后就会触发扩容。此时的新请求并没有立即到扩容实例，而是等待实例准备好后再导流，从而避免了冷启动。同理，如果只设置了并发度指标的扩容阈值为 30（每一个实例承载的并发度），同样满足这个条件后，也会触发同样流程的扩容。如果两个指标都进行了设置，那么先满足的条件会先触发扩容。



通过丰富的伸缩方式，阿里云函数计算解决了 Serverless 冷启动的问题，很好的支撑了延时敏感业务。



“提升效率”本应该是 Serverless 的优势，但对于核心应用来说，"快" = "风险大"，用户需要经过 CI 测试，日常测试，预发测试，灰度部署等几个流程验证，才能确保函数的质量。这些流程是阻碍核心应用使用 FaaS 的绊脚石。



针对于这个问题，阿里云函数计算的策略是“被集成”，把研发平台的优势与阿里云函数计算进行结合，既能满足用户的 CI/CD 流程，又能享受到 Serverless 的红利，帮用户跨过使用 FaaS 的鸿沟。



阿里集团内部通过暴露标准的 OpenAPI 与各个核心应用的研发平台进行集成，经过双十一业务研发的验证，研发效率大大提高了 38.89 %。在公有云上与云效平台集成，把研发流程与 FaaS 结合的更紧密、更顺畅，帮助集团外的业务提高人效。



image.png

3. 中间件连通

核心应用离不开上下游的配合，一旦核心应用使用了函数计算，又该如何与中间件相配合？



传统应用开发需要集成各类中间件的 SDK，进行打包上线，但对于 Serverless 的函数来说，代码包的大小就是一个硬伤，这个问题将将直接影响冷启动的时间。阿里云函数计算经过两个阶段的发展，第一个阶段我们通过搭建中间件 Proxy，通过 Proxy 去打通中间件，函数只用单一的协议与 Proxy 进行交互，从而 offload 掉中间件的 SDK 的包袱。



第二个阶段：随着中间件能力的下沉，一些控制类型的需求也被提上了议程，比如：命令下发，流量管理，配置拉取等等，期间阿里云拥抱了开源组件 Dapr，利用 Sidecar 的方式 Offload 中间的交互成本。上述的方案，是基于阿里云函数计算的 Custom Runtime，以及 Custom Container 功能完成的。



image.png

4. 极致的开发体验



远程调试、日志查看、链路追踪、资源利用率，以及完善周边工具链是开发者的必备能力，阿里云函数计算同时启动了不同的攻关小组。



首先与 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 引领下一个十年

“劳动生产力的最大激进，以及运用劳动时所表现的更大熟练、技巧和判断力，似乎都是劳动分工的结果。” 



这是摘自《国富论》的一段话，强调的是“劳动分工” 的利害关系，任何一个行业，市场规模越大，分工将会越细，这也是著名的“斯密定理”。



那么，接下来的技术十年是什么呢？答案是：Serverless。



Serverless 抹平了研发人员在预算、运维经验上的不足，在对抗业务洪峰的情况下，绝大多数研发也能轻易掌控处理，不仅极大地降低了研发技术门槛，同时大规模提升了研发效率，线上预警、流量观测等工具一应俱全，轻松做到了技术研发的免运维。



可以说 Serverless 是更细粒度的分工，让业务开发者不再关注底层运维，只关注于业务创新，以此大大提高了劳动生产力，这就是“斯密定理”效应，也是 Serverless 成为未来必然趋势的内在原因。



当下，整个云的产品体系已经 Serverless 化，70% 以上的产品都是 Serverless 形态。对象存储、消息中间件、API 网关、表格存储等 Serverless 产品已经被广大开发者熟知。而下一个十年， Serverless 将重新定义云的编程模型，重塑企业创新的方式。



原文链接：Serverless 落地之痛怎么解？