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