一.離線傳遞的痛點
在傳統行業，如政府、能源、軍工、公安、工業、交通等行業，為了防止資料洩露和運作安全考慮，一般情況下網絡會采取内外網隔離的政策，以防範不必要的風險，畢竟在安全防護方面，網絡實體隔離是網絡安全防禦最有效的手段，而網絡隔離在軟體傳遞過程中，對于外部軟體開發廠商來說将會帶來一系列的傳遞難題，也增加大量成本投入。例如：
1. 現場安裝部署和驗收測試，效率低下
傳遞過程中需要将應用程式及依賴的所有資源安裝到離線客戶環境，而客戶環境有可能是實體伺服器、虛拟機、私有雲及K8s容器等各種環境，加上離線環境網絡的限制，就會導緻離線環境安裝和部署效率低下。由于安裝配置過程繁複，容易出錯，在最終傳遞環境中需要重新進行驗證測試工作，也需要浪費很多時間。如果部署的是微服務架構的應用系統複雜性更高，工作量還會加倍。
2. 離線環境定制開發和産品更新，成本高
定制開發需要開發人員投入，成本本來就高，在離線環境需要根據客戶回報持續疊代，疊代過程産品不斷更新，每更新一次就要走一次安裝部署和驗證測試過程，成本很高。如果有些工作必須駐場開發，成本更高。
3. 網絡不通，無法遠端運維
傳遞完成後，應用需要持續運維，保障運作穩定性和功能持續可用，在網絡無法聯通的情況下，出任何問題都需要安排人員現場支援，甚至需要安排人員長期駐場。
二.技術選型
上述問題的根本原因是因為，應用系統的
多環境适配
、
應用安裝部署
應用更新
應用運維
等操作自動化程度不高，需要大量人員手工操作，是以效率很低，解決問題的重點在解決應用管理的自動化。目前，雲原生技術已經越來越成熟，而雲原生技術主要解決的就是應用管理的自動化問題，具體有兩種開源實作方案 ：
1. Rancher+Helm
Rancher是一款K8s管理工具，他提供K8s的管理UI，包管理使用Helm。對應離線傳遞的問題，Rancher可以安裝在多種運作環境（實體伺服器、虛拟機、私有雲），并且提供部分應用自動化運維功能，它可以解決
多環境适配
和
應用運維
問題，而
應用安裝部署
應用更新
問題可以通過Helm包解決。
2. Rainbond+應用模版
Rainbond是“以應用為中心”的應用管理平台，應用模版是Rainbond對應用打包的方案，Rainbond提供應用的全生命周期管理（應用開發、應用編排、應用傳遞和應用運維）。Rainbond可以部署到各種運作環境上（實體伺服器、虛拟機、私有雲），還可以部署到已有K8s叢集和Ranchar上，解決客戶
多環境适配
問題；Rainbond提供應用運維面闆解決
應用運維
問題，使用比較簡單，不需要懂容器概念；Rainbond的應用模版是一個亮點，隻要在Rainbond上運作起來的應用就可以一鍵釋出成應用模版，簡化了應用模版的制作，而且應用模版可以導出離線包，特别适合離線環境的
應用安裝部署
應用更新
。
下面分别比較一下兩個方案
Rainbond相比Rancher最大的優點就是易用性，不需要學習K8s和容器相關技術和概念，另外，Rainbond提供的一體化開發環境和子產品編排功能，能大幅度提高定制開發的效率。Rancher最大的優點是完全相容K8s體系，如果了解K8s能很快上手。
Helm和應用模版比較
| 對比項 | Helm | 應用模闆 |
| 安裝和更新 | 少量配置 | 全自動 |
| 制作流程 | 人工編寫 | |
| 導出和導入離線包 | 不支援 | 支援 |
| 配置調整 | 支援預定義的配置調整 | |
| 子產品定制 | ||
| 相容其他K8s版本 | 相容 | 需要預先安裝Rainbond |
Rainbond的應用模版 跟 OAM的設計思路完全一緻，“以應用為中心”的設計理念，屏蔽掉容器基礎設施的複雜性和差異性，為平台的使用者帶來低心智負擔的、标準化的、一緻的應用管理與傳遞體驗。
綜合對比，在離線傳遞場景Rainbond+應用模版的方案優勢明顯，下面我們結合實際例子，來講解Rainbond+應用模版傳遞離線客戶的整個過程。
三.使用Rainbond應用模版進行離線環境的應用傳遞
基于Rainbond進行離線環境的應用傳遞，隻需将開發環境已開發好的業務釋出至應用市場，基于應用市場導出應用模闆的離線包，在傳遞環境中進行導入操作，導入後基于應用市場一鍵安裝即可自動運作。
預先準備環境
- 擁有兩套Rainbond叢集，模拟開發環境及傳遞環境(開發環境為線上環境，傳遞環境為離線環境)。
- 開發環境安裝，參考 線上安裝 文檔；
- 傳遞環境安裝，參考 離線安裝 文檔；
- 擁有U盤、CD光牒等離線環境下應用模闆離線包傳輸媒體。
1.業務部署
整個流程始于開發環境，我們首先需要将業務搬遷至Rainbond之上。在開發環境基于部署自己的業務，可以支援源代碼或是鏡像。目前以Spring Cloud微服務架構 Pig 為例，部署參考SpringCloud Pig 在Rainbond部署及應用制作。
2.應用釋出
将開發測試環境已開發完成的應用釋出至内部元件庫：點選應用左側導航欄 釋出 按鈕，選擇 釋出到元件庫 ，該過程需要 建立應用模闆，應用模闆定義了以下資訊:
| 選項名 | 說明 |
| 名稱 | 定義應用名稱（必填） |
| 釋出範圍 | 應用模闆的可見範圍，目前團隊為目前團隊可見，企業所有團隊可見（必選） |
| 分類标簽 | 應用标簽，可按照架構、行業、部署方式進行分類 |
| 簡介 | 應用描述，幫助使用者了解此應用 |
| Logo | 應用的Logo圖檔 |
建立應用模闆後定義應用釋出版本：
| 版本号 | 當同應用多次釋出時，如果版本号相同，則會覆寫已釋出的版本，如果不同，将釋出為新版本，應用更新或復原時，平台根據版本判斷（必填） |
| 版本别名 | 應用别名，例如 進階版，初級版 |
| 版本說明 | 目前釋出版本的說明，可區分不同版本的功能差異等資訊 |
釋出元件模型配置：
| 連接配接資訊 | 當連接配接資訊中出現密碼類的資訊，可選擇每次部署時自動生成随機值 |
| 環境變量 | 編輯該元件預設的環境變量 |
| 伸縮規則 | 定義該元件可伸縮的最大最小節點數，及節點伸縮步長，最小安裝記憶體限制。 |
釋出插件模型資訊：
要釋出的應用中其元件攜帶有插件時，會進行展示并在釋出過程中跟随元件釋出。
所有資訊配置完畢後，點選釋出按鈕進行釋出，業務開發過程中定義的元件間依賴關系、環境配置、持久化存儲、插件、運作環境及上述定義的所有資訊都将會被打包釋出。
3.應用導出
将應用模闆進行本地化導出，在首頁應用市場中找到已釋出的應用，點選最後方擴充按鈕，選擇導出應用模闆，選擇應用版本後點選應用模闆規範下的導出按鈕，導出過程完全自動化，待導出完成後點選下載下傳按鈕即可将應用模闆下載下傳至本地，儲存至U盤等移動儲存設備中，帶到離線傳遞環境中去。
接下來進入離線傳遞流程，傳遞人員攜帶着裝有離線包的U盤等移動儲存設備，開始導入應用模版。
4.應用導入
使用已導出的應用模闆在傳遞環境中導入，點選應用市場界面的離線導入按鈕，選擇本地的應用模闆上傳，上傳完畢後選擇導入範圍： 企業或團隊，企業為目前傳遞環境所有人可見，團隊為指定團隊下的人員可見；點選确認導入即進入自動化導入步驟。
5.一鍵部署
應用導入後點選安裝按鈕在目前傳遞環境即可一鍵部署該業務系統，該環境業務運作環境與開發環境完全一緻，到此完成離線環境下的軟體傳遞。
6.增量更新
軟體在更新疊代過程中需要進行某些子產品的更新，進行此類更新時即可使用增量更新來節省釋出及導入導出時間。
要達成增量更新的效果，需要重新進行應用釋出操作，選擇之前已建立的應用模闆，修改版本号，如之前版本設定為2.9，則此次釋出設定為3.0。
在應用釋出步驟選擇需要進行更新的元件進行釋出，而不需要選擇所有元件。釋出完成後，導出新版本的應用模版離線包，在傳遞環境中再次導入。
傳遞環境導入後，平台會對應用模闆不同版本進行對比，并通過應用拓撲圖中的待更新選項提示使用者進行更新。展示版本間屬性變更情況，使用者選擇需要更新的版本進行更新即可，平台将自動執行更新操作，變更元件建構版本。
更新過程中不會變動環境配置類資訊，這類資訊需要人為改動才會生效：
- 環境變量的值
- 配置檔案的内容
- 持久化存儲
7.一鍵復原
在更新版本上線後出現異常情況需要復原時，平台提供了一鍵復原功能，在更新記錄界面選擇對應記錄點選復原按鈕即可對更新操作進行復原。
在復原的過程中，新增元件并不會被删除，如需變更，需要人為操作。
8.應用運維功能
軟體産品傳遞完成以後需要進行長期的運維，在運維層面，傳遞人員需要考慮服務的可用性、可伸縮性、資源監控，Rainbond提供了諸多運維功能，例如：
-
服務性能分析
通過Rainbond插件機制擴充性能分析功能，服務實時性能分析插件運作在目标分析服務同一個網絡空間内，監控網卡的流量來統計分析服務的工作性能，對服務本身的工作流程和性能無影響，收集服務的平均響應時間，吞吐率等主要名額。
-
資源監控報警
基于 Prometheus 對平台及業務進行監控，基于 ETCD動态發現 需要監控的 targets，自動配置與管理 Prometheus 服務。
-
執行個體伸縮
對服務元件進行垂直伸縮或水準伸縮，在流量高峰期靈活進行擴容。
-
網關管理
應用網關支援灰階釋出和A/B測試功能。
四.場景拓展
上面的例子主要針對常見的離線軟體傳遞場景，但在真實的離線傳遞場景中，還可能存在以下場景，如：
- 離線子產品定制，每個客戶傳遞的子產品不一定，根據需要在客戶現場開啟或關閉子產品，或者子產品編排。
- 離線定制開發，在離線場景下進行完整的軟體開發過程，包括源碼管理、源碼編譯、開發測試環境管理、團隊協作、版本釋出流程等。
上面兩個功能定制場景，通過Rainbond也可以支援，大家可先自行探索。或者關注公衆号「好雨雲」，後續會釋出上述場景的詳細教程。
五.總結
本文我們分析了離線傳遞場景的問題，對比了可能的技術方案，并使用一個例子完整講解離線傳遞全過程，整個過程自動化程度很高。使用Rainbond進行離線傳遞肯定可以提高效率，但到底在哪些方面提高我們的效率，我再總結一下：
-
離線環境應用系統一鍵導出和導入
傳遞過程中隻需要攜帶基于Rainbond導出的應用模闆離線包在傳遞環境進行導入，即可一鍵安裝整套業務系統。
-
開發環境和離線環境完全一緻
Rainbond屏蔽了底層環境的差異，基于應用模闆進行傳遞，模闆對應用的運作環境、依賴關系進行打包，開發環境和離線環境完全一緻，不需要進行重複性測試。
-
一體化客戶定制環境
軟體傳遞過程中，不同的客戶會有不同的定制需求，也就意味着需要為不同客戶開發不同的子產品，這些定制的子產品在不同項目中都不盡相同，通過Rainbond提供的應用編排，就可以針對不同客戶編排和開啟不同功能子產品；如果需要定制開發，就可基于傳遞環境已部署的Rainbond直接進行離線代碼開發工作，包括源碼編譯、配置元件運作環境等，在傳遞環境中完成所有定制工作。
- 離線環境客戶持續傳遞 對于項目實施團隊而言，在實施過程中需要不斷将 新功能、缺陷修複 等快速落實到傳遞環境或使用者手中，傳統的持續傳遞過程中，離線環境下需要傳遞人員駐場，手動執行更新上線操作，該過程不僅增加了傳遞時間，且長期的手動執行操作會增加部署的風險；而Rainbond的持續傳遞能力，能夠實作應用後續的增量導入、導出和版本更新，能夠帶來以下優勢:
- 通過自動化方式實作，有效縮短代碼送出到部署上線的時間。
- 軟體在整個生命周期内都處于可部署更新的狀态。
- 簡化更新步驟，使軟體版本更加清晰。
- 讓傳遞過程成為可預期的、可視化的過程。
-
離線環境下自動化運維
服務高可用，自容錯和自恢複機制，減少人工運維，提高業務系統穩定性。