文章來源：EAWorld ；作者：郝炎峰

低代碼平臺在企業數字化轉型中發揮著重要的作用，助力降低成本、提升效率。尤其對于金融行業而言，其規模龐大、復雜多變，各級分行、業務線以及科技部門都有使用低代碼平臺來增強效能的需求。

對于領導層而言，要實現數字化轉型在一線分支機構的全面推進，不能僅停留在總行科技這層。對于分支機構或業務人員來說，依賴總行科技部門來解決日常小場景或特色需求是不現實的。他們希望能夠擁有簡便易用的工具，讓自己從繁瑣重復的日常工作中解脫出來，例如消除跑腿流程、手工報表等。而對于總行的科技人員來說，他們急需低代碼平臺來提升開發效率，并且希望該平臺能夠與既有的架構和技術棧完美融合，而不會增加新的架構和運維復雜性。

這么看來，分行業務線和科技部門都對低代碼有需求，同時也存在用戶和場景的差異性。那么是該分別建設不同的低代碼平臺？還是有一套平臺可以同時滿足兩者的需求？本文就以上問題一起來作探討。

目錄：

一、覆蓋“輕應用、輕業務系統、專業系統”的三類業務場景

二、支撐“零代碼、低代碼、高低代碼融合”的三種開發模式

三、建設“復雜業務系統建設”的六個特色能力

四、低代碼與AI

五、結尾

一、覆蓋“輕應用、輕業務系統、專業系統”的三類業務場景

針對前面提到的不同的用戶和使用場景，我們做了進一步分析，這些場景大致可以總結分為“輕應用”、“輕業務系統”、“專業系統”三類業務場景，我們認為作為企業級的低代碼平臺，要能夠具備支撐這三類場景的建設能力。

一是 “輕應用”：通常類似信息收集類、數據處理類、流程審批類小場景，適合業務人員采用零代碼方式建設；

二是 “輕業務系統”：相比輕應用，流程或業務處理略復雜一些，包含一些頁面、服務、數據相關的集成能力，業務人員或分行科技人員經過培訓也能容易上手；

三是 “專業系統”：對應銀行的大型復雜業務系統，通常有專有的數據模型、復雜的計算邏輯以及分布式的架構體系，這種業務系統則需要科技部門的開發人員為主實施，可采用低代碼、專業代碼融合的形式，以更高的效率和質量，更適合的方案推動復雜業務系統的建設落地。

我們在設計也建設低代碼平臺過程中，充分考慮了上述三類應用場景建設需要，面向不同的用戶和場景，均提供了相應適合的工具和能力方案支撐。讓平臺的用戶均能體會到“零代碼、低代碼”平臺帶來的更高效的生產力。

本文接下將圍繞著平臺面向不同的場景所提供的一些特色能力展開，對普元低代碼平臺的設計思想、能力以及解決方案進行介紹，期望能夠通過本篇文章內容為金融企業客戶提供一些建設低代碼平臺的一些思路參考。

二、支撐“零代碼、低代碼、高低代碼融合”的三種開發模式

上圖為普元低代碼開發平臺的架構示意圖，平臺的底座是基于微服務云原生的應用開發平臺，其為高低代碼融合打好了堅實的基礎。另一部分是DevOps平臺，支持應用全生命周期建設，例如零/低代碼開發場景中的應用環境自動化部署均依托DevOps實現。中間部分是平臺零/低代碼的核心內容，為不同角色的開發者提供了功能視圖、數據視圖、開發視圖。基于這些場景化的開發工具，讓開發者能夠快速構建多種不同場景的數字化應用。

功能視圖、數據視圖主要是為業務人員建設輕應用提供的零代碼視圖和工具，支持快速開發表單、流程、圖表、報表等應用。支持從Excel導入開始，通過向導式生成數據模型、表單、視圖輕應用，消滅手工報表、跑腿流程。讓數字化轉型深入一線，實現科技普惠。

開發視圖則是面向技術人員進一步提供了服務編排、腳本編寫相關工具和能力，方便開發者進行“輕業務系統相關場景”的開發工作。專業代碼開發工具則是為程序員提供的專業編碼開發工具，應對前后端復雜業務邏輯、頁面功能或專業領域算法的開發場景，在專業代碼開發的同時支持與低代碼開發配置結合完成業務系統建設，進而提升效率。

因此我們的平臺設計針對不同的業務場景和用戶分別提供更適合的工具和開發模式。示意圖如下：

三、建設“復雜業務系統建設”的六個特色能力

在金融級“復雜業務系統”建設場景中，低代碼開發模式需要具備更完善的支撐能力，包括但不限于：數據模型、質量與集成場景的支撐力；表單、視圖、圖表、報表、大屏等數據展現能力；服務交易組合編排對應的跨系統集成能力；端到端業務流程場景的靈活管控能力；一站式體系化的應用交付和管控運營能力等等。即便如此，低代碼能夠覆蓋的場景還是有局限的，只能支持系統中相對復雜度較低的功能范圍，很多復雜場景中，還是要程序員開發者進行編碼實現功能邏輯，采用高低代碼融合的方式來實現復雜業務系統高效、可靠落地。

接下來我們針對上述復雜業務系統落地的平臺能力建設中總結的六大特色能力分別進行說明。

1.技術融合的架構模式

近年來，大多數金融企業都在計劃建設低代碼平臺以提升效率。部分先行者已經建設了低代碼平臺。在與部分銀行企業溝通交流下來，我們發現大家建設過程中經常會走入一些誤區，很多都是解決局部問題為主，缺少總體規劃。常見問題如下：

一是引入的低代碼平臺不能融入已有架構體系，如：不符合微服務架構，多應用共享進程計算資源，應用間故障不隔離。

二是引入的低代碼平臺技術棧與銀行已有的技術體系差異較大，難以沉淀復用與融合。

三是引入的低代碼平臺體系封閉，復雜場景無法實現，擴展困難，運維管控方式特異，無法適應銀行既有的過程規范。

針對上述問題，我們認為建設低代碼平臺，架構上應該采用主流的微服務架構體系，能融入已有的技術架構最佳；技術上應采用前后端分離的主流技術棧，類似VUE、Spring Cloud等，同時信創也是目前一定要考慮的關鍵點；基于低代碼平臺開發應用過程中，應支持低代碼配置開發與專業代碼開發方式融合，低代碼開發過程中要能復用高代碼編寫的組件與服務；基于低代碼平臺開發的應用，應該是各自獨立的，不應互相影響，不論高代碼、低代碼或著是高低代碼融合，不應帶來應用的部署運維的變化，要能夠融入已有的運維管理規范體系。

概括來說就是要做到架構一致、技術一致、運維管理一致的三個一致基礎上的高低代碼真融合模式。

2.數據驅動的開發模式

市面上很多零/低代碼產品為了降低開發復雜度，采用了頁面驅動的開發模式。這種模式的優點是非技術人員更容易上手，開發體驗更好。缺點是其數據存儲會采用私有的格式保存，存下來的數據脫離其平臺不可讀。這種缺點會形成數據孤島，在金融企業中是不可接受的。

根據金融企業的業務特點，我們認為數據驅動模式是復雜業務場景建設的更優方案。銀行的各大業務領域，均有各自的專業領域的業務模型，這些模型通常是經過積累沉淀的復雜業務模型，具備行業知識門檻，幾乎不會從零開始構建。另一方面，基于數據模型，我們可以與銀行以后的數據標準做對接，這樣一來數據表字段、類型、接口報文、數據校驗、頁面控件等等都可以標準化，能夠實現高質量的數據落地，為后續的數據入湖、分析統計打好堅實的基礎。當然建模的過程業務人員有一定的學習成本，這種情況下，低代碼平臺可以通過技術手段簡化或自動化建模過程，由平臺自動生成模型與數據表，從而降低學習使用難度，讓業務人員更容易上手。

數據是金融企業的核心資產，高質量的數據落地是必要條件，因此數據模型和建模能力是必不可少的，我們可以通過標準化、自動化、智能化建模能力，在提升開發體驗的同時保障數據高質量落地。

3.組件化低代碼頁面引擎

低代碼拖拉拽所見即所得的表單、視圖頁面設計工具已經是所有低代碼平臺產品的標配，在低代碼平臺的頁面開發能力方面，應該重點關注如下幾個方面：

一是頁面引擎要支持豐富多樣化的展現形式，如表單、視圖、圖表、報表、看板、大屏等等。

二是頁面引擎要支持PC端、移動端頁面設計與渲染。

三是頁面引擎要提供豐富的前端組件，如基礎技術組件、布局容器類組件、高級功能組件等等。

四是頁面引擎要具備靈活的擴展模式，支持自定義擴展頁面組件，支持封裝復用已有的前端組件。

五是頁面引擎要具備代碼生成能力，生成的代碼符合規范和安全要求，支持可控的編碼調整能力。

在低代碼頁面引擎表面能力趨同的情況下，除了頁面的美觀和豐富展現形式外，靈活的組件擴展能力、源碼生成可控調整能力、基于安全源碼實時編譯渲染的能力等，更應是平臺建設或選擇的關鍵特性。

4.企業級低代碼流程引擎

在流程引擎方面，在復雜企業級的流程場景中，通常會有兩大類流程。其一是跨系統端到端的業務流程；其二是系統內部流程審批相關的操作流程。這兩類流程的側重點有所不同。端到端的業務流程，重點是跨系統的集成能力，如數據傳遞、服務調用、消息發送接收、外部系統的子流程調用與回調等場景；系統內的審批流程則更注重流程與表單的聯動配合、審批處理人的權限范圍規則、流程的分支流轉規則、任務處理的復雜規則等場景。除了低代碼產品化的配置能力之外，流程引擎的高性能與高可靠性集群模式運行支持，業務流程的運行期調整配置支持以及基于流程視角的統計分析能力都是必不可少的關鍵功能。

此外在流程銀行的場景中，流程作為銀行業務處理合規性的保障，面向整個銀行都應該有一致的規范和標準。那么統一流程平臺的支撐能力也是大型金融企業應多復雜業務場景的一個關鍵抓手，建設統一流程平臺，面向各領域的多個業務系統提供流程支持，基于多租戶技術手段，讓各業務系統在共享的云流程服務中各自對業務流程進行一站式的設計、開發、運行和管理，讓標準規范的業務、審批流程落實具備了明確可行的路徑和可管控、可分析優化的依據，最終形成業務流程持續優化的閉環。

5.高性能高可靠交易引擎

在銀行的“中間業務”、“場景金融”這類業務場景中，顯著的業務特點是相關業務會涉及與用戶、三方企業、其他金融機構的密切連接，比如投資理財、生活服務、財富管理等等場景，業務多樣性和復雜性較高，更注重個性化服務和合作協同。在這類場景下，不同企業、不同機構的對接需要具備很強大的集成和服務交易編排能力。通過一個高性能高可靠的交易引擎，能夠以低代碼的模式快速的讓相關業務交易實施上線，銀行才能在這些領域取得競爭優勢，為客戶提供更好的金融服務體驗。

服務交易編排是低代碼平臺集成能力的核心體現，在通用場景中，有了服務編排的能力，可以讓低代碼平臺的業務場景覆蓋率大幅提升至80%-90%。針對金融行業的復雜集成場景，具備更強大集成能力的交易引擎就更為重要。我們認為，面向金融企業尤其是銀行，服務交易編排的能力需要支持多種協議的集成能力；多種報文格式解析轉換能力；高性能高可靠性的異步、并行運算能力；以及對于異常場景的交易錯誤處理、補償沖正能力，以保障數據的正確和一致性。

另外，從低代碼交易開發工具的角度，低代碼流程式的交易編排工具必不可少，同時還需要支持開發過程中的在線調試以提升總體的開發效率；要支持運行期的源代碼生成確保代碼安全；盡可能采用編譯運行模式，保障運行期的性能和穩定性。

6.一站式交付與監控運營能力

對于“復雜業務系統”來說，通常會采用分布式的架構，具有實施交付周期長，運維管理復雜等特點。針對這種情況，作為低代碼平臺除了提供開發和運行支撐之外，對于應用的實施、交付、監控運營等場景也需要通盤考慮，提供全面的支撐能力和工具。

在應用實施過程管理方面，需要提供對于項目管理的支持能力，如需求、任務、測試、質量、文檔等工具和管理能力。

在應用交付方面，需要提供對于應用的自動化部署，應對金融企業的多環境交付管理過程規范要求，需要支持開發、測試、UAT、準生產、生產等多類型多套環境的資源管理和自動化部署交付工作。屏蔽繁雜的手工重復勞動。

在應用監控方面，基于低代碼平臺上建設和運行的所有應用，應提供一站式的統一應用監控治理平臺，對應用的配置集中管理，對運行健康狀態、資源使用情況監控，以及對應用的日志、性能做集中的分析與統計。

在應用的持續運營方面，應用基于低代碼平臺從建設到運行過程中持續收集運營數據，逐步實現對應用研發效能、運行效能、業務效能以及企業效能的全鏈路運營分析。

四、低代碼與AI

AI大模型在2023年可謂是火遍全球，帶來了越來越多的新模式新機遇。我們說很快AI就可以幫我們編寫軟件了。目前已經能夠通過提示詞描述，AI大模型幫我們生成一些寫的還算工整的代碼片段，確實可謂驚艷。然而個人認為離編寫生產可用軟件還是有很大的差距。以目前的AI大模型的能力，采用生成軟件源碼的方案即使生成了一個軟件系統，其可用性、可靠性并不能得到保障，想要基于其生成的軟件源碼去優化調整，非常困難。所以基于AI直接生成源代碼的軟件構建方案可行性目前比較低。更何況基于信息安全方面考慮，金融類企業也不允許開放自身的數據給大模型，應用場景也會有很多限制。

換個思路，我們發現低代碼平臺的模式本質上就是抽象了很多的開發、管理等專用模型。讓AI與低代碼的專用模型相結合，確是更具可行性的方案。基于專用模型來訓練AI更容易，生成的“基于模型的軟件”也具備規范性、可調優、可維護的特點。目前我們也已經在驗證低代碼結合AI助手的模式，如：數據模型推薦與生成、應用模塊與功能的生成、專有低代碼模型的輔助配置、專有API的代碼生成等等場景。接下來我們還會在AI與低代碼結合實踐應用方面進行持續研究，陸續會有相應的迭代成果產出，敬請期待。

五、結尾

如果說有這樣的一款低代碼平臺，其能解決業務問題，能提升開發效率，能融合主流的架構，能復用既有的沉淀，從簡單到復雜的場景均能從容應對…… 這樣的低代碼平臺相信您也會感興趣。感謝您對本文的關注與閱讀，期待與您進一步溝通交流，也祝愿您在未來的探索中取得更多的成就與成功！

郝炎峰

關于作者：

郝炎峰，普元首席方案專家，十余年產品研發與架構設計經驗，持續關注和研究分布式、微服務、DevOps等領域。曾負責普元低代碼開發平臺、流程平臺產品的核心架構、產品設計以及發展規劃。先后參與了國家電網BPM、BAM平臺、浦發銀行新一代流程平臺、興業銀行綜合應用開發平臺等大型平臺項目建設與實施。現專注于金融科技建設相關解決方案研究與落地。

這是科技創新最好的時代，這是屬于我們每個人最好的時代，關注“BanTech智庫”，專注銀行科技發展，探索無界金融生態！