作者 | 昊禎
DataWorks 是一個提供了大數據 OS 能力、並以 all in one box 的方式提供專業高效、安全可靠的一站式大數據智能雲研發平臺，提供了數據集成、數據開發、數據治理、數據安全、數據服務、應用開發、機器學習完整數據鏈路的產品。
痛點
複雜的產品功能和技術架構
很多產品都提供了類似於 IDE 形態的富交互單頁應用，如下圖：
圖1. 數據開發 IDE
IDE 形態的產品交互類似於大多數前端工程師使用的 VSCode，包含了眾多的功能模塊（甚至在 VSCode 的架構中，一切功能模塊都是由插件提供），下圖是一個數據開發 IDE 所需的最基礎功能模塊：
圖2. IDE 基礎功能模塊
在基礎能力層面，與通用的 IDE 產品存在大量的能力重疊區，這也是一個 IDE 技術產品所需的最通用部分的功能；在此基礎之上，從業務角度出發定製了上層業務能力部分，包括各種大數據計算引擎、數據開發節點（類似於 VSCode 中文件類型）、以及“模塊”進行數據開發節點的分類和管理、看板負責提供整體數據開發節點流程的統籌視角和流程編排。
橫向角度看，DataWorks 擁有眾多的功能模塊，縱向角度看，DataWorks 上單單節點就達到了額上百數量級。包括功能模塊、上百數量級的節點，所有代碼都糅合在一個前端工程中，加上基礎的 IDE 功能和其它模塊代碼，前端工程儼然已經演化為一個單體巨石應用，隨著需求不斷的迭代和升級，現階段 DataWorks 前端工程的體量相對於第一個版本已經不可同日而語，目前單單一次構建發佈過程已經需要消耗 10 min+，可以預見的將來整個發佈過程將會多麼痛苦。
複雜的運行環境
DataWorks 面臨的運行環境放眼整個阿里經濟體都是及其罕見的複雜，為了混合雲（即專有云）這種私有獨立且封閉的環境，前端無法使用 cdn 的能力，如何保證同一套代碼能夠直接複用到彈內、公有云、混合雲三種形態的運行環境，這是一個極大的工程複雜度問題。
圖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 團隊在去年引入了微服務架構，將一些相對比較獨立的業務邏輯進行微服務化升級，相應的前端也引入了微前端 & 插件化架構實現個性化業務的開發和定製。
微前端
微前端是一種類似於微服務的架構，它將微服務的理念應用於瀏覽器端，即將 Web 應用由單一的單體應用轉變為多個小型前端應用聚合為一的應用。各個前端應用還可以獨立運行、獨立開發、獨立部署。
後臺微服務的一個很大的賣點在於，可以使用不同的技術棧來開發後臺應用。在大型組織機構裡，採用微服務的原因主要在於，使用微服務架構來解耦服務間依賴。
而在前端微服務化上，則是恰恰與之相反的，人們更想要的結果是聚合，尤其是那些 To B（to Bussiness）的應用。
針對 DataWorks 團隊的業務現狀，針對不同的計算引擎，DataWorks 開發了眾多的垂直領域的 Studio，每一個 Studio 雖然在產品交互、功能邏輯上存在大量的重疊，但是呈現給用戶的是眾多的產品，實時計算引擎的走 SteamStudio，離線計算引擎走 DataStudio，當然還有一些用於開發 FaaS 的 Studio 平臺。然而在用戶看來，所有的產品都是來自於同一家公司，他們就應該只有一個產品，同時由於產品功能的分散，導致一些公共基礎功能也是散點式的分佈在各種產品中，對於用戶的使用成本也是一個極大的挑戰。
產品方向也在往內聚的形式轉變，18 年底開始的 XStudio 項目就是希望能夠在一個 Studio 中集成所有計算引擎的開發節點來給用戶提供一體式的產品體驗。
聚合成為一種趨勢，相應的在前端架構層面我們也借鑑了微前端架構來進行架構升級，以實現不同 Studio 中開發的功能能夠聚合到一個應用中呈現給用戶。
在 DataWorks 產品體系中，每一個模塊、節點其實是一個可以獨立開發、獨立運行、獨立部署的單體應用，不同於常見的微前端通過路由來分發微前端應用，DataWorks 的每一個節點、模塊都是通過 Tab 切換式的分發機制：
當然，我們也有路由級別的微前端架構產品，比如：運維中心，通過點擊左側導航條進行路由級別的微應用分發和切換
插件化
插件的英文是 plugin，拆分開是 plug(插頭) + in，現實生活生活中，電源插線板就是這樣"plugin"應用的例子。插線板和通過插頭插入其中的電器構成一個物理世界的插件化系統。插線板通過插孔為“插件”提供電源，而給系統賦予了插件的能力。插入電視的插頭，就擁有看電視的功能，插入冰箱的插頭就具有冷藏食物的功能，插入檯燈的插頭，就具備照明的功能，等等。
一個良好設計的插件化系統和插線板的設計也是一樣一樣的。系統的核心應該是一個可熱插拔的“插線板”，負責給系統接入的插件提供電源（插件API），系統的能力是所有插件能力的聚合。和物理世界的插線板不同是，軟件插線板的插頭沒有數量的限制，也就是說系統可以接入任意數量的插件，意味著它的功能可以無限增加。
微前端架構解決了產品之間聚合的問題，但是針對 Studio 這種富交互產品來說，微前端的方式還無法解決細粒度的功能組合問題，比如下圖所示在一個節點單體應用的頭部操作按鈕區域，不同節點具有不同的操作按鈕，針對這種場景我們通過了插件化形式將按鈕 UI 及其背後的交互和業務邏輯拆分成一個個的插件，然後配合微服務 & 插件管控臺實現配置化的形式組合功能和模塊。
其實無論是微前端還是插件化都是解決產品功能的聚合問題，只是這兩個架構在 DataWorks 產品中解決不同領域的聚合問題。微前端架構解決了大區塊粒度的功能聚合，插件化則解決了細粒度級別的功能聚合、組合。
當然，在這種富交互的 Studio 產品形態中，微應用/插件之間的通信和交互是一個非常常見的場景，這塊我們通過下述一個統一的 Studio 底座層面進行統一的規範化和標準化。
Studio 統一底座
Studio 統一底座提煉了一個 IDE 產品形態基礎的能力，同時在上層封裝了一些 Studio 業務層面的能力，配合後文涉及的 Studio 插件化的方式，實現了所有 Studio 上層業務都是通過插件化的形式植入到 Studio 底座之上，同時配合後面涉及的“微服務 & 插件化管控臺”，我們實現了通過配置形式定製 Studio 產品功能，甚至可以支持快速搭建出來一個全新的 Studio。
統一的 Studio 底座除了可以進行統一的維護和升級之外，也將 Studio 底座複雜的工程結構從應用工程中剝離出來，減少了 Studio 應用工程的複雜度；同時，這也是一種統一的標準，底座規範了上層插件 & 模塊基礎的交互以及通信，這也為後續 Studio 統一插件化對於不同 Studio 之間實現插件互通提供了保障。
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 統一插件化支持了這種嵌套結構的插件渲染，同時配合“微服務 & 插件化管控臺”通過配置化的方式實現插件依賴編排，甚至配合微服務管控臺上的插件編排能力，一個應用完全可以通過配置化方式編排出一個完整的應用頁面。
同時，微服務管控臺提供了更為傻瓜化的可視化編排能力，可以通過可視化交互形式構建出一個應用的插件依賴關係，從而在 Runtime 運行時解析、渲染為一個完整的頁面。
微服務 & 插件化管控臺
前後端一體基於 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。
相關鏈接：
1、https://workbench.data.aliyun.com/
2、https://ide2-cn-shanghai.data.aliyun.com/
3、https://aws.amazon.com/cn/rds/aurora/serverless/
5、https://github.com/aliyun/alibabacloud-console-widget
6、https://app-cn-shanghai.data.aliyun.com/
文末福利
玩轉雲端開發 7 天訓練營
提前享受雲時代的原生開發環境，Serverless 研發從入門到精通，連續 7 天，每天一個直播，阿里專家手把手教你利用阿里云云開發平臺 get 雲端開發新技能。0 門檻打開瀏覽器就可以開發，最快 1 分鐘搭建個人網站，免費開發還送代金券、天貓精靈等多重好禮！
識別下方二維碼馬上入群學習，或點擊鏈接馬上參加：
等等，福利還沒停！關注下方公眾號轉發文章即參與抽取天貓精靈！
關注「Alibaba F2E」
把握阿里巴巴前端新動向