---

> 做好企業應用的交付一直是 ToB 軟體廠商的關注重點。Rainbond Application Model（RAM）是Rainbond提出的一種應用模型，透過將企業應用進行模型化的抽象，搭配 Rainbond 平臺的應用市場機制，最終實現了一鍵安裝/升級。高度自動化的交付體驗，提升了企業應用交付效率，降低交付成本。

---

## 透過應用模型實現自動化交付

企業應用指的是支援企業、事業單位或者政府等機構各項業務運作的軟體系統。除了支援機構內部的協同工作之外，企業應用也支援企業與其供應商、業務夥伴和使用者的協作與協調。

每一套企業應用的複雜程度不盡相同，但往往可以細分出相互協作的多個元件。以輕量級的系統舉例，也要至少劃分成業務系統與資料庫兩個部分。大型的系統則有可能包含數十個元件，若干元件也可以形成模組。這些元件或模組之間還需要定義一些配置，來實現彼此之間的關聯依賴。如此複雜的場景，的確難為到了 ToB 軟體廠商的實施交付人員。

企業應用在傳統模式下的實施部署與升級，其難度、成本都與企業應用自身的複雜性成正比。這是由於在傳統模式下，實施交付人員更多的透過人工的方式，手動部署服務元件、編輯配置檔案。無法自動化處理的流程都具有低效與易錯的通病，企業應用的元件數量和複雜性會將這些通病疊加起來。

雲原生時代的企業應用交付都依靠各種容器化交付平臺落地，透過發揮容器化、平臺化的優勢，解決了環境一致性、自動化運維、故障自愈等問題。而在簡化應用交付與升級這一場景中，所選用平臺的能力就十分重要。

[Rainbond](https://www.rainbond.com)  是開源的雲原生多雲應用管理平臺，兼具 Kubernetes 叢集自動化管理能力，以及企業應用一鍵安裝升級能力。Rainbond Application Model（RAM）是基於 Rainbond 提出的一種應用模型，透過將企業應用進行模型化的抽象，搭配 Rainbond 平臺的應用市場機制，最終實現了一鍵安裝/升級。高度自動化的交付體驗，提升了企業應用交付效率，降低交付成本。

RAM 模型的抽象，囊括了企業應用所包含的所有服務元件以及元件間的關聯關係。這一高階抽象無關乎企業應用內部包含多少服務元件，也無關乎元件間的關聯關係是否複雜。應用模版（RAM模型在應用市場領域的具體實現）可以釋出到 Rainbond 特有的應用市場中，釋出出的應用模版可以作為企業應用的安裝包看待，無論原有架構多麼複雜、內部元件多寡，都可以完成一鍵安裝與升級。

為了適應更廣泛的交付領域，RAM 模型正在努力向 Open Application Model（OAM）演進。OAM 是業界新提出的一種應用模型，其設計是為了能夠以簡單的方式，在複雜環境中間交付更加健壯的企業應用。

---

## 使用Rainbond一鍵安裝企業應用

Rainbond的應用模版是應用模型的具體實現，是企業應用一鍵安裝的載體，如何製作應用模版可以參考下面的教程。

[製作應用模版教程](https://www.rainbond.com/docs/quick-start/get-start/release-to-market)

當製作好了應用模版，釋出到應用市場，就可以透過應用模版一鍵安裝，一鍵安裝過程可以將企業應用從開發環境中完美復刻到交付環境中。元件的特性、映象、外掛、依賴關係都得以保持原樣。

![one-key-deploy-update-8.png](https://static.goodrain.com/wechat/one-key-deploy-upgrade/one-key-deploy-update-8.png)

就實際操作而言，點選應用模版右側的安裝，選定團隊、叢集、應用、版本等必要資訊後，確定即可開始安裝目標企業應用。

Rainbond本身能支援各類客戶環境，不管是伺服器還是虛擬機器，是聯網還是離線，X86還是國產CPU都能支援，
只要客戶環境能安裝Rainbond，就可以透過應用模版一鍵安裝。

---

## 製作一個可以一鍵安裝的應用模版

應用模版所承載的企業應用，藉助一鍵安裝能力已然可以快速的交付部署。然而交付完成的企業應用是否可以在安裝完成後自動進入可用的狀態，和應用模版的製作過程有很大的關係。接下來，我們來介紹下，一鍵安裝即可用的應用模版，應該具備怎樣的“自我修養”。

**環境變數定義連線資訊**

可被訪問的地址，是元件之間的相互關聯呼叫的關鍵。通常情況下，可被訪問的地址會以 `IP:Port` 或域名的形式體現。然而 IP 的變更，在交付場景中是必然出現的，這嚴重影響了一鍵安裝即可用的能力。所以不要將連線地址寫成固定值，而是將其設計成為可以透過環境變數的方式動態拾取並配置的形式。Rainbond 平臺提供非常強大的連線資訊注入功能，專門用於處理元件間的訪問地址。

**資料自動初始化**

企業應用的持久化資料，應該與程式檔案分離。所有需要持久化的資料，都應該具有獨立的目錄，這些目錄在容器啟動前，可以為空。如果有多個目錄需要被持久化時，它們最好擁有相同的父級目錄。所有的資料庫中介軟體、業務持久化資料需要支援自動初始化。資料的初始化有多種方式可供選擇，開發人員可以根據實際情況自行選擇：

- 業務程式碼管理資料版本（推薦）

由開發人員在企業應用程式內部新增邏輯，完成對資料庫表結構的初始化操作。這是一種非常通用的方法，企業應用在啟動時自動檢測可連線到的資料庫中是否存在指定的表結構，如不存在則進行一次初始化。這種方式更被推崇的原因在於開發人員也可以藉助這一方式完成資料庫表結構的升級操作。參考 [原始碼構建實現資料庫表結構自由升級回滾](https://mp.weixin.qq.com/s/mYUqd-kv61_T5gn-Nmq9Mw) 可以瞭解一種基於 Liquibase 結合 Rainbond 原始碼構建能力的資料庫版本解決方案。

- 官方映象提供的能力

對於市面上常見的各類資料庫中介軟體而言，其官方映象均具備資料自動初始化的能力。包括但不限於 Mysql、Mongo、Postgresql等常見資料庫。

- 針對非結構化資料製作初始化外掛

對於更一般化的場景，平臺支援以外掛機制來針對服務元件的指定持久化目錄進行資料初始化，這種方式藉助了外部的物件儲存來保持需要被初始化的資料。該外掛的使用方式，參考 [通用資料初始化外掛](https://www.rainbond.com/docs/practices/app-dev/data-initialization) 瞭解這一最佳實踐。

**合理的解耦方案**

為了實現一鍵安裝企業應用的目標，需要劃分出可以被解耦的不同模組，並且將模組以應用模版的方式釋出出來。每一個模組對應的應用模版，都應該是可以被獨立安裝並執行的。交付實施人員根據最終客戶的業務需求，按需一鍵部署出多個應用模組，並在圖形化介面下進行拼裝，即完成了企業應用的整體交付。對於企業應用開發人員來說，合理的解耦方案，可以達成模組化複用的效果，降低開發人員的重複工作量。

深入瞭解到如何合理劃分模組：[使用Rainbond打包業務模組，實現業務積木式拼裝](https://mp.weixin.qq.com/s/liHYLDmBgcHuhOfODlwJvQ)

---

## 使用Rainbond一鍵升級企業應用

由 RAM 實現而來的應用模版是具備版本控制機制的，這意味著在同個應用模版的不同版本之間可以快速的升級與回滾。

對於開發人員而言，在源應用一側作出需要的變更，無論是程式碼的改動後構建，還是新加入其他元件，都會在下一次應用模版釋出過程中疊加到新版本的應用模版中去。開發人員務必注意釋出時定義的版本號，Rainbond 透過它來確定是否進行升級。

對於交付人員而言，只需要將不同版本的應用模版匯入到交付環境中，Rainbond 會自動識別同個應用模版的不同版本，並執行一鍵升級操作。

![one-key-deploy-update-6.png](https://static.goodrain.com/wechat/one-key-deploy-upgrade/one-key-deploy-update-6.png)

而在已經交付完成，正在執行的應用頁面中，小 A 找到了升級的入口。Rainbond 識別到了最新的版本，而升級操作也是一鍵觸發，非常好用。

![one-key-deploy-update-7.png](https://static.goodrain.com/wechat/one-key-deploy-upgrade/one-key-deploy-update-7.png)

---

## 一鍵安裝和一鍵升級的實現原理

基於 RAM 模型實現的應用模版為何能做到一鍵安裝複雜應用？首先需要了解應用模版內部構造。

應用模版由兩個部分組成：應用後設資料、容器映象壓縮包。

**應用後設資料**

應用後設資料負責描述應用以及其內部元件的特徵。換句話說，應用後設資料是對 RAM 模型的描述。這些後設資料會儲存在 Rainbond 資料庫中，Rainbond 透過拾取這些後設資料，瞭解到需要安裝的是一個什麼樣子的應用。這些後設資料主要包括的內容如下：

| 屬性       | 級別  |
| -------- | --- |
| 應用名稱     | 應用  |
| 應用版本     | 應用  |
| 元件間依賴關係  | 應用  |
| 閘道器策略     | 元件  |
| 元件名稱     | 元件  |
| 元件映象     | 元件  |
| 元件環境變數   | 元件  |
| 元件外掛配置   | 元件  |
| 元件儲存     | 元件  |
| 元件埠配置   | 元件  |
| 元件部署方式   | 元件  |
| 元件健康檢查策略 | 元件  |

**容器映象**

業務容器映象的來源，應用模版一經匯入後，容器映象會被裝載到 Rainbond 所引用的容器映象倉庫中。啟動每一個元件時，Rainbond 會根據後設資料中記錄的映象地址拉取對應的映象。

經過應用後設資料的解析插入，以及容器映象的匯入，交付人員就可以在客戶環境中一鍵安裝企業應用了。

![one-key-deploy-update-9.png](https://static.goodrain.com/wechat/one-key-deploy-upgrade/one-key-deploy-update-9.png)

企業應用一鍵安裝完成後，Rainbond 可以保障讓其執行起來。如果希望能更進一步，確保企業應用內部的業務邏輯也能夠正常工作，則需要在應用模版的製作過程中注意更多的自動化改進。

**升級**

一鍵升級和一鍵安裝的原理類似，一鍵升級的過程實際上是分別對應用後設資料和容器映象進行了版本的變更。

容器映象的升級很好處理，只需要引用不同的 tag 即可。而對於可升級應用內的所有元件而言，升級的過程中會覆蓋以下應用後設資料變更。

| 屬性     | 級別  | 規則       |
| ------ | --- | -------- |
| 元件     | 應用  | 新增, 更新   |
| 外掛     | 應用  | 新增       |
| 配置組    | 應用  | 新增       |
| 映象     | 元件  | 更新       |
| 啟動命令   | 元件  | 更新       |
| 環境變數   | 元件  | 新增       |
| 元件連線資訊 | 元件  | 新增       |
| 埠     | 元件  | 新增，更新    |
| 儲存     | 元件  | 新增       |
| 配置檔案   | 元件  | 新增，更新    |
| 健康檢測探針 | 元件  | 新增，更新，刪除 |
| 監控圖表   | 元件  | 新增, 更新   |
| 監控點    | 元件  | 新增, 更新   |
| 外掛     | 元件  | 新增       |
| 元件依賴關係 | 元件  | 新增, 刪除   |
| 儲存依賴關係 | 元件  | 新增, 刪除   |

值得注意的是，基於應用模版的升級，僅包含了應用程式的升級。實際環境中，經常涉及到持久化資料的變更。最常見的一種情況，是企業應用所使用的資料庫的表結構，需要跟隨應用程式的升級而變化。前文中介紹的 [原始碼構建實現資料庫表結構自由升級回滾](https://mp.weixin.qq.com/s/mYUqd-kv61_T5gn-Nmq9Mw) 方案，就可以處理這種表結構的版本控制。

---

## 企業應用的管理與運維

企業應用的安裝與升級都是一次性的，而管理與運維則是長久持續的。

當企業應用被交付到客戶環境之後，運維人員需要掌控管理執行環境的能力。現代 IT 基礎設施是非常複雜的，運維人員想要在物理機、虛擬機器等不同環境之間統籌有度已屬不易，想要在公有云、私有云乃至混合雲之間遊刃有餘更是對其技術能力提出了挑戰。如果能有一款易用的平臺抹平不同基礎設施之間的差異，那就將極大的簡化運維人員的管理工作。

瞭解 [雲原生應用管理，像管理手機APP一樣管理企業應用](https://mp.weixin.qq.com/s/T6WwbQJKaVgwwWwLLkjH9g) 。

## 總結

本文重點講述了企業應用自動化安裝和升級的實現過程，這個過程非常適合企業產品沒有功能定製化的標準化交付，對接開發環境可以實現客戶的持續交付，提高10倍以上交付效率。 然而，標準化交付在企業產品交付過程中只能佔少數，對於需要功能定製化的個性化交付場景該如何提供交付效率呢？我們將在下一篇文章將詳細介紹。

提高企業產品交付效率系列（1）—— 企業應用一鍵安裝和升級

相關文章