淘系前端搭建服务在2024年有哪些变化？（淘系包含什么）

构建：允许非技术学生使用拖放和配置方法生成页面来运行他们的业务。

模块：建筑工作的最小单元

天马先生：淘西建设服务团队正在打造一个服务于阿里巴巴内部多个BU的中间平台，帮助您快速搭建业务建设体系。

Zebra：基于天马服务建设的通用建设系统。我们帮助企业以较低的门槛和成本快速构建并向用户提供独特的页面。

Wormhole：天马支持的渲染服务。用于动态渲染页面并输出HTML以供用户访问。

去年大约同一时间，我写了一篇文章《淘宝前端在搭建服务上的探索》（https://zhuanlan.zhihu.com/p/137470317）。

我们讨论了过去建筑业的许多变化以及为什么会有像天马这样的建筑服务。相反，它是对过去的回顾。本文将重点介绍我们在过去一年中所做的一些事情和变化。

说到变革，我最近读了一些关于创新的文章。虽然每个人都对iPhone 4 作为真正的创新寄予厚望，但往往忽视了下一代iPhone 会变得更好。比上一代“更好”的更新（镜头、芯片）以及从产品到服务的升级（健康、钱包）。最讽刺的是，我最近尝试使用移动支付乘坐长沙地铁。我什至无法完成这个过程，无论是银联还是长沙地铁应用程序，但我最终能够通过Apple Pay完成这个过程。

这种构建是一个网络化的、部分集成的系统，它深受工程、DSL、甚至客户端渲染系统等垂直技术领域的影响，影响其他领域，而专注于特定领域的工作则较少。深度方向。不断地、渐进地做出积极的改变，连接上下游技术系统，面向用户（包括技术学生和非技术学生），提供不断改进的服务和产品，这是当前建设服务团队最重要的事情。

“建筑物”和“低代码”

建设还是一个很宽泛的概念，中端和后端都有建设，智能化也有建设，天马也是建设服务。

如果我们回到十多年前，我们已经有了像Dreamweaver 这样的低代码产品，但那时网页的复杂性还没有那么高，并且在Web 组件级别上没有抽象。与当时相比，Dreamweaver 是一个标准的低代码产品。

构建天马定义与低代码最大的区别在于，除了限制模块粒度外，还与后端数据分发系统（以下简称分发）建立协作。 ）。最终交付给用户的页面是由构建的页面结构和交付的数据组织决定的。这也意味着施工和交付之间存在非常强的相关性。这种关联性就是天马定义的PMT（page-module-resource）。位）结构。基于这种结构，将UI和数据结合后，后端逻辑可以识别UI结构并提供与当前消费者相关的个性化结果（产品个性化或UI个性化）。屏幕。将来，可以以数字方式创建整个页面，而无需手动创建。天马本质上是为了简化甚至替代手动操作和维护任务而构建的。也就是说，天马构建解决的是业务效率问题，低代码解决的是研发效率问题。

回顾2019年

如前所述，构建本身是一条长链，包括物料系统、DSL、研发、工程、业务管理、后端数据系统、跟踪、监控和性能优化。从服务的角度，我们选择了如何快速搭建业务平台的角度，定义了天马应该提供的能力以及企业本身可以创新的能力。

天马服务的业务构建平台由构建系统应用+批量可构建模块+批量向用户展示的页面组成。

所以我们定义了天马的三个核心部分。

建筑材料基础研发能力

构建稳定的API和渲染服务

高效构建您的交付编辑器

基于该架构，我们重点落实服务层的部署标准和模块规范，以及链路管控，为模块互通和页面体验提供基础保障。

2019年以来，天马逐步向集团内多个BU的建设系统提供服务，大大减少了不必要的重复建设，也实现了一定程度的业务间、BU间模块流转能力。除了提高业务效率之外，天马本身还是一个非常薄的API服务层。如此轻薄的好处是，天马只要业务需要，就可以适应业务系统的抽象模型。构建不一定要在页面维度，也可以在活动维度、应用维度、小程序维度等。未来，天马还可以开发更灵活的功能来适应业务变化。如今正在构建的不同系统的多样性也意味着每个系统都在朝着如何更好地支持自身业务的目标前进。

2020年的变化

研发能力升级

天马的模块开发模型与React源应用程序非常相似，而不是常规的npm组件。

一方面是因为页面维度依赖去重的需求，另一方面是因为即便是Webpack Module Federation对于渲染端来说仍然是一个比较重的解决方案，天马本身就定义了一套依赖关系。因为他们是由SystemJ可以自行支持Webpack依赖，未来也可以不依赖Webpack而在浏览器中运行ESM。

另一方面，由于天马构建系统生成的页面数量较多，且状态切换频繁，不同版本的CDN资源在发布时并没有通过定时回源的方式进行动态组合。因此，该模块最终交付的产品是CDN文件。这意味着每个模块独立构建发布到CDN 的产品。

最初，天马的模块构建器是一个庞大而全面的封装的Webpack流程包，但后来开放了N个配置参数，以支持各种定制构建需求。然而，随着定制需求的增加，构建包中的逻辑越来越多，以及Babel 的版本升级等社区技术解决方案带来的更大变化，远离大规模和全面的想法诞生了。这个想法是只提供基本逻辑和定制部分。 （这是对俗话的回应，如果你的架构复杂，就分层；如果你的定制逻辑太多，就插入。）顺便说一下，几年没有升级的babel 版本已经也得到了升级。

定制模式有很多种。原始构建器处于参数自定义模式。升级构建器本身会限制自定义选项并增加复杂性。最初，我考虑是否需要构建一个顺序运行多个构建器的架构，但事后我意识到多个独立构建器之间的依赖关系并不明确，并且产生了额外的启动成本。总体构建时间应该相当长。

最后，选择Build-script（https://github.com/ice-lab/build-scripts）作为重建构建器的方向。 build-script 执行支持天马和解决多终端的两个主要功能：多任务和插件。同时，webpack 独特的可点击机制让插件可以自由地决定在构建的任何阶段做什么，从而更好地解决问题。原始构建器定制问题。

目前最新的builder的处理流程大致如下。

验证模块文件

对于不同的设备，你会得到不同的Webpack 配置（Applet、Weex、Web 等存在一些差异）。

在多个设备上开始多任务同时构建

依赖的天马组件计算依赖关系，生成种子，并将非天马组件打包成包。

复制剩余的所需文件

重建的构建器转为TS研发，并增加了多项单项测试作为稳定性保证。

我们还对构建器的维护策略进行了一些调整，其中常规构建脚本插件会使用用户本地package.json 中设置的版本进行更新。这类似于开发人员决定版本的方式。在开源社区中，版本最终太大，因此大多数最终都处于低版本状态。但从内部来说这并不是一个健康的状态。由于开发工具属于线下产品，集成升级可以让开发者专注于业务本身，而不是如何升级研发工具，并持续享受构建器升级带来的好处。

当然，随着构建器的统一升级，支持的灰度发布功能也必须保持最新，以避免单个发布异常扰乱所有开发者的正常使用。同时，在提供微分开关的基础上，还将增加灰度试用功能。如果基础库发生重大更改（例如由于设计原因），您将需要创建一个新的构建器来进行迁移和升级。

渲染能力的升级

另外，天马中有一个虫洞，是一个比较老的页面渲染服务，截至2015年，核心《双11 的大规模 Node.js 应用》（https://github.com/tmallfe/tmallfe.github.io/issues/28）被共享。 CDN+源站的架构至今仍在沿用。

Wormhole在最初设计时提供了两个版本：源站点（集中渲染服务）和应用版本（业务独立部署）。

集中服务：采用CDN+源站架构，提供集中渲染能力，业务无需关注页面运维。

与业务无关的部署版本：您构建的产品可以被更多系统和应用程序引用，甚至可以与您的Java应用程序部署在同一台机器上，以便更好地与后端数据集成。

然而，18年前，虫洞应用模型变得难以维护，逐渐被放弃。放弃的主要原因：

源站和应用程序的功能没有太大区别，而且随着异步渲染的盛行，后端数据交互的需求不那么高，所以应用程序的功能可以被源站取代。

当时浏览器端DSL还不稳定，对于商学院的学生来说，天猫的投入产出比足以维持大量的业务线。对于业务来说非常有限。

异步渲染时代

一年前，随着客户端WebView逐渐成为淘宝页面渲染的大部分场景，客户端页面和API数据缓存方案引入了很多限制，而个性化变得更加流行，异步渲染方式现在大部分都被覆盖了。淘宝营销活动页面已更新。 虫洞的作用从简单的渲染升级到为后端数据网关提供额外的页面结构服务。 数据接口从单纯的单层传感数据升级。它可以执行许多页面级别的数据操作，允许您在客户端仅缓存一个HTML 页面并渲染N 个不同的页面（接近纯原生渲染方法）。同时，随着数据网关的集成，API数据缓存已成为默认的优化方法。这是Wormhole+数据网关的终端渲染架构设计。

然而，这种设计背后也存在一些问题。

从工程角度来看，虫洞本身是基于原来简单的CDN源站架构，同时也依赖于数据网关链路。为了避免虫洞需要处理数据接口带来的大量流量，增加了一层缓存应用，模拟CDN的缓存机制，并使用少量的机器。这避免了虫洞添加尽可能多的机器的需要，并且也对虫洞的正常页面渲染行为产生负面影响。

从架构上来说，数据网关到底应该在前端还是后端进行运维，长期以来一直没有明确的答案。数据网关和其背后的交付引擎必须具有相等的流量。数据网关流量也应该如此。虽然交付引擎的数据结构很重要，但数据网关解决了如何分屏、如何在不同设备上加载、智能UI等逻辑等所有前端问题。

此外，即使在这样的异步渲染架构下，由于模块的复杂性、所需数据量的增加以及用户模型和设备的多样化，许多页面的性能持续下降。复杂的。

wormhole 的去中心化版本

我们之前讨论了很多背景知识，这导致了Wormhole 在2020 年将重点关注的两件事。

尝试我们新的同步渲染功能，看看您的页面在几秒钟内打开

利用FaaS的力量快速构建业务数据网关

虽然两者看起来关系并不密切，但背后却存在着一个去中心化虫洞应该重点关注的问题，也是未来虫洞发展的一个方向。我们将其定义为“用户体验的渲染服务”。 Wormhole 3.0的最终产品是npm包格式的SDK。

分散化与原始源站点的集中化相反。当我们刚开始做分布式版本时，所有公司还在使用后端提供的统一数据网关，但由于后端业务领域的限制，我们很快就无法复用该解决方案。同时，如果逻辑不同的公司之间复用网关，数据模型一致性就已经存在重大问题。此外，在大流量情况下，如果隔离和灾难恢复不到位，企业对企业的交互就会成为定时炸弹。

应用化和去中心化的差异

最后

最后，写一句我一直喜欢的一句话。世界上只有一种真正的英雄主义。这是关于即使在认识到生活的真相后仍继续热爱它。

#2024年上述淘宝前端建设服务会有哪些变化？相关内容来源网络仅供参考。相关信息请参见官方公告。