支撑阿里 99% 数据开发的 DataWorks 在技术架构变革方面的实践

DataWorks 是阿里巴巴自主研发，支撑阿里巴巴经济体 99% 数据业务建设和治理，每天数万名数据开发和算法开发工程师在使用。

从 2010 年起步到目前的版本，经历了多次技术变革和架构升级，也遗留了大量的历史包袱。技术的创新和业务的发展，相辅相成但也互为掣肘。存在需求接入慢，代码牵一发而动全身，环境复杂等问题，沉疴已久。历次迭代均未从根基上升级 DataWorks ，仅仅是一些性能提升、工程结构的优化，减少了重复代码等，并未促成根本性的技术革命。

痛点

让我们先来谈谈 DataWorks 当前遇到了哪些痛点，这些痛点是倒逼着我们进行技术变革的源动力。

沉重的历史包袱

首先要提的就是历史原因遗留的各种问题， DataWorks 历史上多个版本同步开发，前后端技术栈多次变革，应用一旦上线就很难废弃，一个对外暴露的 API ，很可能是 5 年前开发的，但依然有业务在依赖，通常情况下连这些古老业务的负责人都找不到了。当我们的服务正常运行的时候，无人搭理，一旦下线，则可能不知道从哪儿跳出几个用户前来投诉。页面上的功能同样如此，有时候只是过去不知道哪位同学开发中引入的一个Bug ，但也因为我们的用户基数庞大，而变成了真理。历史上曾经出现过的隐藏的很深且用户寥寥的功能点都有自己的忠实拥趸，一旦被我们的开发不小心忽视而做丢了，就会迎来投诉和工单，所以 DataWorks 平台不愧是千锤百炼磨练出来的大数据开发平台的标杆，朴素的界面之下隐藏了无数细致入微的功能点。如果想重造这么一个被阿里巴巴经济体无数数据开发工程师验证（折磨）过的数据开发平台，都要好好考虑一下这十年来我们的平台到底经历过了什么。

复杂的软硬件环境

DataWorks 面临的运行环境放眼整个阿里巴巴经济体都是及其罕见的复杂，为了混合云（即专有云）这种私有独立且封闭的环境，三合一版本之后我们必须放弃依赖弹内成熟的中间件体系，只能寻找那些同样在三个环境下都存在的技术来支撑。也因此，很多在某个环境下缺失的依赖，如果我们无法用开关的方式搞定，或者我们判断其复杂度不高，就会通过自研或者去依赖一些开源的体系来解决问题。而公有云上各种 络环境的问题几乎都要靠人肉去排查，从每天居高不下的答疑量上就能看到我们受环境问题的影响是多么耗费人力。除此以外，前不久中美贸易战带来的影响也传递给了 DataWorks 平台，运行环境需要匹配国产芯片，我们的进程不但要运行在 X86 指令集上，同样也要能运行在基于 ARM 指令集的国产芯片上。同时为了满足部分中小企业用户的购买欲求，敏捷化也是我们需要去裁剪设计的。

架构的变革

任何一种技术的变革都是循序渐进的，这和 Spring 之父 Rod Johnson 秉持的理念是一致的。他提出了“轮子理论”，也即“不要重复发明轮子”，这是西方国家的一句谚语，原话是：Don’t Reinvent the Wheel 。除此之外，通过长期的实践后他在著作中总结阐明了循证架构的思想，即“没有最好的架构，只有最合适的架构”。这是架构界进化理论的雏形，意味着我们的架构要不断的演进去配合多变的业务需求。

传统的 SOA 下，服务趋向于稳定和集中，单体服务之间是平等的，或者至少在共通的结构上是类似的，服务与服务之间通过 络通信进行依赖。SOA 下每个单体服务可能是多个开发者围绕着进行合作开发，因此替换任何一个单体服务都是一件伤筋动骨的事情，当有大的技术栈的变革，例如从 WebX 3.0 升级到 SpringMVC ，从 SpringMVC 升级到 SpringBoot ，人力成本消耗都是巨大的，升级周期动辄以年为单位，更不用说假设我们想用 Go 语言或者 Python 的 Django 框架来替换 J2EE 体系下已经设计好的 web 服务，这几乎是不可能完成的任务。也意味着当我们进入了这个技术体系，就很难再从这套体系中脱身，更无从谈起架构的演变和进化。

在传统 SOA 下，提升工程效率的手段是极致的代码复用，凡是可复用的代码，都抽取到二方包中设计成类库让不同的单体服务依赖调用。虽然配置越来越复杂了，但的确减少了“重复发明轮子”的事情。

还有一个办法，是如我在 2015 年时候尝试新的架构设计时候采取的方法，即：能抽象成二方包的抽象，不能抽象的通过自动化代码生成工具自动生成。一套演练成熟的 SOA 架构工程，从目录结构到配置组装都几乎是稳定不变的，即使有变化，也都是按照 MVC 三层架构进行微调，因此我们可以把一些无法抽象的，或者包含了复杂逻辑，需要灵活调整的代码通过自动化代码生成工具来生成，并且尽可能冗余代码的功能，让开发者从生成的工程代码中尽量做减法或者根据业务逻辑只修改最少量的代码，从而提升了工程的整洁度和开发效率。

除了代码的复用，还有服务的复用，我们设计了一些中心化的单体服务，用于将复杂逻辑或启动较慢或需要缓存，等等这样一些功能封装在这些核心服务中，进一步减少围绕中心服务的其他应用的体量和复杂度，当然这也可能会引入单点可靠性的问题，但要确保核心服务的稳定可靠，在一定规模的服务体量下并非难事。

即便如此， SOA 在效率上的提升依然是有限的，初期工程建立的快速高效并不代表长期业务开发后还能维持这样的效率持续发展。前文描述的痛点逐步展现且缺乏行之有效的解决办法，开发者由于整齐划一的使用同一套技术栈甚至同一套工程目录树结构，虽然在协同的时候更加默契，但也消灭了前沿技术在团队内的赛马机制。研发同学在一套逐渐古老落后的框架下研究怎么压榨出最后的效率和性能，但往往忽视了也许换个框架换个技术栈甚至换个语言，就会带来质变。因此，当基于谷歌的 K8s体系成长的生态圈逐步成熟之后，遵循“没有最好的架构，只有最合适的架构”的思想，我们开始思考如何将 DataWorks 的技术方向转向灵活多变的微服务架构。

微服务架构

提到微服务，理所当然要和云原生关联，所谓云原生（Cloud Native），包含了如下三点：

1、DevOps

开发和运维不再是分开的两个团队，而是你中有我，我中有你的一个团队。

2、持续交付

持续交付的意思就是在不影响用户使用服务的前提下频繁把新功能发布给用户使用。

3、容器化

容器化的好处在于运维的时候不需要再关心每个服务所使用的技术栈，每个服务都被无差别地封装在容器里，可以被无差别地管理和维护。

对于 DataWorks 研发平台下众多产品应用来说，微服务架构方向的改造也许不是能破解所有问题的万能钥匙，但一定是当前开发模式所遭受的病痛的解药。

认清自身

DataWorks 研发平台属于典型的 PaaS 应用，当然也有数据服务这样的产品做到了 SaaS 层。传统 SOA 遇到的痛点，以及将来我们要对客户开放的定制化能力，需要借助微服务架构来应对，逐步将研发重心从 PaaS 移向 SaaS 。

当我们采用基于 K8s 容器化的微服务架构之后，开发者可以在我们自主研发的微服务平台中集成 DataWorks 平台开放出来的基础 OpenAPI ，也可以集成外部应用的 API ，在微服务中进行数据整合和业务逻辑的编写，最终暴露出一系列在平台前端可访问的 API ，供前端功能模块使用。在这个过程中，我们可以顺便化解前文提到的一些痛点。

机器人工厂应用微服务

DataWorks 团队设计的微服务平台，充分拥抱了现在大热的 Service Mesh ，即服务 格，通过Mesh将一部分工作封装在前置的微服务里，这些系统级微服务与开发者设计的微服务运行在同一个 pod 里，使得开发者设计的微服务更加简单，Mesh更像是 Spring 框架下的 HandlerInterceptor 或者 Filter ，面向 AOP 编程的开发者擅长在工程里开发拦截器和过滤器，到了集成了 Service Mesh 的微服务框架下，可以方便的使用系统级微服务替代一部分传统拦截器的工作。比如登陆跳转、权限控制、服务发现，比如限流、监控、日志聚合等等。

前端同学在基于 XStudio 插件化设计的页面上，留好插槽，插槽里面可以是一个按钮，也可以是其他任意类型的组件，这个组件后面绑定一个微服务，我们可以将插槽里面的内容连同后端的微服务一并替换，实现页面功能的快速组装，从而实现一次开发的多处使用。同时，插槽里的内容也可以由业务开发团队来提供，那么业务开发团队也只需要自行设计前后端一体的这样一个插件来放置到前端插槽里，实现个性化需求的订制开发。

在传统的插件化设计里，开发者们要么提供一个遵循某种接口协议的二方包、要么提供一系列遵循某种协议的 API 再由 SOA 架构向前端输出。这带来的问题要么是对 SOA 服务有侵入，要么影响了SOA服务整体的安全性和稳定性问题，要么受限于编程语言、要么毫无灵活性，而微服务&插件化完美的解决了这类问题。

同时，前端体系中还有重要的一环是受访的数据监控和 警，我们设计了各种维度的 表和指标监控，无论是自己的业务还是外部业务团队写进来的组件，不用多写一行代码，都可以通过“自动化全量埋点技术”，观察和了解组件的使用情况。

Terminal插件的架构设计图

此外，基于微服务架构，我们还可以构建SaaS的一些实现，例如 FaaS、BaaS（Backend as a Service），以及 BFF（Backend For Frontend）。以 BFF 为例，移动端的 DataWorks 应用 BFF 后，可以减少移动端 H5 页面的 络消耗，将后端多个微服务提供的接口通过 Gateway 组装后提供给移动端，实现微服务的聚合。如果通过 BFF 做了 SSR（Server Side Render：页面同构，相当于在服务器端直接渲染成 html 输出到浏览器），则可以进一步降低移动端的渲染性能消耗。

DataWorks 微服务平台

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

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

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

构造生态

构造生态的重要前提是要有竞争，要有优胜劣汰，构造生态的同时就是在构造可以演变，可以适用进化论的技术体系。作为“循证架构”的升华，微服务架构显然在进化方面更胜一筹，循证架构是一种自上而下用进废退的技术演进路线，而微服务架构则是一种自下而上优胜劣汰的技术演进路线。容器化实现了语言无关，框架无关，每个微服务都被无差别地封装在容器里，从而可以针对一个功能开发出多种微服务，类似算法桶的优选机制，从这些完成同一个功能的微服务中挑选出最优解。在理想情况下，无需上层架构师的主动干预，应用就可以在一段时间的进化后自组装成最佳的实践。当然这只是理论上的情形，我们身处的现实世界受很多外界因素的干扰，实际情况下，受限于开发者的技术素养、外界依赖的参差不齐，甚至是受限于 KPI 的导向，都将使得这种理想下的最佳实践无法达成，但微服务架构给予了我们可以通过团队的协作和努力，从而无限接近理论中的最终解的能力。

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

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

前后端组合拳

同时，微服务架构由于语言无关性，还抹平了一些技术上的鸿沟，前端同学很多擅长 nodejs ，也可以在微服务的设计中一展身手，更使前后端在技术上的交流和沟通会更加有默契。我们的产品线中还有一个特殊的产品：AppStudio ，专职于 WebIDE 的研发工作，将来无论是数据服务提供的数据出口，还是FaaS里的函数，还是微服务本身的开发，都可以与 AppStudio 结合，由用户自主开发，可以完全不用脱离 DataWorks 全域大数据平台，就从数据开发到 表设计，再通过微服务编写业务逻辑，达成数据输出的目标，一站式完成用户的订制需求。

架构驱动职责的转变

上图是未来的团队职责分工的一个构思，前后端研发同学在这套组织架构下，打出一套组合拳，直击痛点问题，帮助用户攻克技术难关，实现生态的繁荣昌盛。

展望未来

技术和架构的未来是什么样子的的理想中，软件工程的研发技术应该是一个没有止境和边界，且越来越智能化的领域。DataWorks 的产品中已经有很多开始向智能化的方向前进，比如基于 VSCode 应用了 Markov 算法的智能编程插件。研发团队的未来很大程度上取决于体系的架构，我们应该鼓励创新，鼓励对技术前沿和边界的探索，不应该人为的制造太多规约从而限制了思考的天马行空。如果有一天，智能化编程终于开始替代人工开发，那么通过改变架构的设计，研发人员也一定可以在新的架构中寻找到新的职责。

世界是变化的，也是有规律的，我们的技术愿景应当是为这个变化的世界构建出成熟且不断进化的工程体系。面向未来，拥抱变化，为了无法计算的价值！

Hot

近期热文阅读推荐

1、《我在阿里做中后台开发》 — 牧瞳

2、《那些年，我们见过的 Java 服务端乱象》– 常意

3、《阿里巴巴在开源压测工具 JMeter 上的实践和优化》–  韩勇

4、《研发运维效率提升100%，机器成本下降50%，阿里巴巴在 Serverless 计算领域的探索》– 誓嘉

Tips：

# 点下“在看”??

# 本期奖品是来自淘宝心选的精梳棉柔软素色浴巾 。