第三屆搞搭建|月飛-如何設計實現中後臺搭建 - 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

歡迎加入咱們的團隊！！