使用Rainbond打包業務模組,實現業務積木式拼裝

語言: CN / TW / HK

背景

每個程式設計師在學習開發的過程中,都知道解耦和模組化的重要性,也希望自己設計和開發的程式支援模組化,開發好的模組其他人就能快速複用,為了達成這個效果,我們學習各種模組化和解耦的技術,從面向物件的設計模式到微服務架構,近幾年大家覺得微服務架構是模組化的銀彈,都朝微服務架構改造,但實際效果不僅沒有很好模組化,反而陷入應用部署和運維的泥潭裡。本文將講講Rainbond解決應用架構解耦和模組化的一些新思路。

當前業務模組化和解耦的問題

  • 架構耦合度還是太高,解耦的不徹底 。比如通過微服務架構拆解的微服務,受開發語言和微服務框架限制,跨開發語言不能呼叫,跨框架也無法使用,還受限於部署環境,換個環境需要重新解決部署問題。
  • 從開發者角度定義模組,而不是從使用者角度定義模組,導致使用體驗不好 。現在我們定義的模組通常都是開發定義的,由於開發離實際使用場景比較遠,主觀的認為模組拆的細和小,不管有什麼場景需求我的模組都能複用和滿足,但從使用者角度,模組拆分的越小越細,學習和使用的成本就越高,甚至根本使用不起來,很多模組化是過度的拆解和過度的設計。
  • 模組化釋出複雜,維護和升級成本高 。現在的模組化本身是一個開發過程,定義和打包過程都需要開發參與,導致成本高。

基於Rainbond應用模型的解耦和實現思路

Rainbond 是一個雲原生應用管理平臺,可以管理應用全生命週期。下面我們詳細講解一下Rainbond如何解決上述問題。

Rainbond的核心抽象和定義了一套應用模型,通過應用模型從架構上解決解耦問題,應用模型將應用、運維特性和底層基礎設施徹底解耦,應用又由多個業務元件拼裝而成,每個業務元件可以是不同開發語言和不同構建方式,只要符合業務契約就可以拼裝。通過以上解耦方式,徹底將業務元件、運維能力和部署環境解耦,業務元件只需要專注純業務,不再關心由於使用場景差異需要匹配不同開發框架、服務治理功能、運維工具和部署環境,業務元件、運維能力和部署環境實現根據使用場景自由組合和拼裝。

基於業務元件的拼裝場景:

  • 從業務功能開發上 ,業務元件提供的是基於業務協議的服務,不受框架和開發語言限制,可以供其他業務場景複用;
  • 從運維管理上 ,在開發測試環境不需要開啟運維的特性,在生產環境對業務的治理、監控、效能、穩定性和安全性有更高的要求,按需開啟通過外掛機制實現的運維特性;
  • 從部署環境上 ,應用模型底層實現對接標準k8s API,所有符合k8s 標準API的基礎設施都可以實現對接和部署,也就實現了業務元件不需要改動就可以部署到公有云、私有云和邊緣裝置上。

解耦不僅能提高各種場景的靈活性,還能讓業務元件、運維外掛和基礎設施複用率大幅度提高,當積累的可複用的能力越多,我們面對不同場景、不同使用者和不同市場的響應能力也越強。

Rainbond 應用模型遵循“以應用為中心”的設計理念,將應用無關的底層複雜技術封裝,簡化理解和使用體驗。應用模型可以以應用模版的形式展現和儲存,以上可複用的能力通過應用模版釋出到應用市場,供其他人使用,從而實現模組複用。通常我們實現模組化主要考慮開發者,而應用模版更多考慮使用者,從使用者角度抽象定義,讓使用者能用起來,從而拉動應用模版的生產。從使用體驗上,應用模版可以一鍵安裝和一鍵升級,通過“拖拉拽”的方式實現業務拼裝。應用模版有很強靈活性,應用模版支援不同顆粒度大小,模版和模版能拼裝出新的模版,新的模版還可以持續拼裝,顆粒的大小由使用者決定,由使用者賦予它意義。

應用模版具備可打包業務的能力,有四個特點:

  1. 模組化 ,可以形成可複用的能力單元,按需拼裝使用場景。
  2. 自治 ,自給自足,可以獨立安裝、升級和管理,確保組合的靈活性。
  3. 可編排 ,模版和模版可以拼裝出新模版,具備無限拼裝能力。
  4. 可發現 ,通過內部服務和外部服務兩種方式體現,可供業務和技術、開發者和其他應用訪問。

應用模版的定義和實現內容:

  • 應用基本的元資料
    • 名稱
    • 時間戳
    • 版本號和別稱
    • 資源佔用情況
  • 應用治理模式( k8s service模式、Service Mesh內建和Istio)
  • 應用閘道器資訊
    • 對外埠
    • 域名和證書
    • 釋出策略
  • 應用全域性配置
  • 一個或多個業務元件
    • 業務元件的依賴關係
    • 業務元件型別(原始碼、映象、Helm和第三方API)
      • 元件的構建方式
      • 元件的儲存方式
      • 元件的配置方式
      • 元件的執行方式
    • 業務元件的外掛
    • 元件埠和協議
    • 元件環境變數

模組釋出和拼裝流程

在Rainbond中應用模版是模組的表現形式,模組釋出和拼裝流程就是應用模版的釋出和拼裝過程。模組建設是一個長期過程,強調積累,更多是在實踐過程中的沉澱,同時需要根據反饋來持續迭代。

這個過程分四步:

第一步: 模組以應用模版的形式一鍵釋出,所見即所得

釋出業務元件首先需要從業務角度定義顆粒度和業務介面,然後將要釋出的元件在Rainbond構建,Rainbond支援各種 構建源 ,構建的同時也在定義 應用模版 ,只要構建成功,就可以一鍵釋出成應用模版,也就意味著任何在使用平臺的開發者都具備釋出應用模版的能力,釋出的門檻低有利於知識和經驗的分享。

第二步: 通過應用市場存放不同顆粒度的模組

應用模版支援不同顆粒度,針對不同使用場景包裝不同顆粒度:

  • 面向內部研發場景,主要積累技術模版,模版顆粒度相對較小,為了提高開發效率。
  • 面向客戶交付場景,主要積累業務模版,模版顆粒度較大,通過模版可以快速拼裝客戶解決方案,提高交付效率。
  • 面向銷售場景,主要積累可以銷售的產品模版,顆粒度最大,能幫助銷售快速演示、使用和整體交付。

第三步:通過應用模版實現模組化拼裝

從應用市場一鍵安裝需要拼裝的模組(應用模版),通過“拖拉拽”將多個模組拼裝成需要場景,拼裝後原模組釋出新版本,在拼裝好的場景裡按需升級。新拼裝好的場景釋出成應用模版,可以是更大的模組支援更大場景的拼裝,也通過應用模版實現後續客戶交付流程。

第四步:在真實應用場景中,持續積累和迭代

模組的建設過程,要避免過度設計和提前過度拆解,模組提早拆解或拆解的粒度太小,會導致模組開發和維護成本高,使用體驗不好。所以,模組前期設計和開發只能佔少部分,大部分模組在真實場景中才能看到它的價值,這時候再發布成可複用的模組,更加具備實用性。同時,模組的邊界和功能在真實場景中才有意義,需要根據實際需求不斷迭代。

使用場景

可拼裝的業務模組,提高開發效率和客戶交付速度

對於軟體公司的研發和客戶交付場景,通過可拼裝的業務模組,在新專案研發和新客戶交付過程中複用,減少重複性開發,能大幅度提高效率。

行業業務中臺,實現行業能力積累和複用

對於行業使用者,實現數字化的過程,會建設很多套系統,這些系統有很多能力是通用的,把這些能力積累下來,後續建設過程直接複用,不僅減少了建設週期,複用成熟的能力還能提高系統成熟度。另外,需要業務融合和資料融場景,可以通過業務編排,實現系統之間的互聯互通。

2B軟體公司的產品化包裝和模組化銷售

對於2B軟體公司,會面對專案個性化和產品標準化的矛盾,要解決這對矛盾有兩個解決方案:一個是讓個性化的專案也能快速沉澱出產品,這個過程通過釋出應用模版能快速實現;另一個是將個性化的專案按模組化拆解,不同客戶選擇不同模組,實現根據客戶需求個性化銷售;這兩個方案可以進一步融合,在早期,個性化專案是驅動力,專案的模版可以作為給其他客戶演示和交付的產品基礎,在不斷的交付客戶過程中,發現和拆解可複用的模組和個性化的模組,等交付客戶越多,積累的可複用模組也就越多,也知道哪些模組有商業價值,模組化成為產品的基礎,更好服務銷售和交付,產品化也就越成熟。