本文連結：https://juejin.cn/post/6899262277459902472

前言

為應對軟體危機，誕生了軟體工程，以期望其達到降低軟體生產成本 、改進軟體產品質量、提高軟體生產率水平的目標。自上個世紀 60 年代以來，從模組化、面向物件設計到設計模式，從瀑布流模型到敏捷開發，dev-ops, 軟體生產的指導理論和工程方法都在不斷進步，軟體的生產效率有了很大改善。然而直到今天，業務需求的增長和企業開發資源緊缺的矛盾依然廣泛存在。

與此同時, 近年來 no-code/low-code 的理念得到越來越多的國內外企業的重視，各類零程式碼、低程式碼開發平臺層出不窮。據 Gartner 的研究預測，到 2024 年低程式碼平臺將被應用於 65% 的應用程式開發。儘管它也不是解決所有問題的 “銀彈”, 但是低程式碼作為一個趨勢，代表了業界向自動化編碼邁進了重要的一步，在 AI 程式設計變得普適之前，低程式碼能夠大幅提升業務交付效率。

本文結合愛奇藝 App 後端在業務資料同步方面的實踐，分享基於低程式碼平臺高效交付業務需求及避免重複開發的經驗。

Part 01

業務背景

首先以移動端為例，我們先簡單回顧下業務資料在呈現給使用者之前普遍會經歷的大致過程：

· 資料生產後臺: 運營人員或者自動化程式透過業務生產後臺將資料生產出來。比如編輯或者使用者釋出的文章、上傳的影片，或者爬蟲程式自動抓取網路上的資源，資料生產後臺將這些資料存放的資料庫中，並提供讀取服務供下游業務獲取資料。當資料發生修改後，透過訊息通知下游更新資料；

·**資料同步：**業務部門透過資料同步服務將生產後臺產生的資料進行轉換、聚合等加工處理，寫入到資料庫和分散式快取裡；

· 資料庫 & 快取: 儲存各類業務資料供業務後端介面讀取；

·**後端介面：**接受 App 前端的請求，從快取、資料庫以及第三方介面讀取各類業務資料，按業務需要進行各種組裝處理。

·**App 前端：**請求後端介面並解析返回的資料，並在裝置上進行渲染呈現給使用者。

出於整體組織效率考慮，一般來說，資料生產部門主要專注於資料生產的場景，對於資料最終如何使用無需過多專注。而實際通常來說，最終呈現給使用者的資料是豐富多樣的，這通常意味著我們需要聚合不同生產方的資料，出於效能上的考慮，這種聚合完全交由後端介面在響應使用者請求時實時訪問多方資料來源介面來聚合是不現實的。同時面向使用者的業務往往併發流量較高，基於高併發以及高可用的需要，資料往往會儲存在不同的資料庫中介軟體裡並保持一致性。基於這樣的背景，資料同步服務承擔了資料從生產側交付給消費側的橋樑角色，這使得生產部門能更加專注於內容生產環節的迭代，而消費側 (一般是後臺介面) 專注於如何快速交付業務介面以及保證服務介面的高效能和高可用。

Part 02

挑戰

在業務早期，資料同步處理的資料型別和資料量不算太高，這種模式下各個部分職責劃分也比較清晰，各個業務環節迭代都比較高效。然而隨著業務不斷髮展，需求場景不斷豐富，逐漸出現了一些問題。主要表現為：

**迭代週期緊迫，專案質量難以保證：**由於業務需求對底層資料依賴關係通常並不能直觀的識別出來，這造成了產品同學在交付需求文稿時容易遺漏對資料層的分析，甚至業務開發同學在早期需求評估階段也無法準確識別出對哪些基礎資料有依賴，這導致在版本臨近交付時才能識別出底層資料的需求依賴, 這就意味著留給資料同步環節的開發時間非常緊迫。同時這個節點測試團隊的排期也已經確定了，測試資源往往不能充分保證，這些因素對專案質量帶來了一定的風險。比如，有時為了快速交付業務需求，會直接在原有程式裡新整合業務上不關聯的新需求，從而在不同業務之間形成了不必要的耦合，為專案後期維護增加了風險和複雜度。

**儲存中介軟體的管理維護成本增加：**資料同步模組負責將各類業務資料到落地儲存中介軟體，而下游眾多的業務介面需要訪問這些中介軟體來獲取資料，這使得介面需要了解資料儲存的細節。一旦需要調整儲存方案 (比如中介軟體依賴的虛機要下線維護, 需要遷移叢集)，除了遷移存量資料，資料同步模組和眾多業務介面均需要調整，而調整的第一步，僅僅確認幾十個專案裡哪些需要調整的工作量就不容小覷，更不用說進而再製定並實施跨越眾多專案的協同遷移計劃。為此我們開發了一些基礎資料介面和封裝資料訪問的 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/%E8%BD%AF%E4%BB%B6%E5%8D%B1%E6%9C%BA/564526?fr=aladdin

本文連結：https://juejin.cn/post/6899262277459902472