Serverless ：让「前端开发者，满满的干货

• 易于开发，前后端同仓库，无缝融合一体开发

• 易于部署，前后端一同发布与部署

• 易于维护，后端代码使用Serverless 部署，运维难度低

而在开发时，我们也提供了诸多的功能来帮助开发者加速研发。

“零 API 调用”

Hooks 支持

在阿里内部，我们提供了中后台一体化与搭建模块一体化两种解决方案。其中，中后台一体化应用在内部已经落地了 300+ 应用，快速且高效的支撑了各个 BU 的中后台需求。

淘系模型驱动解决方案

模型驱动是淘宝导购业务开发过程中沉淀的一种开发方式，面向导购大量的召回补全展现需求。通过配置面板，将模型、数据来源、插件配置组合，最终生成业务逻辑代码，供业务消费。

整个操作面板的核心关注点在右侧的流程画布上，我们希望使用固定的流程来解决这一类业务问题，这些逻辑遵从预定义的操作路径。在云市场轻应用外包介入开发的模式中，由内部同学生成物料，外包同学开发模块和选择业务字段并串联流程，帮助内部同学节省了大量流程串联和模块联调成本，相比传统的开发方式整体提效10%左右。这也是一种创新的协同模式，物料丰富后会有更大的提升空间。

数据源（召回） --> 模型（补全） --> 扩展逻辑（插件）

模型驱动解决方案在淘宝很好的解决了业务问题，但是面临更多的场景需要的是更加灵活的模板定制能力，因此未来模型驱动会在灵活的模板配置化上发力、对节点物料的沉淀上建立更加完善的机制、支持Web IDE等插件，并在更多的场景上支持业务的落地，让不同的业务场景可以更加便利的建立自己的“三板斧”。

考拉 Dart 一体化解决方案

考拉大前端自 2020 年 3 月份开始尝试 Flutter 的应用，部分客户端和前端同学均参与进 Flutter 的开发，对于 Dart 相对熟悉，所以 Dart 一体化解决方案最初目的主要是考虑帮客户端同学解决开发提效的问题。考拉之前主要在使 Node.js Runtime 的 Serverless 方案，相比于 Java Script，Dart 对于客户端同学也更友好一些，同时也不断有客户端同学提出 Dart Serverless 的诉求。

在函数计算 FC 研发团队的帮助下，考拉基于 Dart Runtime 的前期测试版本，快速完成了考拉 App 今日活动 Tab 的改造重构，并已于 9 月底灰度上线。10 月中下旬，基于 Dart Runtime 开始和 DEF 平台对接，最终 DEF Serverless 创建面板，会透出 Dart 纯函数解决方案，目前和 FC 侧基本流程已调通，即将上线 Dart 的纯函数解决方案。

除了已上线的 Dart Ast 生成服务，考拉将基于 Dart Serverless 方案推出更多的业务场景，如 App 端数据模型的动态下发、业务逻辑的动态配置、Flutter 动态化尝试，以及 App 跨端搭建能力等。

除了以上 3 个解决方案，ICBU 团队研发的 EaaS 微应用级别的解决方案，天猫行业团队研发的面向轻店场景的原生小程序一体化 解决方案等，这里不展开一一介绍了。

▐  函数稳定性保障

---

最开始的时候，我们关注的重点是如何用 Node 完成业务逻辑，比如数据怎么组织、 Java 二方包怎么调用、怎么结合阿拉丁链路、线上 bug 怎么快速修复。现在有了这么多线上运行的业务，我们关注的重点已经从怎么完成业务需求，转变成如何高效地、稳定地完成业务需求。

线上稳定性，本质上是对问题的治理。从问题出发，可以分为以下几个主要环节：预防问题、发现问题、定位问题和解决问题。

在预防问题上，要尽可能降低问题发生的概率和缩小影响面，做好上线卡口，以及做好对应的预案。发现问题上要尽可能实现全链路监控，以及实现合理有效的报警分发机制。定位问题上，要尽可能缩短问题的定位时间，在报警元信息的基础上，做一些机器的辅助分析，关联上下文，从而做到半自动定位或提供更多有逻辑的上下文，来缩短人为定位问题的时间。在解决问题上，要保证解决方案的有效，安全以及快速。

大促稳定性保障手段

大促场景下， C 端场景需要重保，以下的稳定性保障手段经历数次大促压测，同时越是大促态，整个稳定性保障也愈发紧张。

稳定性是保障了，但是在之前我们是对照上述的文档完成上线流程的，流程冗长无比，最终并沉淀成一个作战手册，同时这些内容无法和应用关联，离散在文档角落，整个过程「又臭又长」。

上线流程 -> 作战手册一体化

因此，Serverless 研发平台上希望规范化整个流程，从从 强弱依赖梳理 -> 预案配置 -> 监控报警订阅 -> 单链路压测 -> 作战手册生成，记录所有函数上线过程，流程可追溯，文档可沉淀；另外预案、压测、监控等流程做到半自动化，减少上线时间。我们将每个流程节点定义成一个 SOP 单元，这样根据业务特性可以进行 SOP 流程的随意组装。

发布SOP流程

通过半自动化流程生产的作战手册，函数和作战手册关联的硬盘化记录方式，并结合自动限流和下游依赖分析以及预案生产，例如：通过预发流量录制的回放，自动分析出函数下游的强弱依赖，并录入强依赖负责人，方便出现线上问题的时候可以第一时间找到负责人排查问题；根据不同租户对单元化的需求，平台可以帮助用户进行多机房、多单元部署实现异地多活。这些都能够让业务的大促态变得更轻松一些。

淘系业务作战手册

专家应急响应

为解决线上问题定位慢的痛点，平台还提供了应急响应系统，当函数成功率降低触发报警时，平台会自动拉取函数以及下游多项数据信息，进行错误分析，快速产出错误报告推送给函数开发者。并引导开发者回到研发平台进行切流、执行预案等止血操作。例如，下游服务强依赖服务A成功率下降，导致函数自身成功率下降，需要联系服务A负责同学。

▐  租户运维

---

---

平台上的每个租户都有对应的租户管理员，对各自租户的函数稳定性负责，包括租户下函数的单元化部署规则、大促管控、自建网关配置、容器额度、租户私有解决方案等，为此平台提供了一系列运维工具。

租户大盘

帮助管理员更好的观测到租户下函数的服务质量，和容器额度使用状况，提供函数错误率和 RT 黑榜，并且每周都会有治理周报推送给管理员，帮助其更好的进行运维其租户下的函数。

函数盘点

帮助管理员细致的观测每个函数线上运行的具体状态，包括函数线上存在的版本、容器数量、 Runtime 版本、灰度、单元部署状况，甚至可以观测到函数部署是否均衡。

大促管控

平台还提供针对大促态的运维管控能力，管理员可以将租户下参与大促的函数服务一键切换到大促态，进行大促态的额外配置，比如大促容量配置，Broker 侧限流，网关侧统一监控预案等能力，保障大促的稳定。

一些思考

========

---

Serverless 云研发平台后续将在提升用户正向和逆向流程的效率上继续演进，L1 是希望让用户低成本的上手，L2 是希望让用户低成本的进行研发，让前端往应用研发更进一步。

以下是基于用户正向研发链路耗时统计的一些分析：

• 技术方案产出的时间较久，占比整体研发周期 5%，核心原因是服务物料难以检索以及服务可用性难以评估，领域模型沉淀不足；

• FaaS 整体研发占比 25%~30% ；模型驱动等可视化编排在物料准备完备的情况下，能够提效，但是不具备规模化场景；

• 联调耗时较久占整体成本 20% 左右，过度依赖预发环境，据统计，完成一个项目需要部署 50 次；

• 压测成本依然存在，平台熟悉成本过高。

当然还有监控运维逆向链路的一些分析：

小编13年上海交大毕业，曾经在小公司待过，也去过华为、OPPO等大厂，18年进入阿里一直到现在。

深知大多数初中级前端工程师，想要提升技能，往往是自己摸索成长或者是报班学习，但自己不成体系的自学效果低效又漫长，而且极易碰到天花板技术停滞不前！
因此收集整理了一份《2024年Web前端开发全套学习资料》送给大家，初衷也很简单，就是希望能够帮助到想自学提升又不知道该从何学起的朋友，同时减轻大家的负担。

由于文件比较大，这里只是将部分目录截图出来，每个节点里面都包含大厂面经、学习笔记、源码讲义、实战项目、讲解视频

如果你觉得这些内容对你有帮助，可以添加下面V无偿领取！（备注：前端）

7caidM-1710890449619)]
[外链图片转存中…(img-uvWh1UI8-1710890449620)]
[外链图片转存中…(img-RBAw3Odu-1710890449621)]
[外链图片转存中…(img-bnXMNlHs-1710890449621)]

由于文件比较大，这里只是将部分目录截图出来，每个节点里面都包含大厂面经、学习笔记、源码讲义、实战项目、讲解视频

如果你觉得这些内容对你有帮助，可以添加下面V无偿领取！（备注：前端）
[外链图片转存中…(img-mWK3T6ot-1710890449622)]