當大家談到低代碼的時候，常常只會想到邏輯可視化的平台、UI 可視化的平台，但是低代碼還有更多的可能，我們還可以引入很多其他模塊，例如，數據處理、接口、測試、人工智能等等。今天我將基於數據處理、接口、邏輯可視化，以及 UI 可視化這四方面來展開分享，並闡述我們案例中低代碼平台中所有子平台之間是如何協作的。
低代碼可以解決哪些業務問題？
假設有這樣一個場景，當我們需要統計騰訊某遊戲業務的城市登錄人數，並且需要提供可以運營或可以檢索的頁面。
一般的開發流程是這樣的，首先將任務派發給數據開發，基於大數據的方案統計登錄人數，接着找到後台開發進行數據接口開發，然後尋找前端人員進行 Web 頁面開發。
如果基於低代碼的方案來實現，我們希望這些任務可以由一個非開發人員來獨立完成。他可以在數據平台進行數據統計，在邏輯可視化平台完成接口開發，然後在 UI 可視化平台配置界面，最後整體交付這個需求。當然，要實現上述過程，我們還有很多問題要解決。
例如，當統計每個城市的登錄人數的時候，登錄信息日誌一般只有 IP，並不會顯示城市，這使得產品人員不得不將 IP 轉換成城市，但這有很大的難度；其次，當數據平台輸出數據之後，如何將它轉換成接口？最後，即使有了接口，非開發人員還需要知道前端調用的接口參數、輸出以及對應到的 UI 等等。
上面的這一切，對於一個非技術人員來講比較困難。
這裡一共有三個問題需要解決。
首先，是否存在強大的 SQL 可以提供給用戶，這個 SQL 可以直接將 IP 轉換成城市？
其次，當有了原數據之後，是否可以直接給到接口？是否可以針對傳統的 CURD 的方法直接生成接口？
最後，當有了接口之後，UI 平台是否可以簡化，不需要進行複製粘貼。
那麼針對這三個問題，我們採用了以下這套方案。
這套方案的整體架構，包含四個部分，第一層是微服務底座，中間是邏輯可視化，再向上是數據平台，最上層是 UI 平台。所有的基底都是微服務。
這裡我們首先引入本方案中兩個比較重要的概念——元數據和 Mock。
元數據包含了數據的存儲、表、字段等元信息，大家都比較熟悉，這裡不深入闡述，但是本方案中的 Mock 與業界稍微有些不同，業界通常使用 Mock 來做開發聯調和單測。
比如，當後端的接口沒有開發完成的時候，它可以通過 Mock 將請求打到 Mock CGI，然後將返回接口傳遞過來；或者是當我們並不希望觸發真實的請求，可以在 CI/CD 里進行單測（如下圖所示）
不過這將帶來另外一個問題，那就是 Mock 如何進行收集，我們都知道，很多接口不可能都依靠人力輸出。
騰訊的方案是：首先用戶的請求作為輸入，接着經過網關，網關將 Input 傳遞到整個微服務，然後網關拿到返回結果，接着網關會把結果傳遞到客戶端，這個時候請求已經完成了。
接下來將 Input、Output 以及微服務的接口注釋，推薦給 Mocks server，Mocks server 會進行清洗，得到標準的 Mock 的數據（標準 Mock 數據包含用戶的請求方式、地址、輸入以及輸出）。
這裡會有一些性能相關的難點，採集任務不能影響微服務的性能，一些常見的解決方案已貼在上圖 Tips 中，比如，在這個網關裡面需要進行抽樣上報、增量上報以及異步上報等。
假設我們需要拉取一份數據，目前開發人員已經開發了拉取數據源的接口（接口已經部署在微服務），這時候如何生成 Mock？
首先我們通過反射拿到接口的注釋，接着拿到參數，然後通過注釋匹配。當然我們會先對這一份注釋進行清洗，然後得到字段對應中文名的 TV 對，接着嘗試匹配。如果匹配不上，它會有一個單詞庫，再次嘗試匹配，直到拿到中文名為止，最後我們會得到一個標準的 Mock 自動化的方案流程。
經過這樣一套流程，所有接口一旦經過調用，我們馬上經過自動化採集，得到了所有接口 Mock。接口的請求，參數的上傳，以及返回的結果我們都了如指掌。
那我們該如何使用這些自動採集的 Mock 數據呢？接下來一起看看低代碼的第三個問題。
首先，我們需要更強大的 SQL。
一般來講，當 SQL 無法滿足計算邏輯的時候，我們就需要找開發人員開發一個 UDF，比如一個"IP 轉城市"的函數，它會註冊到 SQL 的執行引擎，你便可以使用這個函數了。但這樣的方案是需要開發人員進行開發支持的。
低代碼的方案應該怎麼設計呢？我們提供 SQL 的方案是將微服務註冊進執行引擎，整個引擎是 Spark SQL 的引擎，它會代替開發人員發起微服務的調用，會上傳參數，然後再調度到微服務裡面。Mock 幫助人工進行了最快速的 UDF 的註冊，無需要任何成本，馬上便可以通過 SQL 調用微服務，
例如，當我們使用 SQL 調取微服務的時候，首先需要知道地址、輸入參數、以及返回值。這個接口返回 data 和 count，為什麼你接口返回城市一定是 data？這些都是一些我們在進行註冊的時候需要做的工作。
這裡有個視頻，大家可以看一下。
例如選擇一個獲取黑名單的任務，它馬上註冊微服務，這個 UDF 是一個微服務，它就可以被 SQL 使用，大家可以判斷他是不是黑名單了。
整個過程中，用戶只需要非常簡單的四個步驟，SQL 馬上就可以具備微服務的調度能力。
此處也會有一些性能上的挑戰，當使用 Spark 調用微服務的時候，性能會出現一些問題。因為如果使用非常傳統的調動方法，它是一個串行的過程，那麼我們這裡提了可以供大家參考的方案。
UDF 註冊之後，我們會直接執行 SQL，但不會馬上調用 UDF，將它標記起來，呈現出來是一個偽執行的狀態，SQL（無 UDF）產生一個中間結果，我們會將這個中間結果重新分區，把它打得更散更平均，這樣後續每個分區執行分派到的 UDF 任務個數將會更近平均，避免一些數據傾斜的情況。最後在我們偽標記的 UDF 的基礎上，我們會啟用整個的異步調度方案，使用異步 HTTP 完成微服務調用，並配套相應的緩存以及限流的策略，整體提升請求效率和成功率。
截至到這裡，我們通過 SQL+ 微服務提供了更強大的 SQL，通過了 UDF 的快速註冊，提供給產品人員非常簡潔的操作。這個時候，第一個問題就被完美地解決了。
接下來分享第二個問題的解決方案，CURD 是否還需要開發接口？
我們通過數據平台產生的數據之後，接着需要 CURD 接口。業界有很多生產 CURD 接口的方案，騰訊的 APIJSON 開源方案，它可以做到零代碼生成接口和文檔，並且整個生成過程是自動化。
當企業有元數據的時候，馬上就可以獲得接口，不過這個接口暫時不能滿足運營系統的需要。這時候需要引入規則引擎。
我們可以將接口進行簡單地編排，採用了 BPMN2.0 協議實現了同步和異步雙引擎，因此整個規則引擎可以做任務流的事情。
Mock 可以幫助整個組件的快速註冊，因為每一個節點都是微服務，這種 Mock 節點就可以快速註冊，同時整個微服務在調試的過程中，我們生成了任務工作流，當邏輯執行完之後，它也會馬上去進行 Mock 註冊。
當然，當我們有了簡單的 CURD 過程，我們可以選擇編排一些參數校驗。比如，對時間做要求、對權限做要求，當然也可以做一些錯誤返回等的編排工作，最終通過規則引擎生成完整的查詢接口。
那麼經過了這一步驟，我們就具備了 SQL 和接口，這時候可以將接口放到頁面呈現。
上圖是我們UI平台的架構，跟常規的低代碼平台大同小異，這裡介紹兩個點：通信邏輯模型和Mock加速前端配置
首先是通信邏輯模型，這個模型解決了組件與組件的通信與行為相應，當一個組件拖出來到頁面後，會馬上分配一個唯一實例 ID，每個實例都會有屬性，會有系統事件或自定義事件。
比如我們現在要實現點擊搜索按鈕後表格組件自動從後端重新獲取最新數據並呈現。
那麼，我們配置的邏輯大概是這樣的：按鈕實例的 OnClick 事件可以配置觸發表格實例的 HTTP 時事件。Table 實例的 HTTP 的事件實現拉取數據以後，將它寫進 Value 裡面，實現了整個 Table 的數據刷新輸出。
其次是 Mock 加速前端配置，有了 Mock 之後，在配置前端的時候可以省去了很多複製粘貼的工作。當我拉取一個表格，可能有很多字段，複製粘貼將會非常崩潰，這裡有 Mock server 的快捷配置以及預覽，當用戶配置完之後，便可以馬上預覽，來檢查你的配置是否和你的預期。
我們是如何通過 Mock 快速地配置？
例如，當我們配置表格的時候，地址、請求方式、上報參數、表格輸出等均需要配置。這對於一個配置人員來講，其實成本非常高的，尤其是當碰到非常極端的案例的時候，例如，當你碰到具備 20 多個字段的時候，它的配置工作將會非常令人崩潰。
我們的方案是這樣的，一起來看一下這個視頻。
首先拉取一個表格，然後選擇一個微服務地址，然後自動地獲取參數。
所有的上報參數，其返回都會全部自動填上，以及基於 Mock 的實時預覽，馬上就可以擁有。
通過使用 Mock，平台也可以透過 Mock 平台進行真實的預發布環境的預覽。
今天的主要三個挑戰都已經解決了，有了這樣方案之後，其實對於產品人員來講，可以搞定很多內容。
騰訊遊戲低代碼的整個數據平台大概支撐了 3000 個任務，後端沉澱的原子接口有 1000 個，整個邏輯可視化模板有 200 個，頁面 600 個等等。
在我們的平台上層，支撐着很多的應用。比如客服系統，大家知道王者榮耀的客服系統往往非常複雜，它會有郵件贈送福利。假設用戶 30 天沒有領取，這個郵件就會頂替掉，但是有些人會打電話投訴要求補發福利，這個時候客服需要檢查日誌去檢查是否已經領取？
這一系列流程之前都是依賴人工，但是現在當我們將平台傳遞給客服的時候，他們利用這套平台配置邏輯就可以輕鬆搞定。
當然，在平台的上層，我們也支持運維安全 SOAR 以及安全監控的一些事情。
說完我們的實踐，談談我們的展望。
今天我分享的兩個關鍵點是元數據和 Mock，我們經過這兩個元素的頻繁交互，達成了整個平台的融合。
回顧整個平台架構，我們發現平台的所有東西都是微服務，並且所有的微服務都可以變成 API 使用，整個 SQL 也變得非常的強大。整個數據平台輸出的數據都有 CURD，也貢獻回了微服務，微服務裡面的 CURD 同樣貢獻給規則引擎。這是一種相輔相成的關係。
最後一部分是關於我對低代碼未來趨勢的一些思考。現在低代碼百花齊放，有非常多的低代碼平台，業界需要一些規範，以及如何保證低代碼平台的質量。
上圖是我們整個的騰訊的低代碼架構圖。
首先，我們整個騰訊提出了一些方案——騰訊有 UI 可視化邏輯，還有 DSL 整個語言，生產環境、開發環境以後，便會有配套的前端以及後端的 SARS 的能力。整個的低代碼可以用來配置 Web 和 App，可以通過提供一些 Pass 的服務，也可以通過 Open API 或者鈎子做很多事情。
當然這裡介紹兩個執行引擎。作為低代碼，我們有一個基於 Schema 的解析引擎和編譯引擎。解釋引擎可以用 Schema 直接執行，編譯引擎更多是從性能角度考慮。編輯引擎可以根據 Schema 轉成可運行的代碼，希望大家可以了解一下。
其次，再談一下 Schema 與 DSL 的這樣關係，DSL 可以通過 Pass 模塊轉換成 Schema，Schema 是可以被解釋引擎和編譯引擎識別的。在面向用戶的使用方式上，我們支持整個可視化編輯，也就是說，大家可以在頁面進行拖拉拽。當然如果你不喜歡，也可以無風險、無損失地切換到 DSL。
最後，對於一些中小企業來說，當企業選擇了低碼平台時候，便馬上會被這個平台綁架。因為企業的所有邏輯全部配置在了低代碼平台，由於其他平台無法識別 Schema，所以根本無法遷移。
目前騰訊低代碼提出了一個思想——Schema 可以不一樣，因為不同的執行引擎或編譯引擎是不同的，它們的 schema 規範必然也不一樣。但是 DSL 是更上層的語言，就是大部分數據都支持標準的 SQL 一樣，我們可以抽象 DSL，站在整個低代碼的行業的角度與立場去抽象 DSL。在我的平台裡面剛才我們講了，其實 Schema 是可以轉 DSL 的，當他真正地想從平台導出的時候，它其實就可以把 Schema 轉成 DSL 打包帶走，然後在另外一個平台裡面導入。
我相信如果大家都這樣做，低代碼綁架業務的問題就迎刃而解，整個低代碼的生態會變得更加健康。
這是我今天的分享，謝謝大家。
嘉賓介紹：
葉鑫林，騰訊 IEG/ 公共數據平台部 / 基礎數據平台中心 / 數據產品開發組負責人、騰訊低碼 OTeam PMC。多年大數據開發、前後端開發、算法設計經驗，熟悉遊戲領域的研發環境，主導了多款平台類產品（光譜、天眼、規則引擎、數據平台等）的設計與研發。目前帶領團隊投入低碼平台的研發建設，致力提升易用性與研發效率。
在 4 月 24-25 日，ArchSummit 全球架構師峰會即將落地上海，數字化轉型是大趨勢，不管是金融轉型，還是汽車產業數字化轉型，製造業數字化轉型，一定會涉及到企業的產品形態，這裡面包括市場定位和可行性的諸多因素，還有 ROI 評估模型。
除了在業務上的轉型，在技術上也需要底層技術支持，例如微服務架構實踐，數據庫管理，前端開發，質量提升等等，共同保證項目落地。基於這些需求，ArchSummit 架構師峰會上邀請了國內較有經驗的專家來分享各自的案例，幫助大家少踩坑，多復用，快速解決工作中的問題，了解更多請點擊閱讀原文或掃描下方二維碼即可參與。
點個在看少個 bug👇
留言列表