本文介紹了我們這幾年對大數據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的問題。