導讀：

據(jù)Gartner調研，應用開發(fā)需求的市場增長至少超過IT交付能力的5倍，預計到2025年，70%的新應用開發(fā)將使用低代碼技術。我們需要在需求迭代越來越高頻、創(chuàng)新能力要求越來越高的背景下，探索如何通過技術手段為業(yè)務開發(fā)降本增效提質做出突破，更高效的實現(xiàn)產品創(chuàng)新。百度搜索中臺支撐多元業(yè)務場景，有豐富的業(yè)務形態(tài)，對卓越效能有極致追求。本文從搜索中臺業(yè)務研發(fā)者面臨的困難和挑戰(zhàn)入手，分析原因，探討低代碼的一些解決思路。

全文5988字，預計閱讀時間15分鐘

一、關于低代碼

低代碼是軟件系統(tǒng)的快速開發(fā)工具，開發(fā)者無需編碼就可以實現(xiàn)常見的功能、少量代碼即可完成功能擴展，從而實現(xiàn)便捷構建應用程序。隨著企業(yè)數(shù)字化需求的快速增長，傳統(tǒng)的軟件開發(fā)方式的低下生產效率，成為制約企業(yè)數(shù)字化轉型的主要矛盾，低代碼得到快速發(fā)展。相比傳統(tǒng)的軟件開發(fā)模式和工具，低代碼的開發(fā)門檻更低、研發(fā)效率更高；相比其他的快速開發(fā)工具，低代碼的擴展性更高，可以勝任復雜場景下的核心開發(fā)訴求。研發(fā)效能也一直是各大互聯(lián)網(wǎng)企業(yè)關注的焦點，隨著近幾年的探索和發(fā)展，市場上出現(xiàn)了眾多的低代碼平臺，低代碼也受到了越來越多的關注。

目前業(yè)界低代碼框架主要解決的是一般領域的通用需求，可以低成本的拖拽組件來打造前后端一體的應用，主要用于 BRM（業(yè)務規(guī)則管理）、ERP、CRM等系統(tǒng)的快速研發(fā)。但是這種方式對專業(yè)領域的中后臺開發(fā)者并不適用，他們面對的是復雜多樣的場景，他們專注的問題是如何維護已經(jīng)達到十萬、甚至百萬的代碼，如何快速迭代、策略優(yōu)化實現(xiàn)業(yè)務可持續(xù)增長，如何治理與保障服務的穩(wěn)定性等等。如果低代碼工具只能創(chuàng)建帶界面的數(shù)據(jù)庫應用，支持簡單工作流場景，并不能給后者帶來實際幫助。

搜索中臺從業(yè)務場景和業(yè)務痛點出發(fā)，借鑒業(yè)界低代碼理念，對復雜的后端系統(tǒng)開展了低代碼探索和實踐之路。工欲善其事，必先利其器，希望通過打造新的生產力工具，更高效地實現(xiàn)產品創(chuàng)新。

二、我們面對的場景

搜索中臺為業(yè)務提供兩種接入方式，一種是使用者以配置化的形式進行定制，之后使用提供的API接口訪問中臺的能力，另一種是允許使用者以代碼開發(fā)、部署服務的形式在中臺內部系統(tǒng)中進行定制，實現(xiàn)高度靈活的產品邏輯。前者更加接近“無代碼”，但是擴展性和靈活性不夠，應對的是一般性需求，后者我們在中臺系統(tǒng)內提供了應用引擎（以下稱Search-AE），業(yè)務可以直接入場開發(fā)，通過代碼實現(xiàn)檢索需求定制，滿足更加靈活的業(yè)務場景。

隨著深耕業(yè)務場景的規(guī)模爆發(fā)式增長，大量應用開始涌入 Search-AE，目前已經(jīng)包含了200 獨立業(yè)務系統(tǒng)。在需求高速迭代、規(guī)模快速增長的情況下，效能上面臨的問題也越發(fā)凸顯：

• 缺少有效沉淀

  在 Search-AE 發(fā)展之初，各個業(yè)務更多的是縱向發(fā)展，通用功能很難沉淀，應用之間的能力共享主要通過 copy-paste 來完成，而這些代碼在一段時間的迭代后，又會因為一些微不同導致其往各自的方向發(fā)展，最終業(yè)務之間完全演變成各自獨立的系統(tǒng)，本可以復用的能力變的更加難以有效沉淀。

• 高速迭代下系統(tǒng)的復雜性加大

  隨著需求的快速迭代，業(yè)務系統(tǒng)的代碼量和架構復雜度也在快速提升，部分業(yè)務代碼量級已經(jīng)發(fā)展到數(shù)十萬級別的規(guī)模。同時業(yè)務需求又是第一位的，大家都在被需求推著走，開發(fā)過程中很難保證對文檔做出有效沉淀。接手同學在維護迭代時只能通過大量源碼去理解系統(tǒng)，難以保證高效開發(fā)。

• 研發(fā)全流程操作繁瑣

  搜索本身很復雜，尤其在經(jīng)歷過多年的發(fā)展后，搜索系統(tǒng)成為鏈路長、連接復雜的大型分布式系統(tǒng)。環(huán)境部署、調試預覽等都會對業(yè)務研發(fā)產生一定的負擔。另一方面，研發(fā)全流程需要接觸不同的工具平臺，這些平臺沒有從全流程的維度去規(guī)劃設計，它們之間的跳轉、使用也會產生學習成本。有一個實際場景的例子：開發(fā)一個業(yè)務需求，先花一周時間讀懂代碼評估代碼的修改點，再花一周去配置整套環(huán)境，還要花一周時間熟悉研發(fā)流程中的工具鏈，而真正寫代碼可能只需要一天。

總體來看，我們要解決的問題是：如何更快開發(fā)——少寫代碼，更快上手——系統(tǒng)易理解，更快交付——全流程操作簡單。

三、思路與目標

業(yè)內的一些低代碼平臺主要聚焦的是前端的場景需求，將頁面元素封裝成通用組件，使用者拖拽這些組件實現(xiàn)頁面形態(tài)的定制。搜索中臺面對的是中后臺場景，但是要解決的問題和思路是非常類似的。從每個業(yè)務的實際情況看，雖然最終的檢索場景各不相同，但執(zhí)行的功能流程都有一定的相似性，如果我們把通用的功能抽出來，業(yè)務通過組合這些通用能力來滿足需求，就可以顯著提升效率。同時，這些通用能力是標準化的，業(yè)務可以按標準規(guī)范進行開發(fā)，開發(fā)生態(tài)易于分享和使用，針對通用算子滿足不了的業(yè)務場景，大家就會補充更多的通用組件，在下一次類似需求來到時快速滿足。

統(tǒng)一業(yè)務框架：圖引擎 & 圖編排

我們的解決思路是使用圖引擎來驅動業(yè)務邏輯的執(zhí)行，通用和定制的能力都以算子形式提供，業(yè)務則以 DAG 圖的形式串聯(lián)這些算子。圖本身沒有一套固定的流程，算子間的連接和使用完全由業(yè)務場景決定，所以即使是完全差異化的業(yè)務都可以使用圖引擎來構建系統(tǒng)。并且，圖和算子定義了一套標準規(guī)范，開發(fā)的產品功能都通過算子的形式對外暴露，而算子又是可以插拔的，業(yè)務之間都可以方便的拿來復用。

但是，僅僅有圖引擎是不夠的，我們需要讓算子在業(yè)務的使用之下快速沉淀起來：業(yè)務愿意去共建通用算子，并且這些算子對業(yè)務能夠充分共享，即大家可以便捷的查看和使用這些通用算子。而使用圖編排工具，可以以平臺化的形式對這些算子進行呈現(xiàn)，研發(fā)同學可以快速的查看所需功能算子，也可以通過可視化拖拽低成本的配置使用。

建設圖編排工具還有一個很重要的出發(fā)點是：我們希望通過可視化的圖幫助開發(fā)同學快速的了解業(yè)務系統(tǒng)。這個圖既是系統(tǒng)的實際運行圖，也是幫助快速理解系統(tǒng)的執(zhí)行流程圖。我們使用圖編排進行可視化之后，圖本身就具備自解釋性，研發(fā)同學可以在圖上補充備注信息，圖就相當于和代碼同步的天然文檔。對有一定規(guī)模的業(yè)務來說，通過“圖文檔”理解系統(tǒng)要比讀源碼理解更快，更加自然易懂。

全流程一站式研發(fā)

除了代碼開發(fā)上的改善之外，我們希望有一套統(tǒng)一的工具對研發(fā)全流程進行提效：在圖編排的基礎上打造 All-in-one 的開發(fā)平臺，將研發(fā)流程各個單點能力橫向集成與拉通。業(yè)務研發(fā)者在研發(fā)過程中不需要學習對接各種開發(fā)工具或平臺，所有的研發(fā)工作都收攏在一套工具里解決。同時這套流程又是標準化的，過去研發(fā)過程中所有的飛線技術棧都能統(tǒng)一起來，使用更加高效便捷的標準化解決方案。業(yè)務有能夠提升效率的方式、工具也可以往這套工具里進行沉淀，共同打造。

四、Nimbus 低代碼平臺的設計與實踐

我們在 iCoding（公司代碼開發(fā) IDE） 的基礎上建設了 Nimbus 低代碼平臺，所以 Nimbus 天生就擁有了 IDE 包含的代碼開發(fā)、編譯調試等基礎能力。對使用者來說，研發(fā)全流程的操作都可以在 IDE 內部完成，不需要對接外部工具系統(tǒng)，提供了很大的便利性。我們將研發(fā)全流程劃分為五個階段，分別是環(huán)境準備、開發(fā)、預覽調試、測試和發(fā)布運維。每個階段 Nimbus 都組建了適合的工具來降低開發(fā)者的研發(fā)成本。

一鍵生成線上同步的開發(fā)環(huán)境，開箱即用

在工程效能部同事的支持下，我們建設了可以開箱即用的云端開發(fā)環(huán)境。業(yè)務開發(fā)者在代碼倉庫可以一鍵申請開發(fā)鏡像，后臺會在云端拉起一個 Docker 容器，容器內運行著 iCoding 的服務端，可以使用瀏覽器的形式連接開發(fā)鏡像，也可以使用 iCoding 客戶端進行連接。

鏡像內包含代碼庫、開發(fā)過程中的全部工具、服務編譯運行所需要的全部依賴包、線上同步的服務配置詞典等，業(yè)務開發(fā)者不需要額外的配置就可以直接開始開發(fā)。同時所有用戶的開發(fā)環(huán)境也是完全一致的，不會因為系統(tǒng)、SDK、配置的不同導致的問題影響。當用戶長時間未連接開發(fā)鏡像時，鏡像會自動掛起閑置，節(jié)省機器成本。鏡像也可以分享給其他用戶，便于問題排查。

在打包鏡像的過程中我們發(fā)現(xiàn)應用的依賴非常多，如果將這些依賴都放入鏡像中會導致鏡像體積過大，不僅影響鏡像的拉起時間，也對機器的磁盤空間造成很大壓力。初期我們將這些依賴都放到 NFS 里，在鏡像內通過 fuse 進行掛載，但是會導致業(yè)務無法修改這些依賴，在一些場景下使用體驗不佳。我們又基于Overlayfs 虛擬了一層聯(lián)合文件系統(tǒng)，用戶看到的只是一個普通的文件系統(tǒng)目錄，可以任意修改替換。實際文件系統(tǒng)則包含兩層的合并內容，Lower 層指向了公共的 NFS 集群，里面有全部的依賴文件，和線上實時更新，Upper 層指向鏡像的工作目錄，用戶可以修改 Lower 層的文件，修改后會自動移到 Upper 層，Lower 原始數(shù)據(jù)不受影響。使用 Overlayfs 后我們的鏡像拉起速度非常快，絕大部分依賴都放到遠程，開發(fā)鏡像只需要5秒鐘就可以拉起。

可視化拖拽算子，快速組建復雜場景

開發(fā)過程中，使用者可以在 Nimbus 中打開圖編排工具來拖拽算子。每個算子都會有詳細的描述信息，比如名稱、類別、用途、屬性等。這些信息通過注解的方式在代碼中進行聲明，圖編排工具會掃描這些算子代碼，讀取相應的注解信息，并添加到算子倉庫中。業(yè)務開發(fā)同學可以在圖編排中對算子倉庫中的算子進行瀏覽或檢索，通過拖拽組建適合的業(yè)務場景執(zhí)行圖。拖拽后圖的連接配置會直接保存到業(yè)務的代碼庫，下次打開可以重新加載。

在圖編排工具中，我們也添加了一些交互來提示研發(fā)同學在圖中添加算子、邊的詳細備注，幫助其他同學基于圖快速了解系統(tǒng)。一些領域的問題可能具有相當?shù)膹碗s度，用一張圖表示并不直觀，我們提供了子圖的功能，可以將圖與圖之間關聯(lián)在一起。開發(fā)者在圖編排中可以雙擊跳轉，也可以通過Peek 功能快速查看子圖的結構。對于復雜的業(yè)務場景，研發(fā)同學就可以借助子圖來層級遞進的理解系統(tǒng)。

Nimbus 是在 IDE 基礎上進行的設計，所以圖編排可以和代碼開發(fā)緊密關聯(lián)在一起。在圖中雙擊算子單元能夠直接跳轉到具體的代碼實現(xiàn)，方便用戶實際開發(fā)。圖編排中也集成了調試分析的功能，用戶可以在圖中任意算子增加斷點查看輸入輸出，也可以觀察整個圖的執(zhí)行狀況，各個階段的耗時，通過圖的執(zhí)行過程快速掌握業(yè)務邏輯。

在實際的使用過程中，我們和業(yè)務同學將一些最優(yōu)實踐，高頻出現(xiàn)的業(yè)務場景抽象成了通用的圖模板，這些通用圖模板可以直接在 Nimbus 中進行打開，業(yè)務可以在這些模板的基礎上進行定制，為構建新場景時提供幫助參考。

免配置的端到端效果調試，使用更友好

預覽調試過去一直是很繁瑣的問題，系統(tǒng)的鏈路和模塊太復雜了，尤其對新人來說是一個很大的挑戰(zhàn)。Nimbus 提供了功能強大的預覽工具，同時支持直連請求和端到端的效果調試。我們和 QA 同學一起搭建了沙盒環(huán)境，完全復刻了線上的在線模塊，并和線上模塊保持同步更新。在調試端到端的過程中，Nimbus 會將請求轉發(fā)到沙盒環(huán)境，請求開發(fā)中的業(yè)務模塊時，沙盒環(huán)境會攔截該請求，轉發(fā)到實際開發(fā)調試的服務。新的效果預覽方式中預覽環(huán)境的大部分模塊都使用公共服務，顯著節(jié)省機器成本，同時省去了環(huán)境部署、同步更新的人力成本。

調試過程中，我們也可以通過 Nimbus 進行可觀測性分析，如 logging、tracing 等等。Nimbus 中也打通了 IDE 的 live debug 功能，支持用戶快速進行代碼的斷點調試。

現(xiàn)代化的測試工具集，集中在測試本身

過去測試流程主要依賴人來驅動，研發(fā)同學開發(fā)自測完之后，QA 同學需要將服務部署在測試環(huán)境，因為依賴較多，部署過程中需要 RD 和 QA 的反復溝通對接才能建立完整的測試環(huán)境。Nimbus 連接了一套公共測試集群，研發(fā)同學開發(fā)完之后可以一鍵部署仿真實例，仿真實例通過線下的 Paas 平臺進行部署，環(huán)境和線上基本一致，可用于性能壓測、效果驗證等。同時 Nimbus 支持自動化回歸測試功能，我們定期錄制了線上流量，發(fā)起自動化回歸時，Nimbus 會自動部署基線實例和測試實例，發(fā)送錄制流量來生成 diff 以及性能報告，用于評估上線風險。

智能化的容量管理，快速適應服務變化

Search-AE 內混布了大量的業(yè)務模塊，高峰期有百萬級 QPS，服務的容量規(guī)劃一直很難處理。搜索流量本身變化較快，加上業(yè)務頻繁迭代，線下需要反復壓測評估合適的部署方案。同時線上一直在變化，之前合適的部署方案可能因為上下游變更又產生資源不足或浪費。過去線上的容量問題一直需要研發(fā)和運維關注，我們希望在 Nimbus 中能夠用全局視角統(tǒng)一的管理線上容量，讓業(yè)務同學只需要關注在實際的代碼開發(fā)上。

智能容量管理要解決的問題是在滿足穩(wěn)定性要求的前提下，確定各個服務的部署計劃，讓 Search-AE 整個集群的資源占用最少。智能容量管理的處理包含觸發(fā)、分析和決策三個階段。觸發(fā)階段包含三種情況：一種是業(yè)務迭代變更時會觸發(fā)容量分析，第二種是線上持續(xù)的輪轉服務觸發(fā)分析，第三種是線上實際資源占用達到某個水位時觸發(fā)快速分析。分析階段主要的數(shù)據(jù)輸入包含：

1. 和線上一致的仿真實例，階梯遞增的QPS壓測下的資源占用、速度 SLA曲線。

2. 現(xiàn)在及歷史的QPS、耗時數(shù)據(jù)。

3. 現(xiàn)在及歷史的資源占用 Load 指標。

通過這些數(shù)據(jù)分析系統(tǒng)會綜合判斷服務是否需要變更部署安排，最終通過底層的調度引擎觸發(fā)服務調整。過去大部分容量變化都依賴人去做評估調整，有了這套工具后，線上服務的部署調整就可以實現(xiàn)自動化。

五、總結與展望

業(yè)務創(chuàng)新加速，在需求越來越多、迭代越來越塊、創(chuàng)新能力要求越來越高的背景下，如何通過技術手段為業(yè)務開發(fā)降本增效提質做出突破，是搜索中臺、也是眾多產品研發(fā)平臺需要思考和解決的問題。搜索中臺從業(yè)務場景和業(yè)務痛點出發(fā)，借鑒業(yè)界低代碼理念，對復雜的后端系統(tǒng)深入開展了低代碼的探索和實踐，據(jù)此形成一套從技術思路、到系統(tǒng)能力、再到業(yè)務運營可借鑒可復用的復雜后端系統(tǒng)低代碼解決方案，整個解決方案包含3個關鍵組成：

1. 基于圖引擎&通用模板通用算子&業(yè)務微定制算子，打造低代碼能力引擎，幫助業(yè)務少寫代碼

2. 打造低代碼一體化平臺，通過能力集成和可視化開發(fā)實現(xiàn)研發(fā)流程的全生命周期管理，幫助業(yè)務高效交付

3. 重視用戶培育，營造共創(chuàng)氛圍，促進創(chuàng)新生產力工具的應用、推廣和共建，幫助低代碼現(xiàn)代化生產力工具在實戰(zhàn)中快速成長

低代碼一體化平臺Nimbus正式發(fā)布以來，在多個業(yè)務取得了顯著收益，并收獲了早期用戶的高滿意度和良好口碑，驗證了通過低代碼實現(xiàn)復雜業(yè)務場景降本增效提質的切實可行。它是一套工具，也是一套標準，我們期望打造開放共創(chuàng)的生態(tài)，前臺和中臺同學都可以基于這套標準來沉淀更多的通用算子、研發(fā)能力、應用案例和實踐經(jīng)驗等等，而這些可以支撐我們進一步向更低代碼、更高效能去邁進。在低代碼的征途上，我們已經(jīng)揚帆起航，將繼續(xù)乘風破浪，勇往直前。期待搜索中臺低代碼一體化平臺能夠廣泛應用、深入人心，促進多元業(yè)務高效率、高質量、低成本的敏捷迭代，為加速業(yè)務創(chuàng)新和發(fā)展做出更多貢獻。

• JDK ThreadPoolExecutor核心原理與實踐

• 深入解析Apache Pulsar系列 —— Broker消息確認的管理

• 化繁為簡–百度智能小程序主數(shù)據(jù)架構實戰(zhàn)總結

• 深入剖析全鏈路灰度技術內幕

• 愛奇藝基礎數(shù)據(jù)平臺演進

技術原創(chuàng)及架構實踐文章，歡迎通過公眾號菜單「聯(lián)系我們」進行投稿。

高可用架構

改變互聯(lián)網(wǎng)的構建方式