迈出工程开放的第一步，DEF工程微平台体系升级之路

本文作者上坡，来自淘系前端团队，DEF工程平台前端负责人。

DEF 研发平台从 18 年 7 月由原有淘系的发布流程引擎平台 升级建设之后，服役到目前已经是第三个年头了。目前以各种形式服务着淘系及集团大多数前端研发、部署的流程。随着平台的维护和发展，也遇到了一些业务上的困境和挑战。

从体系内部视角来看，在覆盖不同业务场景的同时， DEF 体系也逐渐变成了一个"巨石(monolithic)"应用和产品。导致如今日常应用的产品研发、维护与稳定性保障的成本也逐渐攀升，经常在单一的需求场景中，存在着较高的复杂度和研发成本，成为了平台发展的掣肘因素。

从体系外部视角来看，当下的环境因素更加的艰巨。随着技术形态、业务链路不断变化与发展，如今当前端同学进入到一项业务进行开发的时候，可能要经历两大步骤

• 熟悉业务的上线流程，例如需要通过在搭建体系中进行创建，然后在 DEF 体系中进行应用接入、研发、上线，随后再到业务的系统中做版本的管理与发布。

• 除此之外，可能还需要了解研发项目的框架，而在当下的技术框架、模式的发展趋势下，需要熟悉前端开发、函数开发以及在过程中需要使用到的预览调试、模拟调试、接口测试等各个功能。

由上面举例的情况来看，在愈发复杂的研发链路中，用户对高效的，体验更好的诉求愈发的明显，例如期望在一个平台中完成大部分的操作，而不是在各个平台中进行操作，因为任何一个平台流程出现问题，都会因为各自为战、平台逻辑不一致等典型问题造成较高的协同与答疑成本。

例如 faas 函数这样的研发场景，用户期望能提供在业务研发过程中完善的函数配置、灰度放量、数据监控等符合技术、业务的能力的流畅功能链路，以及提供支撑前后端一体化这样需要与工程、框架配套的完整解决方案能力。

随着基础的工程流程、工程能力的成熟，从团队视角出发，面向 质量 与 效率 提出了进一步的要求，如何在保障生产的过程规范，产物的质量有保证，发布风险较低的同时，也能借助效率衡量模型、效率度量等方式找到效率瓶颈，不断挖掘、提升现有研发效率。从团队视角下对工程体系提出了更高的要求，需要在更多的核心基础命题上发挥作用。

从更宏观的视角来看，我们把当下大的用户角色分为三类，一线研发同学、DEF 平台、研发链路提供平台方，按照上诉存在的问题进行推导，各个角色都相互存在着一些矛盾

• DEF 方: 面向大而全的工程体系，只能支撑较为通用的需求场景，垂直类需求改造成本较高且无法满足最佳实现效果

• 平台方: 以支撑具体的技术选型、业务研发的链路建设方，依赖已有的 DEF 开放能力建设链路的成本较高

• 一线研发同学: 很多情况下只能使用串通的"可用"链路，无法使用完全匹配具体技术形态和业务逻辑的研发链路，体验、效率有限

最近的一年半左右时间，我们发现此类的问题和矛盾不断凸现，促使平台需要思考如何让问题进行止血并通过体系关系层面的方式进行解决，实现在当下阶段的工程体系的变化与发展。

从宏观视角下，我们期望从目前大的前端团队发展、技术发展的背景下，找到既能解决当下的问题，也能为未来前端再一个"三个年头"做好发展准备。

随着基础低代码、工程研发等能力的逐步发展，平台建设成本、门槛的不断降低。另一方面，通过平台进行链路的串联与集成的方式，为搭建出拥有最好的操作体验、研发效率、质量保证的研发链路提供了舞台。

我们可以看到，在这样基础设施环境不断完善的环境下，出现了小二工作台、千机变这样的平台建设与发展趋势，通过建设匹配业务的技术链路平台，实现技术研发以及业务视角下研发、服务链路体验与效率的最大化保障。

顺着平台化建设的思路从 DEF 体系切入来思考，我们可以归纳到，目前 DEF 体系其实也存在几个层面的能力，以参考云计算的分层概念进行拆分

• SAAS: DEF 体系目前最主要的服务的形式，以研发平台为主要产品阵地面向淘系及集团提供前端研发流程服务

• PAAS: 以现有 DEF 开放平台为网关及开放门户的服务能力，主要通过以接口的形式为各个平台与服务提供前端工程服务能力

• IAAS: 主要以自建容器集群为代表的任务调度、流程引擎系统，支撑上层研发平台及云构建、门神、脚手架等服务

在如今通过垂直化平台、定制化建设来追求体验、效率最大化的诉求不断上涨的趋势下，我们判断在当下阶段，如图上的黄色部分需要将 PAAS 层的开放能力进一步得到加强和能力释放。进一步做厚、做宽 PAAS 层，提供足够稳定的、完善的工程能力，使得 SAAS 角色在下一阶段由更多的上层平台体系进行承接。

调整生产关系和服务用户，从服务一线用户，调整为服务平台链路建设方，释放掉定制化、平台搭建的生产力。一起最终为一线用户提供更好的、效率更高的研发链路、平台。

以往 serverless 体系在现有 def 平台搭建的过程中，随着链路的能力逐渐完备，对于深度定制能力的研发成本变得越来越高。随即我们探索性地将 serverless 整个体系以单独平台的方式进行建设，在统一的服务端底座基础上，通过微前端的方式进行组装搭建，保证了平台的平稳建设与增长。实现平台、DEF、用户多方协同使函数研发链路的体验与效率明显提升。

于是工程体系在团队与技术的发展背景下，结合现有的开放能力与垂直平台建设中的优缺点，进行顶层抽象，建设了一套通过支撑平台建设来实现业务研发提效的工程开放技术方案。

通过不断补充的工程基础能力，通过微前端等技术手段、方式，进行垂直平台的建设，同时为上层业务体系平台提供多形态、多程度的配套开放能力，提供丰富的搭建定制能力及高效搭建方案，实现高效搭建符合业务场景的工程研发链路，实现业务研发的最佳体验。

整个体系建立在以 应用、迭代、变更、发布 为核心的前端工程基础概念模型上，我们对整个体系进行多个层次的拆分。

在微平台分而治之的思路下，通过基于 DEF 体系的开放能力，实现各个垂直"烟囱"的快速发展，能较快地实现短期的业务诉求，但是在面向长期发展的视角上，如果不加约束或者相关的措施保障，无疑很快就会陷入混乱的局面，无法保证服务的长期稳定。

应用接入规范

发布流程规范

在这样的背景下，规范层 作为在 DEF 基础能力之上，开放体系中 最底层 也是 最重要 的一层发挥着保障平台长期维护、用户体验一致的角色。通过将前端工程研发流程中的核心环节进行标准化，通过由点连线的方式，形成的基础保障。

例如针对核心的发布流程，基于 流程引擎 系统的建设，以流水线的维度，按照节点规范来进行发布逻辑、发布结果展示的编写，通过流水线编排来实现发布流程的定制。在统一的流程节点规范的保障下，实现发布流程的快速、稳定的搭建。

在约束开放规范的同时，面对上层业务发展过程中还需要的、以及进一步定制支持的工程能力，我们通过在平台能力上逐步增强来解决问题。

租户能力

在基础能力方面，通过补齐需求管理、效能度量、租户隔离与管理等能力，实现对当下前端环境研发链路中进一步需要的能力进行补齐。同时例如通过 多类型组合 的能力，实现针对复杂场景下应用发布渠道的发布能力复用搭配的问题。

在定制层面能力上，以流程引擎搭建为代表，通过将研发流程进行打散、封装、重组的方式，释放定制成本，大幅提升用户针对发布流程的定制能力以及定制效率。

在基于规范的能力建设完成之后，需要将底层能力进一步的封装以及表达，在 BAAS 层中，通过解决原有 def-open 开放平台存在的问题，实现对接口版本、限流控制、降级熔断等能力的基本稳定性保障。基于 POP 的网关技术体系进行工程能力适配，基于调用客户端 SDK 等工具能力实现稳定性、性能与业务诉求的匹配。

基于新的网关能力，将现有 DEF 的基础开放接口进行治理补齐，实现基础能力的进一步规范化。

在研发链路及研发平台搭建的过程中，如果用户直接拿着 API 来进行能力的组装来实现一个应用接入流程，即使是在工程体系对流程熟悉的同学，也需要投入一两天的成本，对于非工程体系的同学，往往难度更大，对于业务逻辑的表达的存在着较高的成本。

在这样的背景下，通过建设组件物料的方式，以 UI 的形式将工程能力进行规范化、标准化的组装，同时提供定制化参数的能力，从效率出发降低工程能力的使用门槛以及平台搭建成本。

• 降低成本: 通过 UI 能力的输出提供，释放掉平台方对于基础统一的工程能力的集成成本，将 UI 与工程的服务接口进行结合，实现工程能力的开箱即用

• 能力定制: 而面向用户更进一步关心的定制能力，提供相关配置参数、回调钩子等能力，完成用户研发链路的快捷定制。

同时在核心的页面中，以组件当做 UI 层的"原料"，进一步实现布局规范，以及布局规范之上的布局容器能力，实现类似 SPI 的扩展机制，进一步通过 UI 的机制来保障基础体验的一致性。

以上的几层相当于工程体系从开放命题出发，提供出来不同层次、解决不同 点、线 层次问题的工具和能力。我们期望在上层进行工具和能力的进一步组合搭配并补齐实践所需要的支撑能力，来形成工程能力的能力 面 。

以开发者门户作为方案的陈列，提供不同层的搭建、定制方案，为平台搭建提供面向不同技术、业务场景的工程定制方式，实现定制、搭建效率相较以往有本质的提升。

目前工程体系的微平台开放体系，一方面针对现有例如 PHA、小程序、tnpm 等基础的工程链路能力及平台的搭建提供支持，同时也面向例如在 商家研发体系 中支持商家资产这样的业务场景及业务平台体系提供能力的输出 商家微应用体系 的研发，在 行业千机变体系 中，支撑行业链路的研发等等。

针对不同的场景，通过开发者体系层提供的不同形态、形式的搭建与定制方案，实现工程能力的高效集成与适配。为业务链路中的一线业务同学，提供最复合场景的研发工作体验。

在快速向前优化、更新的同时，我们也发现了许多的问题，例如进行平台分而治之后，从顶层视角下各个平台之间也出现了一些问题。

随着平台的数量的逐步稳定，各个平台之间的关联却在一定程度上出现了问题，特别是对于不同的研发链路，由各个平台划分成了一个个孤岛。导致用户在不同研发链路之间切换的成本。

一方面会在平台之间通过统一导航、搜索来增加平台间的信息互通区域，另一方面，我们也正在尝试在前文 UI 部分提到的布局容器能力基础之上再进一步抽象，实现 UI 部分和 API 部分的扩展 SPI 能力，通过更强的规范控制能力，消除平台切换的割裂感，让用户在不同平台之间的切换感觉像是在一个站点的形态，提升全局平台的使用体验。

前端工程化的命题核心需要解决的是在团队或者企业范围内，如何在一定的约束和规范下，实现效率与质量的最大化。随着业务场景与技术能力的不断发展以及组织的升级，一方面对于效率质量的要求必定会有更高的提升诉求，同时在问题层面也必定会往更深的领域去探索。

工程体系作为整个生态体系的支撑角色，也尝试在面向快速发展、高度定制场景下提出解法的同时，更进一步地在在提高服务的交付标准与质量，效能度量、代码质量、安全生产等方面专项投入。

在微平台开放体系这个命题下，我们期望能实现 1 小时能接入开放能力、 1 天能完成平台形态的搭建、1 周完成研发链路平台的上线，从而实现场景链路的高效搭建，快速服务。使一线研发同学能快速体会到最佳的研发体验。

关注「Alibaba F2E」微信公众号把握阿里巴巴前端新动向