低代碼在愛(ài)奇藝鵲橋數(shù)據(jù)同步平臺(tái)的實(shí)踐
本文作者：愛(ài)奇藝技術(shù)
本文鏈接：https://juejin.cn/post/6899262277459902472
前言
為應(yīng)對(duì)軟件危機(jī)，誕生了軟件工程，以期望其達(dá)到降低軟件生產(chǎn)成本 、改進(jìn)軟件產(chǎn)品質(zhì)量、提高軟件生產(chǎn)率水平的目標(biāo)。自上個(gè)世紀(jì) 60 年代以來(lái)，從模塊化、面向?qū)ο笤O(shè)計(jì)到設(shè)計(jì)模式，從瀑布流模型到敏捷開(kāi)發(fā)，dev-ops, 軟件生產(chǎn)的指導(dǎo)理論和工程方法都在不斷進(jìn)步，軟件的生產(chǎn)效率有了很大改善。然而直到今天，業(yè)務(wù)需求的增長(zhǎng)和企業(yè)開(kāi)發(fā)資源緊缺的矛盾依然廣泛存在。
與此同時(shí), 近年來(lái) no-code/low-code 的理念得到越來(lái)越多的國(guó)內(nèi)外企業(yè)的重視，各類零代碼、低代碼開(kāi)發(fā)平臺(tái)層出不窮。據(jù) Gartner 的研究預(yù)測(cè)，到 2024 年低代碼平臺(tái)將被應(yīng)用于 65% 的應(yīng)用程序開(kāi)發(fā)。盡管它也不是解決所有問(wèn)題的 “銀彈”, 但是低代碼作為一個(gè)趨勢(shì)，代表了業(yè)界向自動(dòng)化編碼邁進(jìn)了重要的一步，在 AI 編程變得普適之前，低代碼能夠大幅提升業(yè)務(wù)交付效率。
本文結(jié)合愛(ài)奇藝 App 后端在業(yè)務(wù)數(shù)據(jù)同步方面的實(shí)踐，分享基于低代碼平臺(tái)高效交付業(yè)務(wù)需求及避免重復(fù)開(kāi)發(fā)的經(jīng)驗(yàn)。
Part 01
業(yè)務(wù)背景
首先以移動(dòng)端為例，我們先簡(jiǎn)單回顧下業(yè)務(wù)數(shù)據(jù)在呈現(xiàn)給用戶之前普遍會(huì)經(jīng)歷的大致過(guò)程：
· 數(shù)據(jù)生產(chǎn)后臺(tái): 運(yùn)營(yíng)人員或者自動(dòng)化程序通過(guò)業(yè)務(wù)生產(chǎn)后臺(tái)將數(shù)據(jù)生產(chǎn)出來(lái)。比如編輯或者用戶發(fā)布的文章、上傳的視頻，或者爬蟲(chóng)程序自動(dòng)抓取網(wǎng)絡(luò)上的資源，數(shù)據(jù)生產(chǎn)后臺(tái)將這些數(shù)據(jù)存放的數(shù)據(jù)庫(kù)中，并提供讀取服務(wù)供下游業(yè)務(wù)獲取數(shù)據(jù)。當(dāng)數(shù)據(jù)發(fā)生修改后，通過(guò)消息通知下游更新數(shù)據(jù)；
·**數(shù)據(jù)同步：**業(yè)務(wù)部門通過(guò)數(shù)據(jù)同步服務(wù)將生產(chǎn)后臺(tái)產(chǎn)生的數(shù)據(jù)進(jìn)行轉(zhuǎn)換、聚合等加工處理，寫(xiě)入到數(shù)據(jù)庫(kù)和分布式緩存里；
· 數(shù)據(jù)庫(kù) & 緩存: 存儲(chǔ)各類業(yè)務(wù)數(shù)據(jù)供業(yè)務(wù)后端接口讀取；
·**后端接口：**接受 App 前端的請(qǐng)求，從緩存、數(shù)據(jù)庫(kù)以及第三方接口讀取各類業(yè)務(wù)數(shù)據(jù)，按業(yè)務(wù)需要進(jìn)行各種組裝處理。
·**App 前端：**請(qǐng)求后端接口并解析返回的數(shù)據(jù)，并在設(shè)備上進(jìn)行渲染呈現(xiàn)給用戶。
出于整體組織效率考慮，一般來(lái)說(shuō)，數(shù)據(jù)生產(chǎn)部門主要專注于數(shù)據(jù)生產(chǎn)的場(chǎng)景，對(duì)于數(shù)據(jù)最終如何使用無(wú)需過(guò)多專注。而實(shí)際通常來(lái)說(shuō)，最終呈現(xiàn)給用戶的數(shù)據(jù)是豐富多樣的，這通常意味著我們需要聚合不同生產(chǎn)方的數(shù)據(jù)，出于性能上的考慮，這種聚合完全交由后端接口在響應(yīng)用戶請(qǐng)求時(shí)實(shí)時(shí)訪問(wèn)多方數(shù)據(jù)源接口來(lái)聚合是不現(xiàn)實(shí)的。同時(shí)面向用戶的業(yè)務(wù)往往并發(fā)流量較高，基于高并發(fā)以及高可用的需要，數(shù)據(jù)往往會(huì)存儲(chǔ)在不同的數(shù)據(jù)庫(kù)中間件里并保持一致性。基于這樣的背景，數(shù)據(jù)同步服務(wù)承擔(dān)了數(shù)據(jù)從生產(chǎn)側(cè)交付給消費(fèi)側(cè)的橋梁角色，這使得生產(chǎn)部門能更加專注于內(nèi)容生產(chǎn)環(huán)節(jié)的迭代，而消費(fèi)側(cè) (一般是后臺(tái)接口) 專注于如何快速交付業(yè)務(wù)接口以及保證服務(wù)接口的高性能和高可用。
Part 02
挑戰(zhàn)
在業(yè)務(wù)早期，數(shù)據(jù)同步處理的數(shù)據(jù)類型和數(shù)據(jù)量不算太高，這種模式下各個(gè)部分職責(zé)劃分也比較清晰，各個(gè)業(yè)務(wù)環(huán)節(jié)迭代都比較高效。然而隨著業(yè)務(wù)不斷發(fā)展，需求場(chǎng)景不斷豐富，逐漸出現(xiàn)了一些問(wèn)題。主要表現(xiàn)為：
**人力瓶頸：**數(shù)據(jù)同步模塊承載的業(yè)務(wù)數(shù)量來(lái)源越來(lái)越多, 光就本人所在團(tuán)隊(duì)來(lái)說(shuō)目前已經(jīng)有 30 數(shù)據(jù)同步業(yè)務(wù)，而絕大部分業(yè)務(wù)需求的都需要對(duì)底層數(shù)據(jù)進(jìn)行調(diào)整，數(shù)據(jù)同步環(huán)節(jié)的開(kāi)發(fā)人力逐漸成為瓶頸;
**迭代周期緊迫，項(xiàng)目質(zhì)量難以保證：**由于業(yè)務(wù)需求對(duì)底層數(shù)據(jù)依賴關(guān)系通常并不能直觀的識(shí)別出來(lái)，這造成了產(chǎn)品同學(xué)在交付需求文稿時(shí)容易遺漏對(duì)數(shù)據(jù)層的分析，甚至業(yè)務(wù)開(kāi)發(fā)同學(xué)在早期需求評(píng)估階段也無(wú)法準(zhǔn)確識(shí)別出對(duì)哪些基礎(chǔ)數(shù)據(jù)有依賴，這導(dǎo)致在版本臨近交付時(shí)才能識(shí)別出底層數(shù)據(jù)的需求依賴, 這就意味著留給數(shù)據(jù)同步環(huán)節(jié)的開(kāi)發(fā)時(shí)間非常緊迫。同時(shí)這個(gè)節(jié)點(diǎn)測(cè)試團(tuán)隊(duì)的排期也已經(jīng)確定了，測(cè)試資源往往不能充分保證，這些因素對(duì)項(xiàng)目質(zhì)量帶來(lái)了一定的風(fēng)險(xiǎn)。比如，有時(shí)為了快速交付業(yè)務(wù)需求，會(huì)直接在原有程序里新集成業(yè)務(wù)上不關(guān)聯(lián)的新需求，從而在不同業(yè)務(wù)之間形成了不必要的耦合，為項(xiàng)目后期維護(hù)增加了風(fēng)險(xiǎn)和復(fù)雜度。
**存儲(chǔ)中間件的管理維護(hù)成本增加：**數(shù)據(jù)同步模塊負(fù)責(zé)將各類業(yè)務(wù)數(shù)據(jù)到落地存儲(chǔ)中間件，而下游眾多的業(yè)務(wù)接口需要訪問(wèn)這些中間件來(lái)獲取數(shù)據(jù)，這使得接口需要了解數(shù)據(jù)存儲(chǔ)的細(xì)節(jié)。一旦需要調(diào)整存儲(chǔ)方案 (比如中間件依賴的虛機(jī)要下線維護(hù), 需要遷移集群)，除了遷移存量數(shù)據(jù)，數(shù)據(jù)同步模塊和眾多業(yè)務(wù)接口均需要調(diào)整，而調(diào)整的第一步，僅僅確認(rèn)幾十個(gè)項(xiàng)目里哪些需要調(diào)整的工作量就不容小覷，更不用說(shuō)進(jìn)而再制定并實(shí)施跨越眾多項(xiàng)目的協(xié)同遷移計(jì)劃。為此我們開(kāi)發(fā)了一些基礎(chǔ)數(shù)據(jù)接口和封裝數(shù)據(jù)訪問(wèn)的 sdk, 這在一定程度上解決了問(wèn)題, 但另一方面也新增加了基礎(chǔ)數(shù)據(jù)接口和相關(guān) sdk 的維護(hù)成本。
**重復(fù)編碼的場(chǎng)景較多：**比如，每一個(gè)同步業(yè)務(wù)需要開(kāi)發(fā)監(jiān)聽(tīng)消息隊(duì)列，訪問(wèn)生產(chǎn)方接口的代碼，同時(shí)非業(yè)務(wù)必要能力開(kāi)發(fā)比如重試、限流、監(jiān)控等，在每個(gè)具體業(yè)務(wù)都需要實(shí)現(xiàn)。對(duì)這個(gè)問(wèn)題，我們一度寄希望于通用的同步模板項(xiàng)目來(lái)解決。但實(shí)踐下來(lái)，模板的通用性和業(yè)務(wù)的多樣性之間存在矛盾，同時(shí)每個(gè)業(yè)務(wù)仍然需要?jiǎng)?chuàng)建項(xiàng)目開(kāi)發(fā)、測(cè)試代碼，仍然有較高維護(hù)成本。放眼整個(gè)公司，還有很多兄弟團(tuán)隊(duì)也有大量類似的場(chǎng)景，比如 pc 端，h5 端和我們可能都依賴相同的上游生產(chǎn)方，存在大量相同場(chǎng)景的重復(fù)實(shí)現(xiàn)，這種情況下如何避免重復(fù)開(kāi)發(fā)呢？
Part 03
方案調(diào)研
基于上述這些問(wèn)題，我們希望尋求維護(hù)成本更低、開(kāi)發(fā)效率更高的解決方案。為此我們對(duì)數(shù)據(jù)同步相關(guān)產(chǎn)品進(jìn)行了調(diào)研，結(jié)果發(fā)現(xiàn)大部分都是面向異構(gòu)數(shù)據(jù)庫(kù)的同步，或者只能支持批處理任務(wù)，抑或不能方便擴(kuò)展訪問(wèn)外部接口, 綜合下來(lái)并沒(méi)有發(fā)現(xiàn)能較好適配我們業(yè)務(wù)場(chǎng)景的。當(dāng)然調(diào)研的這些產(chǎn)品很多特性為我們提供了重要的參考，比如 dataX 的插件機(jī)制和 Spring Cloud Data Flow 的編排能力給了我們很多啟發(fā)。
在后續(xù)的調(diào)研中，近年來(lái)逐漸興起的低代碼開(kāi)發(fā)平臺(tái)方案走進(jìn)了我們的視野。低代碼開(kāi)發(fā)平臺(tái)是無(wú)需編碼（0 代碼或無(wú)代碼）或通過(guò)少量代碼就可以快速生成應(yīng)用程序的開(kāi)發(fā)平臺(tái)。它允許終端用戶使用易于理解的可視化工具開(kāi)發(fā)自己的應(yīng)用程序，而不是傳統(tǒng)的編寫(xiě)代碼方式。構(gòu)建業(yè)務(wù)流程、邏輯和數(shù)據(jù)模型等所需的功能，必要時(shí)還可以添加自己的代碼。完成業(yè)務(wù)邏輯、功能構(gòu)建后，即可一鍵交付應(yīng)用并進(jìn)行更新。
結(jié)合我們的業(yè)務(wù)遇到的問(wèn)題，我們期望通過(guò)低代碼平臺(tái)以較低成本實(shí)現(xiàn)如下目標(biāo)：
**1. 快速交付能力。**能夠通過(guò)可視化編排來(lái)快速實(shí)現(xiàn)業(yè)務(wù)邏輯。
**2. 避免重復(fù)開(kāi)發(fā)。**這里有三層含義：
（1）功能單元復(fù)用：同樣的功能，無(wú)論是中間件的訪問(wèn)，還是某些業(yè)務(wù)接口的訪問(wèn)， 只需要開(kāi)發(fā)一次即可，新的業(yè)務(wù)需求里如果有相同的場(chǎng)景，比如訪問(wèn)同一個(gè)公共訪問(wèn)的接口，能夠直接復(fù)用之前的工作；
（2）業(yè)務(wù)場(chǎng)景復(fù)用：不同業(yè)務(wù)團(tuán)隊(duì)有類似的業(yè)務(wù)場(chǎng)景時(shí)，可以快速移植，只需要調(diào)整少量參數(shù)即可實(shí)現(xiàn)；
（3）CI 流程復(fù)用：所有業(yè)務(wù)的開(kāi)發(fā)和上線能夠復(fù)用相同的構(gòu)建、部署流程，從而降低維護(hù)成本。
**3. 能夠靈活擴(kuò)展。**比如使用到之前未支持的中間件，需要能夠方便的集成到已有的功能體系里來(lái), 并且能在后續(xù)業(yè)務(wù)里復(fù)用。
**4. 高可用。**穩(wěn)定性是業(yè)務(wù)的基石, 對(duì)數(shù)據(jù)同步來(lái)說(shuō)，異常重試、限流、監(jiān)控、告警等基礎(chǔ)能力必不可少。
5. 方便查看業(yè)務(wù)對(duì)中間件的依賴**。**比如能查看一組 redis 集群被哪些業(yè)務(wù)使用，一個(gè)業(yè)務(wù)使用了哪些中間件資源，方便后期的維護(hù)。
Part 04
愛(ài)奇藝鵲橋平臺(tái)介紹
基于前文所述背景，鵲橋平臺(tái)的設(shè)計(jì)思想主要是：
·封裝可復(fù)用的邏輯節(jié)點(diǎn), 通過(guò)對(duì)這些邏輯節(jié)點(diǎn)可視化的進(jìn)行編排快速落地業(yè)務(wù)流程；
·通過(guò)平臺(tái)化復(fù)用基礎(chǔ)能力；一次開(kāi)發(fā)，所有業(yè)務(wù)應(yīng)用都受益。
例如可以將消息消費(fèi)，消息實(shí)體解析和特定接口的讀取分別封裝成可以復(fù)用的邏輯節(jié)點(diǎn)，在實(shí)現(xiàn)業(yè)務(wù)邏輯時(shí)，只需要將這些邏輯節(jié)點(diǎn)進(jìn)行組合串聯(lián)即可。在運(yùn)行階段，數(shù)據(jù)在每個(gè)邏輯節(jié)點(diǎn)被加工處理并按順序向下游傳遞，也可以根據(jù)業(yè)務(wù)需要增加判斷分支，這樣業(yè)務(wù)可以通過(guò)類似畫(huà)流程圖的方式快速交付。
如上圖所示，鵲橋主要有管理后臺(tái)和同步引擎兩個(gè)部分組成。管理后臺(tái)供業(yè)務(wù)開(kāi)發(fā)同學(xué)完成業(yè)務(wù)邏輯的編排和發(fā)布。主要功能有：
- 操作簡(jiǎn)單，提供了可視化的業(yè)務(wù)編輯器，可以通過(guò)拖拽的方式完成業(yè)務(wù)開(kāi)發(fā)；業(yè)務(wù)編排完成并發(fā)布后，會(huì)生成業(yè)務(wù)描述配置信息并存入云配置中心后續(xù)供同步引擎使用；如下圖所示為業(yè)務(wù)開(kāi)發(fā)的編輯器，最左側(cè)是各自邏輯插件的列表，可以直接拖到中間的畫(huà)布上組合形成完整的業(yè)務(wù)處理流程。通過(guò)右側(cè)的屬性配置表單可以為每個(gè)邏輯節(jié)點(diǎn)指定業(yè)務(wù)相關(guān)的配置參數(shù)，比如限流配置，重試配置，關(guān)聯(lián)服務(wù)授權(quán)信息等。
- 提供實(shí)體映射模板管理功能。映射模板描述了如何將一個(gè) json 數(shù)據(jù)轉(zhuǎn)換為業(yè)務(wù)需要的數(shù)據(jù)，開(kāi)發(fā)同學(xué)可以在后臺(tái)對(duì)模板進(jìn)行調(diào)試。可以通過(guò)實(shí)體轉(zhuǎn)換邏輯節(jié)點(diǎn)按照映射模板來(lái)完成字段的轉(zhuǎn)換。后期新增和修改字段邏輯時(shí)，只需要調(diào)整模板重新發(fā)布即可生效，不用再拉分支修改代碼，從而更加快速的完成需求交付。當(dāng)前線上已經(jīng)發(fā)生多次 10 分鐘內(nèi)交付業(yè)務(wù)需求的案例。
- 提供邏輯節(jié)點(diǎn)插件管理。擴(kuò)展插件實(shí)現(xiàn)約定的編程接口并在后臺(tái)里導(dǎo)入后，就可以在業(yè)務(wù)編輯器里使用。需要指定插件所在的倉(cāng)庫(kù)坐標(biāo)、邏輯實(shí)現(xiàn)類全路徑名，同時(shí)在錄入時(shí)可以定義插件的屬性配置表單。一般數(shù)據(jù)同步業(yè)務(wù)都是后端開(kāi)發(fā)同學(xué)來(lái)完成，后端一般比較熟悉相關(guān)業(yè)務(wù)邏輯，相對(duì)來(lái)說(shuō)完成插件后臺(tái)的邏輯擴(kuò)展不存在門檻，但是由于需要將邏輯插件和可視化編輯器進(jìn)行集成，涉及到前端頁(yè)面的開(kāi)發(fā)，這往往是后端同學(xué)不熟悉的領(lǐng)域。為了避免后端同學(xué)學(xué)習(xí)前端的成本，我們將屬性表單的生成做成了拖拽式的，無(wú)需前端技術(shù)基礎(chǔ)也可以快速完成表單的開(kāi)發(fā)。
- 中間件資源的管理。可以將業(yè)務(wù)需要的中間件資源導(dǎo)入后臺(tái)，之后在開(kāi)發(fā)業(yè)務(wù)時(shí)，可以在對(duì)應(yīng)邏輯節(jié)點(diǎn)的屬性配置表單里通過(guò)下拉框選擇到。同時(shí)平臺(tái)自動(dòng)維護(hù)了業(yè)務(wù)和中間件的依賴關(guān)系。
- 管理后臺(tái)和公司相關(guān)基礎(chǔ)支持平臺(tái)打通，最大限度的避免重復(fù)性人工流程。比如和應(yīng)用運(yùn)維平臺(tái)打通實(shí)現(xiàn)一鍵部署；和日志平臺(tái)打通，自動(dòng)完成業(yè)務(wù)日志的投遞；和監(jiān)控告警平臺(tái)打通，業(yè)務(wù)應(yīng)用創(chuàng)建后自動(dòng)注冊(cè)到監(jiān)控告警平臺(tái)。
同步引擎完成對(duì)數(shù)據(jù)的處理。首先在應(yīng)用構(gòu)建階段會(huì)基于業(yè)務(wù)配置分析當(dāng)前需要使用的的邏輯節(jié)點(diǎn)插件列表并將列表內(nèi)的插件和引擎核心模塊一起打包；應(yīng)用部署后，引擎在啟動(dòng)階段會(huì)加載配置中心的業(yè)務(wù)配置，完成中間件資源訪問(wèn)的初始化，并邏輯節(jié)點(diǎn)進(jìn)行初始化，這一步主要是加載業(yè)務(wù)配置里為每個(gè)邏輯節(jié)點(diǎn)實(shí)例設(shè)置的配置參數(shù)，并執(zhí)行插件實(shí)現(xiàn)的初始化邏輯。初始化正常結(jié)束之后，引擎將進(jìn)入運(yùn)行階段，開(kāi)始處理線上數(shù)據(jù)。數(shù)據(jù)從起始節(jié)點(diǎn)進(jìn)入業(yè)務(wù)流程后，依次執(zhí)行各個(gè)邏輯節(jié)點(diǎn)。引擎在運(yùn)行過(guò)程中會(huì)定時(shí)上報(bào)心跳給監(jiān)測(cè)服務(wù)，一旦心跳超時(shí)，會(huì)觸發(fā)告警通知業(yè)務(wù)開(kāi)發(fā)同學(xué)及時(shí)處理。而業(yè)務(wù)指標(biāo) (比如 tps、成功率、耗時(shí))) 的監(jiān)控?cái)?shù)據(jù)則會(huì)投遞給監(jiān)控系統(tǒng)。
如上所述，管理后臺(tái)面向開(kāi)發(fā)人員提供業(yè)務(wù)開(kāi)發(fā)維護(hù)能力，同步引擎負(fù)責(zé)解釋和執(zhí)行編排好的業(yè)務(wù)邏輯。業(yè)務(wù)同學(xué)無(wú)需再針對(duì)每個(gè)業(yè)務(wù)需求都按照常規(guī)方式 “拉分支 à 修改代碼 à 提測(cè) à 上線” 的流程, 只需要簡(jiǎn)單拖拽和配置即可，業(yè)務(wù)交付效率大大提升。同時(shí)穩(wěn)定相關(guān)的基礎(chǔ)能力已經(jīng)通過(guò)平臺(tái)化進(jìn)行了沉淀和復(fù)用，在保證業(yè)務(wù)穩(wěn)定的同時(shí)降低了維護(hù)成本。
自愛(ài)奇藝鵲橋平臺(tái)上線以來(lái)，目前已經(jīng)承載了近 20 個(gè)數(shù)據(jù)同步業(yè)務(wù)，30 應(yīng)用實(shí)例，集成了 30 業(yè)務(wù)邏輯節(jié)點(diǎn)。為相關(guān)業(yè)務(wù)的快速迭代提供了穩(wěn)定支撐。后續(xù)我們會(huì)將存量的同步業(yè)務(wù)移植到該平臺(tái)來(lái)降低維護(hù)成本。
總結(jié) & 展望
本文主要介紹了鵲橋平臺(tái)的主要功能，就目前來(lái)說(shuō)鵲橋?qū)鹘y(tǒng)方式小時(shí)級(jí)到天級(jí)的開(kāi)發(fā)耗時(shí)縮短到分鐘級(jí)，極大提升了開(kāi)發(fā)效率；同時(shí)開(kāi)箱即用的高可用能力保證了業(yè)務(wù)的穩(wěn)定性。
后續(xù)我們考慮從如下幾個(gè)方向繼續(xù)優(yōu)化迭代：
- 進(jìn)一步提供數(shù)據(jù)訪問(wèn)層服務(wù)代碼的自動(dòng)生成，進(jìn)一步降低開(kāi)發(fā)成本；
- 支持在私有云平臺(tái)上部署以為更多的業(yè)務(wù)團(tuán)隊(duì)賦能；
- 結(jié)合平臺(tái)形成公司內(nèi)部的業(yè)務(wù)數(shù)據(jù)集市，避免不同業(yè)務(wù)團(tuán)隊(duì)間的重復(fù)開(kāi)發(fā)。
參考文獻(xiàn)：
**1.**The Rise of No/Low Code Software Development—No Experience Needed?
**2.** https://zhuanlan.zhihu.com/p/128581398
**3.**https://baike.baidu.com/item/軟件危機(jī)/564526?fr=aladdin
本文作者：愛(ài)奇藝技術(shù)
本文鏈接：https://juejin.cn/post/6899262277459902472
