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