我在阿里云做飞天大数据平台WebIDE: 序言

[jifeng]

本文介绍了我们这几年对大数据WebIDE的一些工程实践和背后的思考，主要跟大家聊下当时在业务快速发展时技术遇到的问题以及如何应对的技术选型，不涉及具体的过多技术细节，更详细的功能介绍和架构设计之后会陆续分享出来，跟大家做具体的交流

什么是飞天大数据平台？

讲我们做的WebIDE之前，我先讲下飞天大数据平台是什么？
飞天大数据平台是阿里云推出的AI加持的大数据平台，作为阿里巴巴自主研发、开放兼容的大数据平台，拥有中国唯一自主研发的计算引擎，是全球集群规模最大的计算平台，最大可扩展至10万台计算集群，支撑海量数据存储和计算，涵盖了数据管理、大规模稳定计算、数据开发、数据智能治理的整套数据业务。

大数据 WebIDE 要解决什么问题？

阿里的大数据平台业务，一直有两条主线在推动它的发展；
一条是底层引擎的更新升级换代，由最早搭建的 Hadoop 云梯一集群，到自研Maxcompute，再到依次扩展到目前Flink，机器学习，交互式查询等各个计算引擎的蓬勃发展；
另一条线就是基于各引擎之上的以 WebIDE为核心 的在线数据开发工具层，从在云端，到D2，再到目前的全域智能大数据平台Dataworks
前者是为了解决计算能力的问题，让能计算的数量更大，速度更快，实时性更好
后面则为了解决使用门槛的问题，串联起各个引擎，让用户能便捷地使用上前者提供计算力
打个的比方：前端像发电站，后者像电力设施，把“计算力”能像“电”一样传输到终端

架构演进

最纯粹、最抽象的设计难题之一，就是设计桥梁。你面对的问题，基本上就是如何使用最少的材料，跨越给定的距离
——保罗.格雷汉姆 (知名黑客 硅谷牛人，《黑客与画家》作者)

在具体描述我们的架构演进之前，还是先引用下保罗.格雷汉姆这句名言，它也是我们在做重大架构升级时的指导思想；
很多时候大部分人因为走得太远，而忘记了为什么出发。建一座桥并不是目标，跨过那条河才是；
做一个通用并且看起来有技术“亮点”的 WebIDE 并不是我们的目标，让大数据客户更便捷地使用上云上的计算力才是我们的初衷。因此每次做架构升级的时候，我们最重要的考量点就是基于此，它可能一开始并不完美，但是我们在各个阶段下做出最“有效”的架构
下图就是我们 WebIDE 的技术演进过程，重点描述了当时遇到的业务和技术挑战，以及与之对应的架构设计

1.0：云上时代

核心理念：一个浏览器完成所有数据开发
特点：B/S的架构做WebIDE的实践
挑战：从0到1，自研做个WebIDE

阿里飞天大数据平台的 WebIDE 起点在2012前后的对集团内使用的大数据开发产品：在云端。
这里说下背景，处于数据量和安全的考虑，数据是不能下载到本地，因此当时阿里内部的数据开发工程要做加工数据时，需要先连接到远端服务器，搞定一堆复杂的运行环境之后，才能用命令行工具执行一次次的查询任务；
上手门槛高，运行代码难系统沉淀，是当时我们用户切切实实遇到的痛点
为了解决这些痛点，就开始着手搞了第一版的WebIDE，期望用户只要一个浏览器完成所有数据开发
以下就是我们当时简单的架构图

当时 WebIDE 的概念在前端还不是门“显学”，ACE 和 CodeMirror 也刚刚崭露头角，VSCode（Monaco）更是要是多年后才横空出世，一骑绝尘，Thiea 和 Code Server 要更晚才在江湖上出现它们的身影；
而当时人就两三个人，而且大家在此之前更是在 IDE 这个领域也有太多的技术积累，难度和挑战是非常大的。
现在回过头来看这事，我们能在当时的技术条件下完成一个WebIDE 还是非常幸运。

这当中很重要的一个原因是当时很好得抓住了重点，具体因为大数据开发首选的语言就是SQL，核心功能是代码编写和运行，而像Debug，实时协同之类的需求优先级则没那么高，因此架构可以做得相对简单，最终快速结合业务有了不错的产出；

在这方面我也想分享很多目前也再做WebIDE方向的同学，WebIDE要做的功能点很多，而且每个点往往又可以挖得很深，因此一定要想清楚自己要做的WebIDE到底能解决本地IDE 没法或很难解决的问题，这需要有取舍，需要清楚地知道它核心功能什么能解决用户那些问题，千万不要只是简单地把本地IDE做Web化，因为这就像要在微软 Office 套件的世界里面再造一个Office技术难度和用户接受度可想而知

2.0：增强时代

核心理念：让编辑体验能更智能更高效
特点：前端AST语法解析, 可视化能力
挑战：在前端实现一套语法解析

时间到2017年，随着业务的发展和用户的急剧增长，当时WebIDE中编辑体验不佳的问题就逐渐暴露出来，其中最典型的例子就是代码开发过程中没有智能提示和实时错误提示等功能；
�
以SQL为例，如何在合适位置提示合适的信息，如何做到实时的错误提示，这一点功能看似简单但其实还是有一定的技术难度，因为它不能简单地做关键词无脑提示，而是要对文本内容做一次语法解析，针对解析结果做合适的提示；

因此这个时期我们花了很大的力气做了前端的SQL AST 解析和大量的性能优化，并以此为基础完成代码的智能提示和实时错误提示的等辅助编辑功能，并开始探索用可视化等方案来进一步降低使用门槛

大致的架构图如下

这里讲一个小插曲：
当我们启动要做这个事情的时候，考虑到改动量，我们打算基于之前的大架构上做；
但由于之前业界没有这方面的实践，我们在是否能在浏览器实现一整套的语言服务还是有一定的顾虑的，甚至在项目启动之后的一段时间里，我们没有绝对的信心，这种心态直到我们完成第一版Demo时才大大松了口气；
通过这件事，想跟大家分享的是前端能做的事情其实很多，关键是不要自我设置限制，深入到业务，勇敢地去尝试用前端的手段去解决业务的问题的，会为你打开一片新天地；

3.0：多语言智能化时代

核心理念：统一完整的架构设计
特点：LSP架构，插件化，智能化
挑战：完整的WebIDE架构，复用本地IDE的插件生态，智能化

当我们把 WebIDE 的架构发展到 2.0 的增强时代后，在SQL编辑器层面已经做到如鱼得水，但同时我们也在思考如何设计下一代的WebIDE架构，以适应接下来的业务发展。

随着业务的发展，我们预判到除了SQL之外，其他多语言（特别是Python，Java）的支持需求越来越高，我们又该如何提升我们的架构来对应接下来的挑战。

当时具体思考的出发点如下：

1. 之前主要是解决 SQL 编辑的场景，如果要支持Java，Python等多语言时，我们的架构是否能快速支持实时协同，Debug等高阶功能；
2. 如何更好地去复用开源的插件化生态，以自己所用
3. 之前为了解决 SQL AST解析的问题，当时前端就差不多投入了一个同学全职在搞语法解析的事情，而前端的人力在各个团队又往往是最缺的，如何让更多得同学能参与进来

基于这些思考，在团队核心同学的几轮讨论下，我们最终决定参考 VSCode 的 LSP 设计重新升级 WebIDE 的架构，它的架构图大致如下：

核心思想：
1.把纯 HTTP通信改成 通过 WebSocket ，一次来实现实时协同和对多个语言服务（Lanuage Server）的对接 ；
2.后端侧重实现 Lanuage Server 和 Dubug Server 语言解析和运行调试环境的功能
3.前端重点解决交互体验和编辑体验优化
4.改造完成的系统，整体的核心功能将会是稳定的，更多的外围功能通过插件化的形态来扩展新的功能；

未来展望

插件化

插件化的好处不言而喻，既可以吸纳更多外部好的插件来服务用户，又能让业务方通过开发插件的方式解决他们的长尾需求。
技术上讲，做插件化最重要的是要解决“易用”和“隔离”的权衡；

“隔离”方面VSCode在主流IDE方面实践得比较好又比较彻底的；通过进程隔离的方式，插件都只能运行在 Extension Host 进程里，而UI则在主进程里，插件们天然没法直接操作用户界面。VS Code 统管所有用户交互入口，制定交互的标准，所有用户的操作被转化为各种请求发送给插件，插件能做的就是响应这些请求，专注于业务逻辑。但从始至终，插件都不能“决定”或者“影响”界面元素如何被渲染（颜色、字体等，一概不行），至于弹对话框，在页面上增加某些按钮，就更是绝不可能

但我们毕竟不是款通用IDE，照抄这些原子性操作并不能最大限度提升我们的研发效率，如何复用阿里巴巴集团前端委员会的WebIDE，基于它之上去抽象我们业务上原子操作，目前就是我们在规划的重点

智能化

IDE 产品发展了这么多年，各款产品你方唱罢我登场，但到了目前的智能时代，如何用技术手段让 WebIDE 做得更智能是我们一直在思考的上一个点；
之前一款 AI补代码的IDE插件 是次不错的实践，其实我们今年年初开始也在做类似的实践，在用户许可的情况下，用深度学习的方法训练用户在WebIDE上写的代码，通过训练的模型再去做下一次更智能得提示；
如何将WebIDE 做得更智能，更懂“你”，是我们的一个在努力的方向

写到最后

这么多年一路走来，我们越来越意识到做WebIDE，思路绝不能仅仅停留在简单将本地IDE做到Web上。
WebIDE 和 本地 IDE 肯定是不一样，就像移动时代，绝不仅仅只是把web的屏做得更“小”那样，而是一种思路的变更；
WebIDE需要结合业务特点，提供本地 IDE 没法提供或很难提供的功能（比如本地无法模拟的运行环境，无法提供的计算能力），用“云+端”的思考，用云上无边界的计算力和一站式开发能力来弥补在编辑体验跟不上本地IDE的问题。