背景與價值
說到邏輯編排大家應該都不陌生了，目前我們集團有多面向後端的邏輯編排技術專項，且沒有統一的标準、沉澱通用的方案。也有前端邏輯編排項目，但均面向前端開發提效的邏輯編排，而我們是要打造一個面向非研發人員，可讓他們根據圖形化元件搭建出邏輯的平台。
為什麼要做這個呢，随着頁面可視化搭建的蓬勃發展，互動營銷類的頁面/元件需求日益增長，為了提高開發效率，研發側不斷地沉澱通用的基礎庫，與服務端商定标準化的接口，以此來減少維護成本，但現有的可視化搭建效率和研發效率都已經達到瓶頸了，再多的需求進來也是在堆人力了，經常會出現資源不足、排期緊張的情況，我們急需一種新的生産模式，給我們帶來生産效率的突破性提升。
那我們前端嘗試了頁面級、子產品級的複用，減少代碼重複開發，提升産研效率。我們是否也可以拆分到更小粒度，函數層的邏輯複用呢？這就是我們近期打造的具有前端特色的邏輯編排平台 - YOHO，建立令非研發人員自由且規範化編排邏輯的編排器，以NoCode的形式，借助圖形化元件，完成邏輯的搭建生産，并可複用于多業務場景。
本文通過邏輯編排可視化搭建的設計與業務實踐，來和大家做一些交流。
編排器
基礎概念
編排器是邏輯編排中通過可視化搭建，生成一條具有業務邏輯的容器；将邏輯流程圖導出，通過DSL轉化，生成業務中實際執行的代碼邏輯。可以了解為邏輯編排中生産邏輯的環節。
平台側編排器設計為如圖四個部分。工具欄、元件清單、搭建畫布、基礎配置。
工具欄包含儲存邏輯、檢查搭建規範性和導出邏輯這些基礎操作。
元件是邏輯中的一個節點，一個函數，是将業務中常用的邏輯抽離出來，按照編碼規範沉澱下來。如下圖清單中有不同形狀色彩的元件，是我們根據函數類型對元件的進行的分類。
中間部分是進行邏輯搭建的畫布，主要操作動作是将邏輯元件拖拽進來，通過具有指向性的線條将元件連接配接起來，組合成一條完整有始有終的邏輯，實作簡單的或者複雜的具有特定業務含義的流程圖，也是核心部分。
右側是點選某個元件所顯示的對應基礎配置資訊面闆，即函數的入參，我們的設計一定是令使用者可靈活配置元件基礎資訊。
在設計該編排器的時候，我的目的是通過技術手段，建立令使用者最大化自由編排且規範的編排器，使之無侵入、可複用各業務場景。下面介紹我們是如何具體設計的。
整體設計
元件設計
基于G6繪圖引擎能力，根據元件定義類型，注冊出不同形狀、色彩、結構的元件。元件由主體形狀、分支線、描述文字、節點四部分組成。其中節點如圖也分上下兩部分，上方節點是其他元件連接配接至目前元件的節點，下方節點是目前元件可連接配接至其他元件的節點。
為了令使用者更絲滑且更标準化地搭建邏輯，我們在設計元件時将一切限制條件，得已顯示，在使用者所有可執行的動作中，得已展現。例如我們在初始化元件環節，開發者可設定好該元件會有幾種輸出情況、幾個分支，每個元件可連接配接幾個其他元件，每條分支代表哪種結果導向，定向去做關聯。所見即所得，不讓使用者去猜或任意自定義連接配接。
這樣設計的目的：減少使用者操作成本，減少解釋成本，增強搭建規範性。
元件類型
根據元件是否含有邏輯，将元件分為兩大類：基礎元件、業務元件。如上樹形圖。
基礎元件不帶有任何業務邏輯，包含開始、結束元件，固定為一條邏輯的起點或終點辨別，每條邏輯必有開始元件和結束元件。把基礎元件設計為圓形、綠色；
業務元件均帶有業務邏輯，僅有一個輸入節點，依據元件可輸出的結果數量，将業務元件又更細粒度地分為三種類型。（詳情如下表）
結束業務元件，雖然帶有業務邏輯，但也可能是一條邏輯的終點。如跳轉新頁面邏輯，這個動作執行後會跳轉到一個新位址，無法在目前頁面目前邏輯繼續傳遞至下一動作，是以稱之為結束業務元件，是以設計它為僅有一個輸入節點，無輸出節點。因為同樣辨別一條邏輯的結束，我也将它設計為圓形，用黃色作為區分。
普通業務元件就是一個正常有輸入且有固定一種結果導向的元件，比如通過接口請求擷取資料，會有固定schema格式的傳回資料輸出；是以普通業務元件有一個輸入節點，一個輸出節點，形狀為長方形。
判斷業務元件會複雜點，根據元件設計規範，在建立元件時即可确定有多種結果輸出，該結果為>1種，且也會有固定schema格式的傳回資料輸出。如判斷使用者是否登入，分為已登入、未登入兩種情況；判斷業務元件也不是非1即0的情況輸出，也可能會有a 、b、c、d...多結果導向。是以普通業務元件有一個輸入節點，N個輸出節點，形狀設計為菱形。
我們根據函數類型定義、注冊元件，盡可能涵蓋所有的類型，目的就是讓這套邏輯編排方案通用化、可複用，适用于多業務、多場景。
注冊元件
元件有多種形狀、顔色、分支、節點不定，平台側注冊元件的思路：拿判斷業務元件為例，使用SVG繪制菱形 - 元件主體形狀，根據元件類型自定義元件樣式，根據元件的分支數量，動态繪制分支線的長度、節點位置、錨點資訊等等。
G6.registerNode(
'diamond',
{
draw(cfg: Cfg, group: GGroup) {
const size = [94, 64]; // 轉換成 [width, height] 的模式
const width = size[0];
const height = size[1];
// svg 自定義主體形狀
const path = [
['M', 0, 0 - height / 2], // 上部頂點
['L', width / 2, 0], // 右側頂點
['L', 0, height / 2], // 下部頂點
['L', -width / 2, 0], // 左側頂點
['Z'], // 封閉
];
...
},
afterDraw(cfg: Cfg, group: GGroup) {
const size = [100, 64];
const width = size[0];
const height = size[1];
// 分支描述資訊
addDesc(cfg, group, width, height, cfg.outLine);
// 分支線
addLine(group, width, height, cfg.outLine);
// 連接配接錨點（小圓點）
addNode(group, width, height, cfg.outLine, cfg.showNode);
},
...
},
'base-node',
); 元件分支線也是長短、方向各異，線的長度由分支數量決定，即代碼中outline字段：
const addLine = (group, width, height, outLine) => {
group.addShape('path', {
attrs: {
path: [
['M', -width / 2 * (outLine - 1), height + 3],
['L', width / 2 * (outLine - 1), height + 3],
['Z']
],
...edgeStyle
},
draggable: true,
});
} 元件的節點分為一個輸入節點，一組輸出節點，輸出節點的位置依然由outline決定
const addNode = (group, width, height, outLine, isShow) => {
// x坐标
let xPosition = i => {
return -width / 2 * (outLine - 1) + width * i;
}
outLine && new Array(outLine).fill(0).forEach((d, i) => {
group.addShape('circle', {
attrs: {
x: xPosition(i),
y: height + 4,
r: 4.5,
...dotStyle
},
name: `circle-shape-${i + 1}`
});
})
} 建立元件
使用者需要根據規範，去建立一個新的元件，初始化項目包含四個核心檔案，拿基礎業務元件舉例，如圖所示。
index.js 是元件的主體函數邏輯檔案，函數一般是有入參的，且可以讓使用者靈活配置。
input.json 檔案即定義為函數基礎配置資訊的标準Schema協定，該内容在平台側可渲染為表單，供使用者配置基礎資訊，在邏輯執行過程作為payload參數傳入對應函數。
基礎業務元件，函數執行有固定一種結果輸出的情況，那branch.json這個決定分支數量與分支資訊的檔案就有數組長度為1，隻輸入一項内容，錄入即可。
output.json 是主體函數執行後最終return傳回的data資料對應的标準json schema協定資訊。輸出資料是邏輯編排的産物，如圖，可供業務側綁定對應字段，可視化顯示出對應内容。
不同元件類型，項目結構是一樣的，不同的是，輸出結果的數量不同，主體函數異步傳回的内容結構有差別。
如檢查登入元件，會傳回已登入、未登入兩種情況，那主體函數會調用相應的api後，經過判斷在兩種傳回情況裡做選擇。傳回資訊branch為0，即為branch檔案對應的數組第一項的未登入的傳回情況；branch為1，即為branch檔案對應的數組第二項的已登入情況，傳回data也對應已登入的消息提示資訊。Branch檔案的數組長度即為元件輸出結果的數量，數組内容也是語義化對應的。這就是元件整體結構的設計與對應開發錄入規範，開發者根據這樣的規範即可建立對應類型的新元件。
input、output檔案的schema标準協定資料我們也提供了【可視化搭建 表單設計器】供開發者快速搭建出對應内容。
基于form-render的可視化搭建
平台嵌入了基于 form-render的表單設計器，可關聯、自定義元件快速接入，滿足多元定制化需求。考慮到form-render在 schema 的設計上，尋求合适的現有标準作為載體在其上适度擴充，經過長時間積累已經可以覆寫大部分業務場景，是以基本可以實作我們的業務訴求，即可能會有的擴充，是以選擇該schema to form方案。
技術同學可根據功能需求，通過可視化拖拽的方式搭建出配置表單；點選導出Schema，即可導出标準json schema協定資訊，這就是元件注冊環節的基礎配置資訊InputSchema協定來源，也是輸出資料outputSchema标準協定資訊來源。
提供搭建的元件市場
邏輯編排
搭建邏輯，是将元件清單中的元件拖拽至畫布中，通過具有指向性的線條将節點與節點對應連接配接起來，即可将邏輯片段組合成一條完整有始有終的邏輯。（效果展示）
通過技術手段，增添了搭建智能對齊、檢查規範、自動糾錯等能力。點選工具欄中檢查按鈕、儲存按鈕，都會根據規則對不規範搭建行為提示說明，例如元件基礎配置表單某字段不可為空；在使用者搭建過程，我們也設計了元件連接配接規則，對不規範搭建行為自動糾錯，例如元件不可閉環連接配接、不可重複連接配接等。我們建立令使用者最大化自由編排且規範化的編排器，使使用者在搭建、釋出邏輯時，已經是規範可使用的邏輯。
當然我們在設計編排器上，也将物料清單、畫布、屬性面闆，做解耦處理；每個功能面闆不會強依賴于另一個，有通用擴充卡，設定好的基礎規範與可供選擇使用的工具，也有可根據不用業務場景做定制化的闆塊。我們的初衷是，以邏輯搭建為中心，可根據實際業務場景打造不同的産品形态。
業務落地
UI & 邏輯編排結合設計
我們首個嘗試落地的業務平台也是我們團隊的活動搭建平台，與UI編排的結合嘗試。UI編排的概念：也稱為通用熱區子產品，是活動搭建平台推出的子產品生産工具，提供易用、強大的操作界面，讓營運和設計同學像制作PPT一樣制作子產品。如圖，UI編排完全可實作一個靜态頁面的搭建；使用者可任意建立熱區子產品，熱區作為一個載體可配置文字、樣式、圖檔等基礎資訊，在對應熱區綁定“動作”，動作的概念就是使用者主動點選後所觸發的一個行為，如跳轉頁面、關閉頁面、打開小程式等等。這是純UI編排搭建。
在近期的活動應用中，一個子產品使用UI編排進行了搭建嘗試。我們來看下UI編排與邏輯編排結合起來的整體設計。
在子產品中觸發邏輯分為兩種情況，一種是主動觸發邏輯，即伴随元件加載自動開始執行的邏輯。一種是被動觸發邏輯，需要使用者點選才可觸發執行的邏輯。在對應功能配置區選擇提前搭建好的邏輯即可将邏輯挂載到目前子產品。
如圖，每一條邏輯都擁有獨立上下文，邏輯執行後對應的資料産物，會存于上下文并與目前子產品共享；子產品将所有資料以key.value的格式打平，通過語義，将視圖中的熱區綁定對應字段；一旦邏輯執行過程中資料狀态發生改變，就會驅動子產品的局部UI動态渲染。若子產品的狀态綁定了對應字段，那字段資料狀态發生改變，也會驅動子產品整體UI改變。
平台側實際操作，如下圖右側，熱區選擇動作中的“邏輯編排”，二級下拉框選擇一個 從邏輯編排平台搭建好導出的邏輯。
邏輯的資料産物根據outputSchema協定可視化展示在業務平台側，對應熱區子產品可選擇/綁定對應字段内容，邏輯真正執行時，資料驅動視圖改變。
前後對比 - 優勢
從前：産品提了需求後，前端開發同學需要依賴設計稿，開始頁面開發&邏輯開發，開發完成後釋出、錄入子產品至平台側，營運同學方可配置子產品基礎資訊。
現在：在了解需求後，前端&設計可并行啟動工作了，前端同學開始開發該子產品需要依賴的邏輯元件，開發完成後産品根據需求搭建出邏輯；設計同學也可開始繪設計稿并在平台側可導入整體樣式，進而營運同學去配置基礎資訊、對應動作選擇比對的邏輯。
這樣的優點是：項目進行中，UI、邏輯的頻繁改動不會太過于依賴技術開發、技術發版，将重開發拆分為多角色輕工作快疊代； 我們從子產品複用，下沉到更小粒度的元件複用，釋放研發人員的 "搬磚" 工作。經驗證，傳統源碼開發從接到需求到上線大概需要評估2天時間，通過UI邏輯編排結合的方案僅需要2h。真正實作降本提效。并且最大的優點是做到邏輯與UI的解耦。
當UI設計稿有變動時，前後流程的對比：
純UI改動已經完全釋放開發資源，節省源碼開發 -> 代碼釋出 -> 子產品錄入/上架 -> 營運更新子產品的流程，既節省開發人力成本，營運同學通過增/删/改配置資訊也不再依賴開發。
雖然邏輯變動看似多了一個判斷步驟，但若已有可複用的邏輯元件，産品直接拖拽更新邏輯即可；無可複用元件需開發同學新開發。但長遠角度思考，我們從子產品複用，下沉到更小粒度的元件複用，元件庫不斷沉澱着邏輯，未來元件複用率一定是增長的。我們從開發角度，也在規劃從本地元件開發更新為線上開發，一鍵釋出并上架元件。讓流程編排效率更大一步提升。
結構圖
這張結構圖展示了邏輯編排與業務平台側整體上下遊關系
邏輯編排分為編排器、DSL、Runtime三部分
- 編排器基于Schema解析和G6繪圖引擎，結合對元件類型的定義注冊繪制出不同形态與功能的四種元件，供畫布搭建使用；元件是由開發者開發，且可在元件管理頁面對元件進行管理。畫布包含縮放、撤銷等工具欄功能，使用者搭建過程，我們通過技術手段提供智能對齊、檢查規範、自動糾錯、線上測試等能力，讓使用者更順滑且規範地搭建出邏輯。
- DSL 轉換器：将畫布所有資訊轉換為json，提供給業務方
- 業務平台側（活動搭建平台）邏輯的起點在主動觸發邏輯&被動觸發邏輯，一旦邏輯被觸發，由Runtime提供的api進行注冊元件，并開始執行，每一個元件的執行對應的資料産物會通過context與業務共享，一旦綁定字段對應的資料發生狀态變動，會引起局部UI變動，子產品整體狀态切換。動作執行完流轉到下一動作，如此直到邏輯結束。
這就是邏輯與UI結合的整體 / 核心思路，邏輯編排産生資料，UI編排監聽資料變化，驅動試圖改變。
總結
邏輯編排在以下三個方面做出了突破：
邏輯可複用：避免研發同學重複代碼開發，節省人力成本，實作降本提效，也使需求變動成本降低；
分工更明确：實作了UI與邏輯解耦，技術在開發環節僅開發邏輯，将重開發工作，拆分為多角色輕工作的配合。且産品搭建邏輯的同時，也将需求可視化，便于他人了解；
業務可複用：通過對元件、畫布、DSL、Rumtime的通用化、靈活性且可擴充地設計，使可适用于多業務場景。我們的規劃是，以邏輯搭建為中心，可根據實際業務場景打造不同的産品形态，希望可以服務更多平台。
以下内容你可能感興趣
邏輯編排在優酷可視化搭建中的實踐（一） - 邏輯與Runtime 優酷播放體驗優化實戰（四）--“三高”音頻渲染引擎設計 ABF平台設計（六）：微前端渲染架構-YseraMicroServer