背景
每個程序員在學習開發的過程中，都知道解耦和模塊化的重要性，也希望自己設計和開發的程序支持模塊化，開發好的模塊其他人就能快速複用，爲了達成這個效果，我們學習各種模塊化和解耦的技術，從面向對象的設計模式到微服務架構，近幾年大家覺得微服務架構是模塊化的銀彈，都朝微服務架構改造，但實際效果不僅沒有很好模塊化，反而陷入應用部署和運維的泥潭裏。本文將講講Rainbond解決應用架構解耦和模塊化的一些新思路。
當前業務模塊化和解耦的問題
- 架構耦合度還是太高，解耦的不徹底 。比如通過微服務架構拆解的微服務，受開發語言和微服務框架限制，跨開發語言不能調用，跨框架也無法使用，還受限於部署環境，換個環境需要重新解決部署問題。
- 從開發者角度定義模塊，而不是從使用者角度定義模塊，導致使用體驗不好 。現在我們定義的模塊通常都是開發定義的，由於開發離實際使用場景比較遠，主觀的認爲模塊拆的細和小，不管有什麼場景需求我的模塊都能複用和滿足，但從使用者角度，模塊拆分的越小越細，學習和使用的成本就越高，甚至根本使用不起來，很多模塊化是過度的拆解和過度的設計。
- 模塊化發佈複雜，維護和升級成本高 。現在的模塊化本身是一個開發過程，定義和打包過程都需要開發參與，導致成本高。
基於Rainbond應用模型的解耦和實現思路
Rainbond是一個雲原生應用管理平臺，可以管理應用全生命週期。下面我們詳細講解一下Rainbond如何解決上述問題。
Rainbond的核心抽象和定義了一套應用模型，通過應用模型從架構上解決解耦問題，應用模型將應用、運維特性和底層基礎設施徹底解耦，應用又由多個業務組件拼裝而成，每個業務組件可以是不同開發語言和不同構建方式，只要符合業務契約就可以拼裝。通過以上解耦方式，徹底將業務組件、運維能力和部署環境解耦，業務組件只需要專注純業務，不再關心由於使用場景差異需要匹配不同開發框架、服務治理功能、運維工具和部署環境，業務組件、運維能力和部署環境實現根據使用場景自由組合和拼裝。
基於業務組件的拼裝場景：
- 從業務功能開發上，業務組件提供的是基於業務協議的服務，不受框架和開發語言限制，可以供其他業務場景複用；
- 從運維管理上，在開發測試環境不需要開啓運維的特性，在生產環境對業務的治理、監控、性能、穩定性和安全性有更高的要求，按需開啓通過插件機制實現的運維特性；
- 從部署環境上，應用模型底層實現對接標準K8s API，所有符合K8s 標準API的基礎設施都可以實現對接和部署，也就實現了業務組件不需要改動就可以部署到公有云、私有云和邊緣設備上。
解耦不僅能提高各種場景的靈活性，還能讓業務組件、運維插件和基礎設施複用率大幅度提高，當積累的可複用的能力越多，我們面對不同場景、不同用戶和不同市場的響應能力也越強。
Rainbond 應用模型遵循“以應用爲中心”的設計理念，將應用無關的底層複雜技術封裝，簡化理解和使用體驗。應用模型可以以應用模版的形式展現和存儲，以上可複用的能力通過應用模版發佈到應用市場，供其他人使用，從而實現模塊複用。通常我們實現模塊化主要考慮開發者，而應用模版更多考慮使用者，從使用者角度抽象定義，讓使用者能用起來，從而拉動應用模版的生產。從使用體驗上，應用模版可以一鍵安裝和一鍵升級，通過“拖拉拽”的方式實現業務拼裝。應用模版有很強靈活性，應用模版支持不同顆粒度大小，模版和模版能拼裝出新的模版，新的模版還可以持續拼裝，顆粒的大小由使用者決定，由使用者賦予它意義。
應用模版具備可打包業務的能力，有四個特點：
- 模塊化，可以形成可複用的能力單元，按需拼裝使用場景。
- 自治，自給自足，可以獨立安裝、升級和管理，確保組合的靈活性。
- 可編排，模版和模版可以拼裝出新模版，具備無限拼裝能力。
- 可發現，通過內部服務和外部服務兩種方式體現，可供業務和技術、開發者和其他應用訪問。
應用模版的定義和實現內容：
- 應用基本的元數據
- 名稱
- 時間戳
- 版本號和別稱
- 資源佔用情況
- 應用治理模式（ K8s service模式、Service Mesh內置和Istio）
- 應用網關信息
- 對外端口
- 域名和證書
- 發佈策略
- 應用全局配置
- 一個或多個業務組件
- 業務組件的依賴關係
- 業務組件類型（源碼、鏡像、Helm和第三方API）
- 組件的構建方式
- 組件的存儲方式
- 組件的配置方式
- 組件的運行方式
- 業務組件的插件
- 組件端口和協議
- 組件環境變量
模塊發佈和拼裝流程
在Rainbond中應用模版是模塊的表現形式，模塊發佈和拼裝流程就是應用模版的發佈和拼裝過程。模塊建設是一個長期過程，強調積累，更多是在實踐過程中的沉澱，同時需要根據反饋來持續迭代。 這個過程分四步：
第一步： 模塊以應用模版的形式一鍵發佈，所見即所得
發佈業務組件首先需要從業務角度定義顆粒度和業務接口，然後將要發佈的組件在Rainbond構建，Rainbond支持各種構建源，構建的同時也在定義應用模版，只要構建成功，就可以一鍵發佈成應用模版，也就意味着任何在使用平臺的開發者都具備發佈應用模版的能力，發佈的門檻低有利於知識和經驗的分享。
第二步： 通過應用市場存放不同顆粒度的模塊
應用模版支持不同顆粒度，針對不同使用場景包裝不同顆粒度：
- 面向內部研發場景，主要積累技術模版，模版顆粒度相對較小，爲了提高開發效率。
- 面向客戶交付場景，主要積累業務模版，模版顆粒度較大，通過模版可以快速拼裝客戶解決方案，提高交付效率。
- 面向銷售場景，主要積累可以銷售的產品模版，顆粒度最大，能幫助銷售快速演示、使用和整體交付。
第三步：通過應用模版實現模塊化拼裝
從應用市場一鍵安裝需要拼裝的模塊（應用模版），通過“拖拉拽”將多個模塊拼裝成需要場景，拼裝後原模塊發佈新版本，在拼裝好的場景裏按需升級。新拼裝好的場景發佈成應用模版，可以是更大的模塊支持更大場景的拼裝，也通過應用模版實現後續客戶交付流程。
第四步：在真實應用場景中，持續積累和迭代
模塊的建設過程，要避免過度設計和提前過度拆解，模塊提早拆解或拆解的粒度太小，會導致模塊開發和維護成本高，使用體驗不好。所以，模塊前期設計和開發只能佔少部分，大部分模塊在真實場景中才能看到它的價值，這時候再發布成可複用的模塊，更加具備實用性。同時，模塊的邊界和功能在真實場景中才有意義，需要根據實際需求不斷迭代。
使用場景
可拼裝的業務模塊，提高開發效率和客戶交付速度
對於軟件公司的研發和客戶交付場景，通過可拼裝的業務模塊，在新項目研發和新客戶交付過程中複用，減少重複性開發，能大幅度提高效率。
行業業務中臺，實現行業能力積累和複用
對於行業用戶，實現數字化的過程，會建設很多套系統，這些系統有很多能力是通用的，把這些能力積累下來，後續建設過程直接複用，不僅減少了建設週期，複用成熟的能力還能提高系統成熟度。另外，需要業務融合和數據融場景，可以通過業務編排，實現系統之間的互聯互通。
2B軟件公司的產品化包裝和模塊化銷售
對於2B軟件公司，會面對項目個性化和產品標準化的矛盾，要解決這對矛盾有兩個解決方案：一個是讓個性化的項目也能快速沉澱出產品，這個過程通過發佈應用模版能快速實現；另一個是將個性化的項目按模塊化拆解，不同客戶選擇不同模塊，實現根據客戶需求個性化銷售；這兩個方案可以進一步融合，在早期，個性化項目是驅動力，項目的模版可以作爲給其他客戶演示和交付的產品基礎，在不斷的交付客戶過程中，發現和拆解可複用的模塊和個性化的模塊，等交付客戶越多，積累的可複用模塊也就越多，也知道哪些模塊有商業價值，模塊化成爲產品的基礎，更好服務銷售和交付，產品化也就越成熟。