第三屆搞搭建|月飛-如何設計實現中後臺搭建 - PaaS 平臺

前言

Hi，大家好，今天非常高興能有機會作為講師，來給大家分享關於《如何設計實現中後臺搭建 PaaS 平臺》這個話題。今天的分享將圍繞阿里淘系技術部飛冰系列產品中的中後臺搭建產品 iceluna 來進行展開。

個人介紹

在正式分享之前，先自我介紹一下。我是來自阿里淘系營銷中後臺團隊的月飛，負責中後臺搭建產品 iceluna，以及《阿里集團中後臺搭建協議標準規範》的推廣和落地。2013 年加入阿里巴巴聚划算，負責 PC & 無線詳情。2016 年加入天貓，帶領營銷玩法團隊，負責玩法、互動型別業務。2019 年加入淘系技術部，帶領營銷中後臺團隊，負責中後臺業務，專注於中後臺搭建產品建設。

話題介紹

今天的話題是搭建，以面向角色的不同大致可以分為面向運營和麵向研發兩類搭建產品。面向運營的搭建產品主要是以視覺化配置 ( No-code ) 的方式進行完整頁面搭建，如營銷活動頁面搭建。面向研發的搭建產品主要以低程式碼開發 ( Low-code ) 的方式，搭建“中後臺系統”或者“無線模組”，如商家、小二後臺系統的搭建，無線 Rax 模組的搭建。今天我這邊的話題是中後臺系統搭建，跟營銷活動類頁面的搭建在面向角色和搭建模式上是非常不同的，接下來主要圍繞 “ iceluna 產品 ” 和 “ PaaS 平臺建設 ” 2 個維度來展開分享。

分享大綱

這是我分享的大綱，我會先對 iceluna 這個產品進行整體介紹，講解下產品背景、定位及現狀。第 2 部分會從架構設計、功能模組設計、研發流程設計三方面來介紹中後臺搭建產品的設計思路，讓大家對 iceluna 產品全貌有個基本認識。第 3 部分會著重從中後臺搭建基礎設施維度來講一下 iceluna 是如何建設搭建基礎設施的。第 4 部分則會回到 PaaS 平臺這個焦點，來講解 PaaS 平臺需要建設的核心能力。最後會稍微做下總結和展望。

iceluna 產品介紹

產品演示

大家現在看到的是 iceluna 介面，因為目前產品還未開源，還未對外網訪問，大家可以先看一下這是我們研發中心的一個站點首頁，第 2 頁是站點區塊中心，在這裡面可以看到區塊市場，區塊管理等內容，因為演示頁面數有限，在這裡還可以看到頂部 tab 還有元件和模組等物料管理。第 3 頁是應用研發中心，裡面有頁面，應用元件，導航，資料中心，釋出等等一系列操作的介面。最後這 1 頁是 iceluna 的低程式碼搭建編輯器，這也是 iceluna 產品最核心的一個能力，總體介面和產品形態還是比較清爽，中間搭建的是一個商品列表頁面。

產品背景

剛演示了 iceluna 幾個核心頁面，對整個產品有了一個基本的瞭解，iceluna 產品發展至今已經經歷了 3 年半時間，產品一路迭代演進至今的低程式碼開發 PaaS 平臺，背後有著一系列原因。在瞭解這些原因之前，想先跟大家普及一個概念，今天我們一直在提的“低程式碼開發”。對於 iceluna 通用搭建來說，有著自己的一點理解，它是通過視覺化的方式，使具有不同經驗水平的開發人員可以通過圖形化的使用者介面，使用拖拽元件和模型驅動來搭建網頁的開發模式。

瞭解完這個概念，我們來談下 iceluna 產品的背景：

• 中後臺技術之殤：在淘系整個業務偏消費者端，中後臺這一側人力投入是偏弱的，這是目前中後臺的一個困境。我們有大量的商家或小二作業系統，前端人力相當緊缺，大量系統依賴後端/外包/ ISV 負責研發，由於前端工程環境複雜，技術迭代快，門檻高，在效率/質量/體驗/可維護性等方面存在較多問題，對於如何賦能？如何改善協作模式？傳統原始碼模式已不能滿足業務發展的訴求，對於低程式碼開發模式的需求日趨強烈。
• 低程式碼開發模式的崛起：據 Forrester 市場調查結果，通過低程式碼開發模式可帶來數倍甚至 10 倍以上研發效率的提升。這對於中後臺現狀面臨的一個業務壓力，是我們非常迫切需要解決的一個問題，那就是如何提效的問題。它給了我們足夠大的想象空間。近年來各大網際網路巨頭公司都以紛紛投入到低程式碼或無程式碼平臺的建設上來。在阿里的話，各大 BU 也是重兵投入到這一塊的。這也就衍生出來第 3 個問題，那就是搭建氾濫後的技術收斂和統一。
• **搭建氾濫後的收斂和統一：**阿里內部各 BU 針對不同業務場景構建保守估計有數十個以上低程式碼搭建產品，投入成本巨大，能力完善程度相對不一。在搭建這塊如何收斂和統一？完善搭建基礎設施，由集團層面提供統一的搭建服務的執行和開發環境，是勢在必行。我個人作為集團搭建協議的負責人，也是希望通過 iceluna 產品去解決這一塊的問題，能講 iceluna 演進成為一個搭建 PaaS 平臺，去提供搭建底層服務的能力，服務全集團的搭建產品。

產品定位

目前 iceluna 產品有著 3 層定位：

1. 中後臺通用搭建產品：由淘系技術部研發，面向全體研發人員可用，打造一箇中後臺通用的搭建產品。由於淘系業務幾乎以商家，小二運營作業系統為主，業務邏輯多，互動複雜，很難抽象固定場景的業務模版或視覺化配置的解決方案。因此，需要我們低程式碼開發的中後臺搭建產品具備有極強的通用性和擴充套件性，才能夠 100% 覆蓋複雜互動的中後臺系統頁面的搭建。
2. 全鏈路低程式碼開發平臺：集前端應用工程建立、開發、除錯、釋出，甚至到頁面的託管，全鏈路一體化的低程式碼平臺。遮蔽複雜的前端工程體系，全鏈路打通。
3. PaaS 平臺：建設搭建基礎設施，基於標準搭建協議生產搭建物料，為各業務場景提供搭建服務的執行和開發環境。 目前 iceluna 的 PaaS 平臺主要以以下 2 種模式提供服務：
4. 平臺模式：業務研發進入 iceluna 研發中心，全鏈路在 iceluna 平臺上進行編輯器定製和執行，業務託管在 iceluna 平臺上；
5. 中臺模式：脫離 iceluna 研發中心，對外將 iceluna 編輯器能力和低程式碼能力以 npm 包形式提供出去，助力於孵化各個領域場景的獨立的低程式碼編輯器，獨立部署。

然後，我們在目標設定上，對應有如下 3 個目標：

1. 賦能：賦能是我們第一重要的目標，因為在目前中後臺發展的業務現狀下來說，賦能恰恰是目前最能消化中後臺業務壓力的一個重要手段，這是我們經過 2 - 3 年在業務上不斷摸索下得出的一個結論，賦能可以通過後端、外包，改變與前端的一個生產關係，去改善和提升研發專案或者說總個研發團隊的生產力，使得我們後端外包可以跨界的工作，減少一些不必要的依賴和成本。
2. 提效：目標還是降低研發成本。提效一直是我們技術永恆的話題，但就 iceluna 現狀來說，提效效果並不是特別的理想，在下一頁現狀會聊到。
3. 搭建生態：希望成為一個 PaaS 平臺或搭建中臺，去孵化領域搭建產品，形成搭建產品矩陣，在各領域上有更高研發效率。

產品現狀

iceluna 是一個面向集團提供服務的通用低程式碼開發平臺，基於產品定位和目標，iceluna 在賦能、提效、搭建生態上均取得不錯成果。

• **賦能：**活躍使用者數 1000+ ，後端佔比 44% ，前端佔比 39% ，測試佔比 11% ，外包占比 7% 。從佔比可以看到，有超過 60% 的使用者屬於非前端研發人員，在使用 iceluna 進行系統頁面搭建。通過資料可以看到， iceluna 在賦能上有不錯的效果。
• **提效：**上線應用 440+ ，頁面 6000+ ，覆蓋阿里多個部門中後臺應用研發，經霍爾斯特德軟體複雜度演算法模型測算(後面章節會介紹)，人均研發效能提升 200% 左右。
• **搭建生態：**提供完備的搭建基礎設施服務 & PaaS 平臺服務，已孵化 8+ 業務場景定製的搭建產品。

iceluna 架構設計

架構設計

上圖是 iceluna 產品從 PaaS 角度看的一張架構分層圖，從圖上我們可以看出，核心包含後端服務、搭建基礎設施、PaaS 服務、研發中心、搭建產品 5 層。下面對每一層服務能力做介紹。

• 後端服務：基於 Node.js 的 Midway 框架實現的一個 Server 層，提供搭建平臺資料介面和 Socket 服務。
• 搭建基礎設施層：目標提供搭建編輯器的開發環境。核心包含中後臺搭建描述協議、低程式碼編輯器、外掛生態、物料生態 4 個模組能力建設；
• PaaS 服務層：提供搭建編輯器的執行環境，使其能具備有完備的搭建配套服務能力。
• 研發中心層：業務研發的主陣地，提供雲端一體化的研發流程。包含站點中心，應用中心，物料中心，資料中心 4 個功能模組。
• 搭建產品：最上一層是搭建產品層，是 iceluna 作為 PaaS 平臺或中臺，目標孵化的各個垂直領域的搭建產品。

功能模組設計

接下來從功能模組設計角度來進一步瞭解 iceluna 的功能全貌，還是基於剛 PaaS 角度的架構設計核心 3 個分層來拆解裡面的核心模組。

搭建基礎設施這層的話，就包括基礎能力的建設，包含搭建協議，視覺規範，工程腳手架等原始碼級別的一些基礎能力。其次是我們搭建編輯器核心，包含了骨架、主題包、外掛、用於配置視覺化屬性皮膚的控制元件，另外就是我畫布和渲染引擎 2 個核心模組，另外還有國際化能力模組。在外掛生態模組上，目前整體搭建編輯器上所有的功能模組均是以外掛的形式存在。比如在頂部我們會有模型驅動、影像識別、資料驅動、邏輯編排、流程編排等外掛，這樣一些外掛是目前我們重點推廣或重點研發的外掛，作為研發模式升級提升效率的核心主抓手。其次是編輯器上常規一些的大綱樹、屬性/事件/樣式/資料等外掛，在現階段主要以視覺化增強來達到提效目的。在物料生態方面，我們希望構造一個完備的物料生態，通過低程式碼方式開發搭建元件、搭建區塊、搭建模版、元件例項，並進行物料的釋出和共享。對於  PaaS 和研發中心模組就不再一一做詳細介紹。

研發流程設計

這一頁重點介紹 iceluna 研發中心的研發流程設計，主要分 2 個許可權角色：

1. 站定管理員：一般由專業業務前端負責，建立站點稽核通過後，可以完成站點基本資訊、編輯器預設配置、應用預設配置、物料預設配置等資訊。該配置講決定了在該站點下建立的應用主題、搭建編輯形態、以及物料供選池子等。
2. 應用管理員：選擇進入某個站點後，可以在該站點下建立應用、建立多分支、進入搭建編輯器搭建頁面或元件，線上實時除錯，一鍵釋出部署等操作。

中後臺搭建基礎設施建設

瞭解了 iceluna 從各個維度的設計，相信對 iceluna 的產品設計有了一個更全面的認識；那麼接下來，我們從實現層面，看看 iceluna 建設了哪些基礎設施能力，來保障搭建平臺的技術先進性。

從這一頁內容是我們整個低程式碼搭建基礎設施的一個內容全圖，從左側我們可以看到一個物料研發的流程，由專業前端同學研發原始碼的物料，並沉澱到物料中心，這樣一個原始碼的物料，通過我們一個解析模組，可以生成一份搭建元件描述檔案，有了這份描述檔案，就可以入駐到我們的低程式碼搭建編輯器裡面來，低程式碼搭建編輯器會識別這個元件，生成這個元件的屬性配置皮膚，並具備有良好的搭建編輯體驗。其次，編輯器可以將已入駐的原始碼元件，以釋出的方式上行到物料中心，沉澱成為一個搭建元件。多個搭建產品矩陣，基於相同協議標準，與物料中心的上下行，使物料得以流通和複用，從而形成物料生態。從最右側可以看到，前後端、外包、測試都是通過搭建方式來使用低程式碼編輯器，低程式碼編輯器成為了最核心的一塊能力。如何保障低程式碼編輯器的技術先進性，總體建設的思路，從以下 5 個方向闡述：

1. 首先要定義一個搭建描述協議的標準規範，所有搭建產品遵循這套搭建規範，這樣可以使物料得以流通。
2. 我們要構造一個搭建編輯器開發生態，iceluna 作為 PaaS 平臺或中臺提供出來的一個能力，去低成本的孵化各場景下的低程式碼編輯器；
3. 就是我們提供出來的低程式碼編輯器，在面向不同端的一個訴求，我們會包含 React，Rax，小程式等技術棧的搭建，需要編輯器能支援多技術棧，適配多端。
4. 相比其他低程式碼編輯器，它如何保持技術先進性，有哪些核心能力建設。
5. 是我們要打造的外掛生態 和 物料生態。

搭建描述協議標準規範

如何指定搭建描述協議的標準規範？從以下 4 個方面闡述我的一些思考：

1. 版本化、語義化、漸進性描述：版本控制，語義清晰，簡明易懂，可讀性強；搭建的本質是通過原始碼元件進行巢狀組合，從小往大、依次組合生成元件、區塊、頁面，最終通過雲端構建生成 應用 的過程。因此在搭建基礎協議中，我們需要知道如何去漸進性的描述元件、區塊、頁面、應用這 4 個實體概念。
2. 不引入新概念，可與標準原始碼互轉：不引入新的語法概念，程式碼部分純 JS 語法，降低上手門檻；明確每一個屬性與原始碼對應的轉換關係，可生成跟手寫無差異的高質量標準原始碼；
3. 可擴充套件，可流通性，面向多端：支援第三方 npm 包的引入，增強協議描述能力的擴充套件性，以應對不同應用複雜多變的需求，如 Lodash ，Moment.js 等第三方工具庫；產物能在不同搭建產品中流通，不涉及任何私域資料儲存，統一標準，構建搭建物料生態。不能僅面向 React，還有小程式等多端；
4. 支援國際化

低程式碼編輯器開發生態

iceluna 作為一個 PaaS 平臺或搭建中臺，我們希望把搭建編輯器底層所有的能力都能原子化的開放出去，所以我們在建設搭建編輯器的時候考慮到了以下幾個問題：

1. 分層架構：整個框架分為四層能力的建設，最裡層為搭建編輯器的核心（主要有訊息通訊、狀態的管理及配製的解析、骨架的載入、外掛的機制的載入等能力）；其次為渲染模組，也就是渲染模組的部分，它的輸入就是符合搭建描述協議的 Schema，通過這個模組可以把整個頁面渲染出來；再往上為編排模組，主要負責畫布區域的物料拖拽、下鑽編輯、點選，快捷鍵，多設計模式等操作，提供了靈活的擴充能力；最上層為整個編輯器的框架，包括骨架、主題以及編輯器裡面所有的皮膚都是以功能外掛的形式整合進去的。
2. 模組化解耦：這裡的框架分層，每一層均為獨立 npm 包，提供原子化服務的能力去開放。比如我們可以以整體低程式碼編輯器整體開放給需要的場景，也可以只以編排引擎或渲染引擎的方式去開放，如物料中心搭建物料的預覽。
3. 擴充套件能力及開發生態：除了提供現有的能力之外還提供完整的骨架，外掛及控制元件的開發腳手架及命令列工具來保證整個低程式碼搭建編輯開發機制是完備完善的，同時整個骨架、外掛也是可以在我們整個平臺進行配製或定製。

低程式碼編輯器多端適配

目前搭建編輯器面向的領域不僅僅是中後臺 React 的體系，還包含有 Vue ，小程式、Rax 的體系，這樣的一些體系因為底層的技術棧不同，對於元件的解析和渲染存在較大差異，不能通過純粹的 React 渲染模組來把總個頁面渲染出來。所有呢，我們怎樣去適配多端，需要針對不同的技術棧，來實現對應的渲染引擎，通過很薄的一層適配層來使得我們的搭建編輯器支援各個技術棧的渲染，從而達到多端適配的目的。比如，阿里表格資料包表的搭建， imgcook 消費者端搭建，淘寶小程式搭建等。

低程式碼編輯器核心能力

第 4 塊內容，就是我們如何保障搭建編輯器技術先進性的一些核心能力。

1. 開箱即用： 提供全鏈路一體化的搭建服務，不需要到線下去 2 次開發。其次支援定製搭建編輯器和定製業務主題風格。同時在我們平臺上支援多人協作、多分支並行開發，可以應對大型複雜工程。比如淘系營銷系統，同時會有數十個人並行開發同一個應用，往往會建立數個分支並行開發需求。所以呢，像這樣一些大型複雜系統，中後臺搭建系統不具備有多人協作和多分支並行開發的能力，那基本上在我們的業務場景上是無法落地的。所以這 2 塊能力建設非常關鍵和重要。
2. 安全沙箱隔離：我們對業內比較多的搭建產品做市場調查，發現較多搭建編輯器是沒有做好沙箱隔離的。 iceluna 發展 3 年，反覆從做隔離到不隔離幾個階段的不斷迭代，最終徹底解決掉所有問題，完全實現沙箱隔離，從而保障搭建頁面與編輯器本身完全隔離，互不干擾，並支援獨立主題設定。
3. 實時除錯能力：我們的畫布是一個真實的 Runtime ，它不是一個模擬器或不完整的渲染，業內很多低程式碼編輯器在搭建狀態就是一個純 UI 的渲染，通過低程式碼方式配置了互動資料或事件，它無法實時實時生效，需要通過預覽或釋出等鏈路才能除錯 。而中後臺場景業務邏輯非常重，往往需要高頻的實時除錯，這也是跟其他搭建產品不同，是結合業務場景建設的一個重要能力。

低程式碼編輯器物料生態

我們提供的通用搭建平臺，對於不同的業務場景，對於物料的訴求是不一樣的。今天，我們的搭建平臺服務於 400 多個前端應用，要服務集團 20+ 部門，或者更大的一個組織體系，如果只提供一套物料庫，那搭建平臺的可用性會因此而大打折扣。我們需要針對不同 BU 不同業務場景，能夠具備有快速接入不同物料的能力，第 1 點我們要能快速生產物料，第 2 點能快速接入已有的物料，第 3 點就是能夠讓這個物料流通起來，能夠變成一個生態的機制，就如 Iconfont 圖示生態一樣。所以 iceluna 也在致力於怎樣去打造一個低程式碼搭建物料的一個生態。我們在這塊做的核心工作，主要如下：

• 統一搭建物料描述協議：統一標準，規範生產，提升搭建物料的可複用性。
• 實現物料低成本接入：支援 React 元件 npm 包低成本的接入，不需要對元件進行 2 次包裝或開發，通過簡單配置一個表單，就可以將元件接入進來，並且保障元件在原始碼裡面完整的所有屬性，在屬性配置皮膚可以具備完整的視覺化配置能力，無論你的屬性是什麼型別，陣列型別也好，物件型別也好，ReactNode 型別也好，都具備有完整的視覺化機制，來保障良好的編輯體驗。
• 搭建物料流通：建設搭建物料市場，形成類似 Iconfont 的生態機制。

我們回到左側圖上來看，我們的低程式碼編輯器，它不僅僅是可以接入元件，最重要的能力就是通過低程式碼的方式來生產元件，為什麼？低程式碼編輯器面對更廣的使用者，比如後端和外包同學，他們不掌握很多的原始碼知識，也不掌握原始碼的工程體系環境，但是他們同樣會有做元件的訴求。其次，搭建編輯器本身就是一個提效的開發模式，無論是前端還是後端，研發頁面還是元件，低程式碼開發同樣帶來開發側的效率提升。在 iceluna 上，我們也提供了物料專屬的搭建編輯器，可以在我們的平臺上通過搭建的方式搭建物料，並且把這個物料上行到我們的物料中心，最後形成物料流通的機制。

提供搭建服務的 PaaS 平臺建設

這一章節，回到我們主題的核心重點— PaaS 平臺能力建設上來。對於在聽的同學來說，可能對於 PaaS 平臺的定位也不是特別清楚。PaaS：平臺即服務 ( Platform-as-a-Service )，iceluna 的 PaaS 定位是把搭建編輯器的執行和開發環境作為一種服務，提供給不同業務場景下的搭建產品。

前面我們講到了搭建基礎設施是提供搭建編輯器的開發環境，那上層我們還需要一個更加完善的平臺側服務能力，來提供搭建編輯器具備完整良好的執行環境，使得我們具備有一體化研發的能力，在整個能力的基礎之上去孵化垂直領域的搭建產品。

我們將從下面 6 個維度來介紹 Paas 服務的能力：研發中心編輯器定製、雲端構建 & 釋出 & 儲存、多人協作、多分支開發、程式碼回滾、效能衡量。

搭建編輯器定製服務

在我們的站點中心提供了一個可視的方式來進行一個編輯器的配製，通過雲端構建就可以構建出不同搭建編輯器，比如右邊的 Iceluna 搭建編輯器及下面的 imgcook 編輯器，就是在研發中心建立了 2 個不同的站點，分別構建出來的編輯器。剛我們看到了編輯器的一份配置，那麼編輯器具體可以配置哪些內容呢？

• **佈局定製：**編輯器面向的領域不同，場景不同，做消費的頁面和中後臺頁面，它對於皮膚畫布的大小及可利用區域都是不同的，所有我們對於整個搭建編輯器皮膚佈局是有不同的訴求。而我們可以通過這個的一個佈局定製來快速構建出不同的佈局出來，再配製不同的外掛可以形成一個全新的搭建編輯器。

**

• **主題定製：**搭建編輯器可以嵌入不同的場景，比如在淘系裡面我們可嵌入 WebIDE 跟原始碼進行一個互轉能力的打通，你可以同時切換到原始碼的開發，也可以同時切換到視覺化的開發，在 WebIDE 的下面，它整個視覺風格就是個深色系，所以我們在平臺上面也提供了主題包配製的一個能力，然後再適配不同主題風格搭配來定製編輯器。

• 外掛定製：我們提供了一個完備的外掛化機制，整個搭建編輯器上的所有皮膚都是以外掛化的形式來承載的，目前 iceluna 編輯器上總共有 26 個外掛（圖右可視），同時在外掛生態池子裡面，我們往後會沉澱越來越多的公共外掛，並且這個外掛都是可以被嵌入到搭建編輯器裡面的。  如果這個外掛池子裡面沒有你想要的外掛，我們也提供了外掛開發腳手架，給你來實現與編輯器功能解耦，可插拔，可定製的一個獨立的外掛。

雲端構建/釋出/ DB 儲存服務

雲端構建服務是 iceluna 低程式碼開發平臺核心鏈路之一，目前雲端構建的能力主要是把我們在應用搭建過程中搭建出來的頁面，然後元件產生出來的 Schema ，存在資料庫裡面之後的碎片化資料，通過雲端構建的方式，去釋出成應用或元件或者編輯器資源包，同時構建出來的這些應用、元件它們的原始碼，我們也推送到 GitLab 作為儲存，也會發到 CDN ，申請 CDN 資源最終推送到線上去。目前雲端構建主要支援應用（日常/線上釋出）、元件（Low code/ Procode釋出)、編輯器（畫布/框架的構建）3 大功能 6 種形態構建能力。

雲端構建架構圖分為資料層，執行層，通訊層，應用層4層，如圖左所示。它的核心能力主要包含如下：

1. 編輯器去中心化：在我們的平臺，站點下建立的每一個應用均對應一個自己的編輯器資源包，這樣的話，我們可以給每一個應用去定製自己的主題和元件的擴充套件，並帶有版本化控制的能力。
2. 一鍵釋出部署：進行許可權管控；對元件的依賴進行動態分析；在分支釋出過程中會需要合併主幹，如果產生衝突的話，線上解決衝突；Webpack 構建和 CDN 釋出。
3. 多系統打通：GitLab 儲存以及通過 GitLab 來做程式碼回滾的機制，其次通過 Tair 做構建過程的併發鎖，最後，通過 ODPS 做構建日誌的分析。

多人協作服務

在 PaaS 平臺，多人協作是一個不可缺少的一個能力，它的主要原理是通過 WebSocket 的連線加上一個檔案鎖的機制，檔案鎖目前在平臺上包含頁面鎖、元件鎖、應用級別公共檔案鎖這三個維度的鎖。大體思路主要是利用WebSocket 的保活的機制，與 Tair 保持一個心跳保活的訊息通訊。在 Tair 側則是儲存一個主動失效的分散式樂觀鎖，然後去儲存這個鎖的資訊，大概 10 秒鐘之內沒有新的心跳過來，這個鎖就會失效。所以說一旦客戶端或 Server 端的 client 斷了之後，那這個檔案鎖就會被自動釋放這樣一個機制來做的多人協作服務。我們也對業界多人協作的方案做了一些調研，比如釘釘文件、Google Docs 等都利用了業界比較先進的 OT 技術，實現相對複雜，功能也更強大。對於低程式碼搭建編輯器場景來說，編輯鎖的能力已經夠用了。左側 iceluna 編輯器上紅線框出來的點，都是有鎖的功能。

多分支並行服務

多分支並行的能力最重要解決的一個問題是衝突解決，對於原始碼來說，衝突解決是已經存在的一個能力，但對於低程式碼雲端工程體系來說卻是一個非常難解決的問題。截止目前為止 iceluna 衝突解決的程式碼仍然是搭建描述協議 Schema 的程式碼，比對時相對比較困難，這是問題之一。其次，總個衝突解決的流程，多分支並行，包括程式碼回滾到資料庫 DB ，這一塊總個機制的構建也是相對比較複雜的。總體的流程如上圖所示。

程式碼回滾服務

程式碼回滾服務主要利用的就是基線同步的機制，這個機制保障我們可以指定任意 commit hash 進行編輯器應用程式碼回滾。因為我們在低程式碼平臺的每一次釋出，都會將程式碼同步到 Git ，所以任何一次釋出的程式碼都可以回滾到我們的低程式碼編輯器。這裡最大的難點就是 “ 資料庫的碎片化資訊 ” 與 “ Git 倉庫上原始碼工程檔案 ” 能具備有一一轉換的關係。

搭建效能衡量體系

最後一頁內容提到了低程式碼搭建平臺的效能衡量體系，其實它跟技術不太相關，但為什麼要講效能衡量這個體系呢？我們在做搭建平臺 3 年，還有其他兄弟團隊的搭建平臺都面臨一個問題，就是都說搭建能提效，但沒有一個很精確衡量提效多少的方法或策略，所以我們花了很長時間去研究，怎樣有一個策略來衡量搭建是不是真的提效了。具體的實現方式，衡量標準是我們藉助業界霍爾斯特德軟體複雜度測量演算法模型，這個演算法模型可以將搭建頁面時產出的 Schema 作為一個輸入，它通過 Schema 裡面的如表示式個數，程式碼長度等數十個運算元，可以計算出 Schema 的複雜度以及預計開發時長。

當然，這個預計開發時長需要反覆去調參，比較符合真實情況後會得到一個相對準確的數字。另外呢，低程式碼搭建相對於原始碼開發，有一個好處就是使用者都是在我們的平臺上進行操作，平臺側可以通過埋點，操作日誌等手段記錄每一個研發人員在某個頁面上的操作記錄，在 2 次操作間隔時長在 10 分鐘之內的算有效開發時間段，有效時間段的總和就是實際開發時長。通過計算公式 研發效能 = 預計開發時長/實際開發時長 就可以知道該使用者開發效能是提升還是降低。在 iceluna 平臺上資料中心會有專門一個效能中心，來反饋總個平臺的總體人均研發效能、個人研發效能等資料。所以說這一點非常有價值，所以分享給大家。

總結&展望

• 前路總結：中後臺通用搭建產品建設成本超高，能很好的解決賦能&協作的問題，但研發提效未達數倍甚至 10 倍的預期，需要往模型驅動、智慧搭建等 Nocode 新研發模式升級，或建設領域搭建產品矩陣來達成數倍提效的目標。
• 展望未來：致力於將 iceluna 打造為中後臺領域的 hpaPaaS 平臺（超高生產力平臺）。如果志同道合，期待的你的加入！

團隊風采&招聘

最後，就是我們團隊的一個招聘，如果有意向的話，請掃碼加一下我的微信！

投遞簡歷方式

• 郵件：jianhui.fjh@alibaba-inc.com
• 釘釘：月飛
• 微信：

  

團隊產品連結：

• 飛冰：ice.alibaba-inc.com/
• 淘系前端部落格：fed.taobao.org/
• 淘系前端知乎專欄：zhuanlan.zhihu.com/tmallf2e

歡迎加入我們的團隊！！