转载

重新定义研发模式，DataWorks 前端架构演进与 Serverless 实践之路

DataWorks 是一个提供了大数据 OS 能力、并以 all in one box 的方式提供专业高效、安全可靠的一站式大数据智能云研发平台，提供了数据集成、数据开发、数据治理、数据安全、数据服务、应用开发、机器学习完整数据链路的产品。

痛点

复杂的产品功能和技术架构

很多产品都提供了类似于 IDE 形态的富交互单页应用，如下图：

重新定义研发模式，DataWorks 前端架构演进与 Serverless 实践之路

图1. 数据开发 IDE

IDE 形态的产品交互类似于大多数前端工程师使用的 VSCode，包含了众多的功能模块（甚至在 VSCode 的架构中，一切功能模块都是由插件提供），下图是一个数据开发 IDE 所需的最基础功能模块：

重新定义研发模式，DataWorks 前端架构演进与 Serverless 实践之路

图2. IDE 基础功能模块

在基础能力层面，与通用的 IDE 产品存在大量的能力重叠区，这也是一个 IDE 技术产品所需的最通用部分的功能；在此基础之上，从业务角度出发定制了上层业务能力部分，包括各种大数据计算引擎、数据开发节点（类似于 VSCode 中文件类型）、以及“模块”进行数据开发节点的分类和管理、看板负责提供整体数据开发节点流程的统筹视角和流程编排。

横向角度看，DataWorks 拥有众多的功能模块，纵向角度看，DataWorks 上单单节点就达到了额上百数量级。包括功能模块、上百数量级的节点，所有代码都糅合在一个前端工程中，加上基础的 IDE 功能和其它模块代码，前端工程俨然已经演化为一个单体巨石应用，随着需求不断的迭代和升级，现阶段 DataWorks 前端工程的体量相对于第一个版本已经不可同日而语，目前单单一次构建发布过程已经需要消耗 10 min+，可以预见的将来整个发布过程将会多么痛苦。

复杂的运行环境

DataWorks 面临的运行环境放眼整个阿里经济体都是及其罕见的复杂，为了混合云（即专有云）这种私有独立且封闭的环境，前端无法使用 cdn 的能力，如何保证同一套代码能够直接复用到弹内、公有云、混合云三种形态的运行环境，这是一个极大的工程复杂度问题。

重新定义研发模式，DataWorks 前端架构演进与 Serverless 实践之路

图3. 复杂的运行环境

除了工程架构和复杂度，不同的运行环境对于需求迭代和发布提出了更高的管理要求，Gitlab 帮助我们解决了版本之间代码冲突的问题，但是并不能解决产品发布周期上的冲突，当多个需求都需要对外发布上线，尤其在混合云需要按月为周期产出大版本，我们一边需要快速上线新 feature，一边还要按照类似瀑布模型的方式将这些功能打包到专有云版本。弹内、公有云、混合云的发布节奏截然不同，众多 feature 按照不同的节奏要出现在不同的版本迭代中，再考虑阿里集团的熔断机制，更加剧了大家在窗口期集中发布而产生的风险。

千人前面的商业化需求

DataWorks 平台虽然庞大且复杂，但是考虑到公有云和混合云环境客户的不同功能需求，我们需要提供一种足够灵活轻便，便于随时随地的功能拆散/组合以实现轻装上阵，因为挑剔的用户一贯希望能够以最少的代价购买到最合适的解决方案，DataWorks 的竞争力显然也需要从灵活且具备演变能力上寻找未来。

DataWorks 通过权限点的方式给功能模块单元加上开关，虽然这种方式可以解决千人千面的需求，但是也导致了前端工程中存在了大量的权限判断代码，这种方式无论是开发难度、测试成本都有较大的 effect。

简陋的灰度机制

整体而言，DataWorks 在灰度功能验证的时候采用的人为干预形式的灰度机制，即依赖于提前设计好一个功能开关，当我们需要验证一个功能的时候，往往是前端通过人为方式配置一个开关，筛选一部分用户进入到新设计的功能模块，经过一段时间的试跑和调整，逐步把问题解决掉，同时对用户的影响也可以控制在比较小的范围。但显然这不是一个可以反复的、随意的、自然而然的灰度机制。

人为的干预，为灰度而耗费的设计开发，使得一次灰度的成本居高不下，有些时候我们的同学甚至因为想避免麻烦，而忽视做灰度验证。当我们想通过灰度来验证的功能非常的局部，或者用户无关，工作空间无关的时候，或者我们压根不知道哪些用户会使用到某些功能的时候，灰度机制也会在传统架构下失效，即使我们想去设计，也无从下手。

紧缺的人力

DataWorks 团队存在众多的产品，同时需要 Cover 阿里集团内外众多的数据开发需求，而前端团队也就只有 10+ 的规模，显然这个团队规模在应付繁重的需求迭代时是捉襟见肘的，更别说在一些创新领域进行突破了，当然这也是富交互产品研发团队普遍面临的问题。

虽然在引入了 React 这种模块化的 UI 开发方式之后，在代码层面 DataWorks 尽量做到了代码的可重用性，但是限制于交互形态的差异，样式的迥异，业务的区别，以及研发同学自身对于业务理解上的信息不同步，以至于在推进组件化建设之后的一段时间之内都无法沉淀出能够 Cover 基本面的可重用业务组件。

在前后端分离，基于主流前端框架的设计模式下，相较于历史上的前后端一体设计体系下的用户体验是有提升的，然而这都是基于前端开发同学辛勤的劳作，一点点的调整样式和交互换来的成果，这里从来没有捷径可走，而我们只能寄期望于能够复用前端开发同学的研发成果，让每一次设计都不要成为只使用一次的劳动。

其他

上面列举的几点当然不能穷举 DataWorks 研发团队面临的众多问题，而是跟产品需求一样，上面几点已经是筛选之后显得比较痛的点，产品原则上突出要强调做减法，其实这一点在研发领域同样适用，限制于研发团队规模，我们没办法 Cover 所有数据开发同学的需求，那我们也反过来也希望 DataWorks 是一个更加开放的平台，类似于 VSCode 的模式，DataWorks 团队重点关注于打造一个基础功能的数据开发平台，同时制定一系列标准和协议来赋能三方业务进行插件化形式的功能定制。

合作和竞争

DataWorks 研发平台众多功能涵盖了数据开发工程师的日常工作，用户在我们的平台上长年累月的伏案工作，对一些功能点的设计有自己的切身体感，而这些体感是我们平台的研发同学所感受不到的。PD 和 UED 去收集需求、去使用、去亲自感受，然而毕竟不是专职于数据开发本身，因此很难体会到数据开发工程师长期使用后的那种细微的挫败感。再到细分的垂直业务市场，不同行业下如何使用我们平台，差异更是有天壤之别。面向金融，银行，政府，大型国企，互联网公司，传统企业，民营，教育，等等，他们的用法都是完全不同的，有的行业甚至就不知道拿到 DataWorks 平台后该做什么。用户的需求千差万别，用户的心智也处于不同阶段。

因此，在我们无暇一一顾及的领域，前方的交付团队或者公司，使用 DataWorks 平台应用到具体的行业中，然后再将行业的专属需求带回给我们的 PD 进行分析。我们平台本身也会开放一些 Api 给予前方团队包装成产品提供给特定领域的客户，帮助客户解决实际问题。

新的产品规划还在不断制订之中，引擎团队设计好自己的产品也需要在 DataWorks 平台上降低用户的上手难度，如果永远只是 DataWorks 平台的开发同学按照排期逐步完成这些接入和订制需求，平台注定难以持续发展壮大。因此，从前后端架构层面，从无数的合作和竞争场景出发，都迫切需要我们进行一次针对自身的技术革命，彻底从现有前后端研发模式中解放生产劳动力，引入更多的用户侧的研发力量，帮助平台向更健全的方向发展。

架构的演进

循证软件架构（Evidence-Based Software Architecture）是《Expert One-on-One J2EE Development without EJB》一书中推崇的架构思路，用通俗的话说就是摸着石头过河，找最适合自己的架构。该理论提醒我们，在产品形态不断演进的过程中，技术架构也需要根据当前产品形态进行相应的进化。

DataWorks 前期刀耕火种的时代，在 DataStudio（数据开发工作台）中基本提炼出了一套 Studio 产品的前端架构，按照分层的方式梳理出了一个 IDE 技术产品的技术架构，基础层封装了 IDE 布局能力、通信能力、国际化能力、换肤能力、数据中心、无痕埋点、事件中心、消息中心等基础模块，上层实现了模块管理、节点管理。

随着需求的不断演进，DataStudio 上的节点急剧增长，各种类型节点在功能和交互上存在较大的重叠，所以在刀耕火种时代之后，DataWorks 前端团队针对节点进行了一次重大重构，通过产品需求中提炼出一个基础节点类，基本包含了一个节点常用的功能和交互，同时基于该基类衍生出了一大堆节点实例。

该套架构已经在 DataStudio 稳定运行了好几年，DataStudio 底层依赖于 MaxCompute（原 ODPS）引擎，针对离线场景，MaxCompute 提供了强大的运算能力，但是对于实时性要求比较高的场景，MaxCompute 无法提供相应的能力，所以在不同的垂直领域 DataWorks 从 DataStudio 衍生出了各种计算引擎对应的 Studio，包括：StreamStudio（基于流计算引擎）、HoloStudio（基于交互式分析引擎）、GraphStudio（基于图计算引擎）。

每一种不同的计算引擎都对应了一个全新的 Studio，业务在快速扩张的压力之下，每一个 Studio 还是以拷贝代码的方式集成 DataStudio 中提炼的 Studio 底座能力，同时基于基础的节点类衍生各自 Studio 中对应的数据开发节点，这种形态大概存在了一年多的时间，随着各个垂直领域 Studio 的单飞式发展，各个 Studio 底座也是走向了无法再复合的状态。

最近 DataWorks 团队已经完成了统一 Studio 底座的抽取，将这块相对底层且变动相对不频繁的功能统一进行收敛和升级维护，同时，我们也在和阿里经济体 IDE 共建小组（kaitian）共同推进 IDE 底座能力的融合，做到通用能力复用、业务特性通过统一上层插件协议来实现个性定制。

同时，为了解决前端人力瓶颈，我们希望将 DataWorks 平台做到更加开放，可以为 DataWorks 引入用户侧的研发能力，当然这也是基于用户侧各种个性化的需求而不得不考虑的架构升级。DataWorks 在去年开始进行 Studio 插件化架构升级，基于前面抽取的 Studio 基础底座，在上层通过插件化方式开放了 DataStudio 的常用扩展能力。目前已经通过该方式对接了一个新引擎（Analysis DataBase）的完全自主接入，通过这种方式极大简化了新引擎搭建数据开发 Studio 的流程和开发工作量，同时也解放了前端团队的人力（原先新接入一个引擎，需要前端团队针对新引擎进行定制开发）。

阿里经济体每个 BU 在达到一定的体量之后，慢慢都会衍生出大数据开发的需求，有一些 BU 可能会成立自己的数据小组来支撑 BU 对于大数据的需求，更甚的可能会自己搭建一个大数据平台。其实，在跟一些 BU 同事沟通过程中发现大部分的业务 BU 对于大数据平台的需求往往是因为 DataWorks 在局部一些点上无法满足特度的业务述求，而这一小部分的差异由于并不通用，DataWorks 作为一个大一统的开发平台无法承载业务特性的细节差异。

针对这个场景，DataWorks 基于之前的 Studio 底座统一 + 插件化技术架构基础上打造了 DataWorks 的开放平台，另外我们也将 DataWorks 中已有的能力提供给业务部门进行功能拼装 + 组合，从而赋能集团各业务团队进行数据开发平台的快速搭建。

总结下来，DataWorks 经历了(1)刀耕火种的单体应用时代、(2)组件化、(3)微前端 & 插件化三个时期的前端架构演进。

单体应用时代

各个 Studio 在快速迭代往前走的过程中，前后端不断的累积功能和代码模块，后端还是按照 SpringBoot 的方式堆积功能模块，前端虽然积累了一些业务组件库，但是基本也是在堆积业务模块代码，整体前后端都在按照单体应用（巨石应用）的方式进行业务迭代。

单体应用（巨石应用）有几个好处：

易测试
易部署

在前期快速的产品迭代过程中，单体应用的开发模式确实帮助业务快速的形成了完整的产品闭环和完善的产品链路。但是单体应用却也有他的适用范围：在应用不那么复杂的时候，当应用越来越复杂，尤其是各个 DataWorks 产品都在往在线 IDE 形式发展过程中，我们遇到了单体应用越来越吃力的情况：

部署繁重：单次的小修改，需要整个应用重新部署
开发效率：应用代码越来越多，编译时间长影响开发效率
回归测试难：应用功能越来越复杂，无法有效的分隔功能模块，导致产品回归测试周期长
另外，单体应用也不太容易实现整体技术架构升级

组件化

经历了一段时间的单体应用开发模式之后，随着业务复杂度越来越高，单体应用的体积也越来越大，不管是开发阶段的实时构建还是发布阶段的编译构建，每次一个微小的改动，前后端都需要经历繁重的部署过程；而单体应用也在不断的业务迭代过程中显得越来越吃力。

后端尝试基于 SOA 架构方式引入了 Spring Boot Starter 来进行业务模块划分，前端也在横向层面抽象和积累了一部分 IDE 形态的交互组件，比如：Terminal & 文件树 & TabPanel & LSP Editor。

SOA 架构类似于一种服务端的组件化架构思想，把一些常用的公用模块进行抽象，将一个庞大的系统按照功能模块划分为一个一个独立的业务模块单元（组件），一般来说，每个组件会从始至终执行一块完整的业务逻辑，通常包括完成整体大 action 所需的各种具体任务与功能。

前端组件化类似于 SOA 架构，把一格庞大的页面交互按照功能模块划分为一个一个独立的 npm 包（组件），一般来说，每个组件从始至终也是执行一块完整的业务逻辑和页面交互，组件之间通常是松耦合的。

SOA 和组件化架构的确部分解决了单体应用（巨石应用）的痛点，至少把一些可复用的功能模块进行了抽象，减少了部分功能的重复劳动，但同时也带来了一些问题：

依赖关系复杂：相对于单体应用，代码的依赖关系趋向复杂
问题排查问题难度高：三方组件的问题排查变得困难
一旦出现问题，所有依赖的应用都需要进行重新发布

微前端/插件化

相关概念解释

鉴于有些同学对于 Serverless、微服务等概念还存在一定的认知误解，开头我们先来看下相关的概念：

Serverless

Serverless（无服务器架构）是指服务端逻辑由开发者实现，运行在无状态的计算容器中，由事件触发，完全被第三方管理，其业务层面的状态则存储在数据库或其他介质中。

Serverless 是云原生技术发展的高级阶段，可以使开发者更聚焦在业务逻辑，而减少对基础设施的关注。

许多年前，我们开发的软件还是 C/S（客户端/服务器）和 MVC（模型-试图-控制器）的形式，再后来有了 SOA（面向服务的架构），最近几年又出现了微服务架构，更新一点的有 Cloud Native（云原生）应用，企业应用从单体架构，到服务化，再到更细粒度的微服务化，应用开发之初就是为了应对互联网的特有的高并发、不间断的特性，需要很高的性能和可扩展性，人们对软件开发的追求孜孜不倦，希望力求在软件开发的复杂度和效率之间达到一个平衡。

云改变了我们对操作系统的认知，原来一个系统的计算资源、存储和网络是可以分离配置的，而且还可以弹性扩展，但是长久以来，我们在开发应用时始终没有摆脱的服务器的束缚（或者说认知），应用必须运行在不论是实体还是虚拟的服务器上，必须经过部署、配置、初始化才可以运行，还需要对服务器和应用进行监控和管理，还需要保证数据的安全性，这些云能够帮我们简化吗？让我们只要关注自己代码的逻辑就好了，其它的东西让云帮我实现就好了。

云计算经历了 IaaS（Infrastructure as a Service）、PaaS（Platform as a Service），到现在 Serverless 的兴起，其实是在经历了一个让用户越来越聚焦于真正的业务逻辑，而非操作系统、软件等非业务逻辑相关的基础设施；在云原生技术发展的较高阶段，整体的目标是让用户只需要关心业务代码逻辑，把其他的部分交给云，而当前 Serverless 所包含的两个领域：BaaS（Backend as a Service）、FaaS（Function as a Service），基本也是两种形式的实现了 Serverless 的初衷。

Baas

BaaS（Backend as a Service）后端即服务，一般是一个个的 API 调用后端或别人已经实现好的程序逻辑，比如身份验证服务 Auth0，这些 BaaS 通常会用来管理数据，还有很多公有云上提供的我们常用的开源软件的商用服务，比如亚马逊的 RDS 可以替代我们自己部署的 MySQL，还有各种其它数据库和存储服务。

FaaS

FaaS（Functions as a Service）函数即服务，FaaS 是无服务器计算的一种形式，当前使用最广泛的是 AWS 的 Lambada。

现在当大家讨论 Serverless 的时候首先想到的就是 FaaS，有点甚嚣尘上了。FaaS 本质上是一种事件驱动的由消息触发的服务，FaaS 供应商一般会集成各种同步和异步的事件源，通过订阅这些事件源，可以突发或者定期的触发函数运行。

微服务

微服务代表了一种新型的应用构建架构方案，有别于更为传统的单体式方案，微服务架构可将应用拆分成多个核心功能，每个功能都被称为一项服务，可以单独构建和部署，这意味着各项服务在工作（和出现故障）时不会相互影响。

相对于 Serverless，微服务其实是服务（API）领域范畴的一种 Serverless 架构形式，而 Serverless 除了服务（API）领域之外，还涉及存储（比如：OSS）、数据库（Amazon Aurora Serverless）等。

Baas 和 FaaS 其实是微服务架构的两种实现形式，FaaS 相对于 BaaS 来说是一种更细粒度的服务单元，两者并没有孰优孰劣之分，看具体的业务场景更适合哪种形式。

微服务是一种架构设计模式。在微服务架构中，业务逻辑被拆分成一系列小而松散耦合的分布式组件，共同构成了较大的应用。每个组件都被称为微服务，而每个微服务都在整体架构中执行着单独的任务，或负责单独的功能。每个微服务可能会被一个或多个其他微服务调用，以执行较大应用需要完成的具体任务；系统还为任务执行——比如搜索或显示图片任务，或者其他可能需要多次执行的任务提供了统一的解决处理方式，并限制应用内不同地方生成或维护相同功能的多个版本。微服务架构具有如下特点：

负责单个功能
单独部署
包含一个或多个进程
拥有自己的数据存储
一支小团队就能维护几个微服务
可替换的

相比于 SOA 架构，区别如下：

重新定义研发模式，DataWorks 前端架构演进与 Serverless 实践之路

DataWorks 团队在去年引入了微服务架构，将一些相对比较独立的业务逻辑进行微服务化升级，相应的前端也引入了微前端 & 插件化架构实现个性化业务的开发和定制。

微前端

微前端是一种类似于微服务的架构，它将微服务的理念应用于浏览器端，即将 Web 应用由单一的单体应用转变为 多个小型前端应用聚合为一的应用 。各个前端应用还可以 独立运行 、 独立开发 、 独立部署 。

后台微服务的一个很大的卖点在于，可以使用不同的技术栈来开发后台应用。在大型组织机构里，采用微服务的原因主要在于，使用微服务架构来解耦服务间依赖。

而在前端微服务化上，则是恰恰与之相反的，人们更想要的结果是聚合，尤其是那些 To B（to Bussiness）的应用。

针对 DataWorks 团队的业务现状，针对不同的计算引擎，DataWorks 开发了众多的垂直领域的 Studio，每一个 Studio 虽然在产品交互、功能逻辑上存在大量的重叠，但是呈现给用户的是众多的产品，实时计算引擎的走 SteamStudio，离线计算引擎走 DataStudio，当然还有一些用于开发 FaaS 的 Studio 平台。然而在用户看来，所有的产品都是来自于同一家公司，他们就应该只有一个产品，同时由于产品功能的分散，导致一些公共基础功能也是散点式的分布在各种产品中，对于用户的使用成本也是一个极大的挑战。

产品方向也在往内聚的形式转变，18 年底开始的 XStudio 项目就是希望能够在一个 Studio 中集成所有计算引擎的开发节点来给用户提供一体式的产品体验。

聚合成为一种趋势，相应的在前端架构层面我们也借鉴了微前端架构来进行架构升级，以实现不同 Studio 中开发的功能能够聚合到一个应用中呈现给用户。

在 DataWorks 产品体系中，每一个模块、节点其实是一个可以独立开发、独立运行、独立部署的单体应用，不同于常见的微前端通过路由来分发微前端应用，DataWorks 的每一个节点、模块都是通过 Tab 切换式的分发机制：

重新定义研发模式，DataWorks 前端架构演进与 Serverless 实践之路

当然，我们也有路由级别的微前端架构产品，比如：运维中心，通过点击左侧导航条进行路由级别的微应用分发和切换

重新定义研发模式，DataWorks 前端架构演进与 Serverless 实践之路

插件化

插件的英文是 plugin ，拆分开是 plug(插头) + in ，现实生活生活中，电源插线板就是这样"plugin"应用的例子。插线板和通过插头插入其中的电器构成一个物理世界的插件化系统。插线板通过插孔为“插件”提供电源，而给系统赋予了插件的能力。插入电视的插头，就拥有看电视的功能，插入冰箱的插头就具有冷藏食物的功能，插入台灯的插头，就具备照明的功能，等等。

重新定义研发模式，DataWorks 前端架构演进与 Serverless 实践之路

一个良好设计的插件化系统和插线板的设计也是一样一样的。系统的核心应该是一个可热插拔的“插线板”，负责给系统接入的插件提供电源（插件API），系统的能力是所有插件能力的聚合。和物理世界的插线板不同是，软件插线板的插头没有数量的限制，也就是说系统可以接入任意数量的插件，意味着它的功能可以无限增加。

微前端架构解决了产品之间聚合的问题，但是针对 Studio 这种富交互产品来说，微前端的方式还无法解决细粒度的功能组合问题，比如下图所示在一个节点单体应用的头部操作按钮区域，不同节点具有不同的操作按钮，针对这种场景我们通过了插件化形式将按钮 UI 及其背后的交互和业务逻辑拆分成一个个的插件，然后配合微服务 & 插件管控台实现配置化的形式组合功能和模块。

重新定义研发模式，DataWorks 前端架构演进与 Serverless 实践之路

其实无论是微前端还是插件化都是解决产品功能的聚合问题，只是这两个架构在 DataWorks 产品中解决不同领域的聚合问题。微前端架构解决了大区块粒度的功能聚合，插件化则解决了细粒度级别的功能聚合、组合。

当然，在这种富交互的 Studio 产品形态中，微应用/插件之间的通信和交互是一个非常常见的场景，这块我们通过下述一个统一的 Studio 底座层面进行统一的规范化和标准化。

Studio 统一底座

Studio 统一底座提炼了一个 IDE 产品形态基础的能力，同时在上层封装了一些 Studio 业务层面的能力，配合后文涉及的 Studio 插件化的方式，实现了所有 Studio 上层业务都是通过插件化的形式植入到 Studio 底座之上，同时配合后面涉及的“微服务 & 插件化管控台”，我们实现了通过配置形式定制 Studio 产品功能，甚至可以支持快速搭建出来一个全新的 Studio。

统一的 Studio 底座除了可以进行统一的维护和升级之外，也将 Studio 底座复杂的工程结构从应用工程中剥离出来，减少了 Studio 应用工程的复杂度；同时，这也是一种统一的标准，底座规范了上层插件 & 模块基础的交互以及通信，这也为后续 Studio 统一插件化对于不同 Studio 之间实现插件互通提供了保障。

重新定义研发模式，DataWorks 前端架构演进与 Serverless 实践之路

Studio 统一插件化

DataWorks 微前端 & 插件化架构底层使用了 qiankun（qiankun 底层依赖于 single-spa），针对 qiankun 无法满足 Studio 场景的需求，DataWorks 团队基于 qiankun & single-spa 进行了大刀阔斧的改进和升级：

PS：DataWorks 基于微前端架构 & 插件化架构开发的微应用/插件，两者的存在形态都是一个可以单独开发、单独部署、单独运行的前端模块，这里统一将称为插件（当然，也有一些插件的运行是依赖于 Studio 底座，这种类型的插件有点不符合微前端的特性）。

1. 多实例模式

DataWorks 需要一个综合的插件化架构方案，它同时需要路由级别插件（比如：运维中心）、插槽机制插件（比如：数据开发）、页面级别插件（比如：数据地图），整体方案底层基于 single-spa & qiankun，同时解决了 qiankun 无法实现同一个插件在同一个页面多次渲染的问题。

2. 插槽机制

一个插件只关心它本身的交互形态和业务逻辑，至于该插件被那个业务系统引用完全是由应用决定，所以在设计过程中我们加入了插槽机制来保证一个应用可以通过开发一个插槽插件来承载子插件，同时插槽插件可以决定其自插件的渲染逻辑，由一系列的插槽插件和子插件构建成了一个完整的页面。

qiankun 也有样式隔离方案，但是 qiankun 是在插件挂载的时候进行样式清除，在同时只能渲染一个插件的情况下该方案完美解决了样式冲突问题，然而对于 Studio 类型的插件化方案来说，需要解决同时渲染多个插件而导致插件之间样式打架的问题。

3. 样式隔离 & 版本隔离

qiankun 也有样式隔离方案，但是 qiankun 的使用场景是单一时间内只渲染一个插件，插件挂载的时候进行样式清除，对于 Studio 类型的插件化方案来说，需要解决同时渲染多个插件而导致插件之间样式打架的问题；另外，两个插件引用了同库不同版本的场景，两个版本库对于全局样式定义上的冲突也是需要解决的一个问题。

同样的，样式方面冲突问题同样存在于 JS 相同库、不同版本的场景，针对一些依赖于全局（window）对象的 JS 库，我们也需要解决冲突的问题。

PS：感谢阿里云管控台团队 Widget 微前端方案的思路，样式隔离和版本隔离的解决方案借鉴于 Widget 方案。

4. 插件嵌套

对于 Studio 插件化来说，一个插件的粒度可以是一整个区块，也可以是一个小粒度的小按钮，同时插件之间可以是一种树状的数据结构，比如下图展示的整体是一个插件，同时该插件中头部工具条区域每一个按钮都是一个子插件：

重新定义研发模式，DataWorks 前端架构演进与 Serverless 实践之路

DataWorks 统一插件化支持了这种嵌套结构的插件渲染，同时配合“微服务 & 插件化管控台”通过配置化的方式实现插件依赖编排，甚至配合微服务管控台上的插件编排能力，一个应用完全可以通过配置化方式编排出一个完整的应用页面。

同时，微服务管控台提供了更为傻瓜化的可视化编排能力，可以通过可视化交互形式构建出一个应用的插件依赖关系，从而在 Runtime 运行时解析、渲染为一个完整的页面。

重新定义研发模式，DataWorks 前端架构演进与 Serverless 实践之路

微服务 & 插件化管控台

前后端一体基于 DataWorks 业务的插件化，也是我们坚持要自研设计开发 DataWorks 微服务平台（DMSP：DataWorks MicroService Platform）的重要原因。DMSP 打通了前端组件的发布和后端微服务的绑定关联，通过 Swagger 这样的技术手段成功使得前后端在部署后可以迅速成为一个业务插件。让团队的前后端都可以在 DMSP 里面实现 DevOps，以持续交付的方式源源不断的将新功能发布给客户。

尤其值得说明的是，DMSP 同样是针对三大环境的，即弹内、公有云和混合云，插件开发完成后，我们要通过 DMSP 持续交付到公有云多达 20 个 region 的环境中，还要能够实现微服务在专有云的统一打包部署。并且，DMSP 还要让开发插件的同学尽量对复杂的外界部署环境无感。

未来我们期望整个 DataWorks 平台的大部分页面内容都基于微前端 & 插件化设计，从而解决前文痛点里面提到的问题：“灵活轻便，便于随时随地的拆散组合轻装上阵”。架构驱动的不仅仅是开发模式，而且势必还将影响到整个产品的蓝海。

构建生态

在后端微服务配合微前端 & 插件化架构下，前文提到的垂直业务的定制开发也将成为一种可能性，面向行业的交付团队可以利用 DataWorks 平台提供的微前端 & 插件化能力，为客户订制完全适配行业特征的智能研发平台。进而在 DataWorks 研发平台上营造一个有活力的创新生态圈，为客户提供更加丰富多彩的选择。架构将驱动整个生态圈的优胜劣汰，从而不断向更有竞争力的方向进化。

我们 DataWorks 研发团队也寄期望于在这套架构之上，实现弹内弹外的共赢模式的合作，推动云智能事业群下的产品形成合力。

重新定义研发

微服务 & 微前端架构由于语言无关性，还抹平了一些技术上的鸿沟，后端同学不会使用 React，可以使用纯 JS 进行插件开发；前端同学熟悉 NodeJS，也可以在微服务的设计中一展身手。在该开发形态下，前后端同学都扩展了自身的技术领域，不但对于业务来说是一种更加高效的开发模式，同时也使前后端在技术上的交互和沟通更加有默契。

同时，DataWorks 还存在一款特殊的产品：AppStudio，专职于进行 WebIDE 的研发工作。不管是后端微服务还是前端微前端，都实现了产品功能的细粒度切分，WebIDE 正适合这种小体量工程的开发，不管是后端的微服务、还是前端插件、还是 FaaS 里的函数，都可以进行在线开发。同时，AppStudio 后续将会更好的与微服务 & 插件化管控台进行流程打通，减轻研发流程，让开发同学专注于业务逻辑的开发，加速产品迭代速度。

另外，在机器学习以及智能化的潮流下，我们针对前端 Coding 领域打造了一款智能化编程产品：Sophon 代码智能化提示插件，我们希望在这款 IDE 插件的辅助下，前端开发能够真正做到“键”步如飞。

展望未来

微服务和微前端 & 插件化的架构已经在 DataWorks Studio 这种富交互产品场景中经过一段时间的验证，后续我们除了在业务中不断去实践这套技术架构之外，也希望能够通过该套技术方案来以开放的姿态迎接更多的业务方来进行 DataWorks 大数据开发功能定制，我们也会通过微服务方式来不断开放 DataWorks 的一些核心能力。

比如：最近我们通过该架构承接了 ADB（AnalysisDB）引擎接入到 DataWorks 体系，后端通过微服务来访问 DataWorks 核心 API 以及自身业务逻辑，前端通过微前端 & 插件化方案定制 ADB 引擎从数据采集、数据开发节点定制、数据地图展示等各个环节产品的功能定制。

欢迎感兴趣同学加我微信沟通交流： harbin1053020115 。