由於資料隱私和網路安全的考慮，大多數toB場景的客戶需要私有化應用交付，也就是需要交付到客戶的環境裡，這樣的客戶有政府、金融、軍工、公安、大型企業、特色行業等，這些私有化場景限制很多，如何提高私有化應用交付的效率是個難題，本文將介紹，私有化應用交付有哪些技術？他們都各自有什麼特點？私有化應用交付的發展歷程。

## toB應用私有化交付的困難點

**環境網路限制，影響交付效率**

- 交付實施過程中不能方便查詢資料；
- 在交付過程中，交付人員需要跟公司的開發進行溝通，網路限制會影響協作工具的使用，有些客戶環境甚至不能帶手機，會影響解決問題的效率，環境越複雜影響越大；
- 在離線環境內，安裝軟體包也沒辦法直接下載，我們需要將安裝檔案或配置檔案打包成離線包，在客戶環境匯入。由於業務的複雜性會導致映象很多且很大，只能有交付人員帶行動硬碟到客戶現場匯入，導致在匯入離線包就會花費較多時間。甚至有些環境只能燒錄光碟在客戶環境匯入，光碟本身存不了太大的包，只能分多個光碟燒錄；

**客戶基礎設施差異，需要適配過程**
- 在私有化場景，不同客戶的安裝環境也不一樣，有些使用物理伺服器，有些使用虛擬機器，不同的虛擬機器廠商也有差異。作業系統也各有不同，例如常見的作業系統有 CentOS/Debian/Ubuntu/Redhat，當前還有很多國產化作業系統。CPU 架構也可能不同，有 X86、ARM 等；
- 資源準備週期長，需要審批流程；
- 交付的應用需要很重的適配過程，要麼在公司適配，要麼在客戶現場適配；
- 由於環境差異很大，應用交付完需要完整測試和驗證，需要大量的人力和時間投入；

**交付人員的技術門檻高**
- 交付人員需要懂底層硬體和網路；
- 交付人員需要懂作業系統和系統運維，需要懂服務治理、高可用、安全、效能分析、備份恢復、交付開發等等；
- 交付人員要能獨立排查交付應用的問題，需要很強的技術基礎；

**定製化交付迭代效率低**
- 在定製化交付場景，客戶會參與到開發過程中，客戶需要看到效果後反饋問題，再持續迭代，直到客戶滿意，過程中需要頻繁升級產品；
- 如果開發人員在公司定製開發，升級過程複雜，溝通低效；
- 如果開發人員在客戶現場，沒有好的開發工具和環境，開發效率低，人力投入大；

**後期維護難度大**
- 應用交付完成後，後期需要保障應用執行的穩定性，離線環境遠端沒辦法運維，報警沒辦法發出來，運維的難度大；
- 產品有Bug、一些預期內的變更或產品升級都需要出差客戶現場，支援的成本比較高；

## 傳統應用交付

傳統的應用交付是直接交付二進位制的可執行檔案或軟體包：
- **二進位制的可執行檔案：** Java 的 Jar，Linux 的可執行檔案，Windows的 EXE 等。
- **軟體包：** CentOS 使用 RPM 包，Debian 使用 DEB 包，Java Web 使用 WAR 包。

安裝他們都需要先安裝依賴的環境和基礎軟體，YUM 和 DEB 有自己的管理依賴的軟體源，但離線環境用不了，如果客戶的作業系統不同，還需要另外想辦法解決，執行這類服務為了解決啟動和自動重啟的問題，還需要透過 Systemd 或 Supervisor 的方式來管理。如果交付單體架構的應用傳統應用交付方式還能勝任，但如果是複雜的微服務架構，傳統應用交付方式將難以勝任。

在傳統應用交付過程中，管理這些執行環境和作業系統差異是一個痛點，容器的出現解決了這個問題。

## 當前雲原生技術應用交付
雲原生應用交付主要使用的容器和 Kubernetes 相關技術。

### Docker 映象交付

Docker 將業務和依賴的庫一起打包成 Docker 映象，在這個映象中包含所有環境和應用，這樣就可以達成一處打包、到處使用，我們可以將該映象在任何支援 Docker 的作業系統上執行。Docker 的特性的確解決了很多開發、交付以及其他許多問題，因此 Docker 容器概念迅速的被普及。

在微服務架構場景，需要多個服務或應用一起交付，服務之間有依賴，還有複雜的配置，DockerCompose 解決了這個問題。

### Docker-Compose應用交付

DockerCompose 將多個服務或應用使用 YAML 的方式管理，可以利用 DockerCompose 命令安裝部署和管理，對於一個微服務架構的應用，利用 DockerCompose 命令就可以在任何作業系統實現一鍵安裝和執行，當然前提是需要安裝好 Docker 和 DockerCompose。

對於單機場景 DockerCompose 可以適用，當應用需要高可用或多節點分散式部署，DockerCompose 就不能勝任，Kubernetes 的出現解決了容器的高可用和分散式排程問題。

### Kubernetes YAML應用交付

在 Kubernetes 中部署業務我們需要定義 Deployment Statefulset Service 等資源型別，透過調整副本的方式 Kubernetes 會自動排程到多個節點實現業務高可用，在交付時我們只需要將這些 YAML 資源和 Image 匯出，在客戶的 Kubernetes 環境中部署並交付給客戶。這種交付方式需要客戶環境有 Kubernetes 或在客戶環境安裝 Kubernetes。

當我們將 Kubernetes YAML 交付很多客戶的時候，就需要引數配置、版本管理和簡單的安裝和升級，Helm 在 Kubernetes YAML 的基礎上解決了上述問題。

### Helm 應用交付

Helm 是 Kubernetes 資源的包管理器，它可以將一組資源定義成 Helm Chart 模版，提供了基於 Helm Chart 模組的安裝和升級，安裝時可以配置不同的引數。Helm 同樣也是在 Kubernetes 交付中大多數人選擇的工具。

Helm 最大的問題是需要開發者學習容器和 Kubernetes 整個技術棧，而且客戶環境必須要有 Kubernetes，學習和使用的門檻太高。抽象的應用模型是一個解決方案。

## 面向未來的雲原生應用模型交付
應用模型強調以應用為中心的理念，讓開發者專注在業務本身，在應用級抽象和包裝底層複雜的技術，應用模型跟底層基礎設施完全解耦，根據對接和交付的基礎設施不同，自動轉換和適配，真正實現一次開發，處處自動化部署。

### 基於OAM的KubeVela應用交付
OAM（Open Application Model） 是一個描述應用的標準規範。有了這個規範，應用描述就可以徹底與基礎設施部署和管理應用的細節分開。透過將應用定義與叢集的運維能力分離，可以讓應用開發者更專注於應用本身，而不是”應用部署在哪“這樣的運維細節。KubeVela 基於 OAM 實現了應用跨雲、跨環境持續交付。當前 KubeVela 對離線場景的應用交付支援較弱。

### 基於RAM的Rainbond應用交付

Rainbond 是一個雲原生應用多雲管理平臺，Rainbond 遵循以應用為中心的核心理念，統一封裝容器、Kubernetes 等複雜技術，將 Kubernetes 資源統一抽象成 RAM（Rainbond Application Model）應用模型，使使用者能非常簡單的使用 Kubernetes，降低使用者使用的門檻，使使用者專注於應用開發、應用交付和應用運維。

在對於離線交付場景，Rainbond 基於 RAM 可以匯出三種離線交付包：
- **Rainbond應用模版包：**其中包含了複雜微服務架構交付的所有要素，支援升級和回滾，但要求客戶環境安裝 Kubernetes 和 Rainbond；
- **非容器的軟體包：**非容器包按照傳統應用交付方式打包，但易用性更好，包中包含了環境依賴，並採用靜態編譯，適合大多數作業系統，使用 Systemd 管理；
- **Docker-Compose離線包：**支援在標準 Docker Compose 環境一鍵啟動和管理；

## 綜合對比

|       | 交付門檻 | 微服務支援 | 多節點排程<br>自動化運維 | 離線迭代效率 | 客戶環境支援 |
|----------------|----------|:-----------|:---------------------|:-------------|:-------------|
| 傳統交付       | 高       | 不支援     | 不支援               | 低           | 伺服器       |
| Docker映象     | 中       | 不支援     | 不支援               | 高           | 容器/K8s     |
| Docker Compose | 中       | 支援       | 不支援               | 中           | 容器         |
| K8s Yaml       | 中       | 支援       | 支援                 | 中           | K8s          |
| Helm Chart     | 中       | 支援       | 支援                 | 中           | K8s          |
| KubeVela       | 中       | 支援       | 支援                 | 中           | K8s          |
| Rainbond       | 低       | 支援       | 支援                 | 高           | K8s/容器/伺服器       |

- **應用交付門檻:** 傳統方式交付門檻最高；Docker、DockerCompose、Kubernetes Yaml、Helm 和 KubeVela 交付的門檻中等，因為需要學習會容器和Kubernetes 相關技術；Rainbond 使用最簡單，不需要學習容器和 Kubernetes。
- **微服務支援:** 除傳統應用交付和Docker映象，其他方式都支援微服務編排和打包交付。
- **多節點排程和自動化運維：**Kubernetes Yaml、Helm、KubeVela 和 Rainbond 支援 Kubernetes 的多節點排程。
- **離線迭代效率:** 傳統方式交付效率最低；Docker 映象有版本，而且一個命令就可以匯出一個離線包，所以迭代效率高；Docker-Compose、Kubernetes Yaml、Helm 和 KubeVela 需要手工逐個打出映象離線包，複雜架構效率不高，而且手工容易出錯；Rainbond 支援自動化匯出一個離線包，匯入離線環境，可以一鍵升級和回滾，迭代效率很高。
- **客戶環境支援:** 不同客戶有不同的執行環境，交付的包需要根據客戶環境選擇，傳統應用交付方式適合老的一些基礎設施，作業系統版本老，沒辦法安裝執行容器；客戶環境沒有 Kubernetes，也不允許安裝 Kubernetes，可以選擇 Docker 映象和 DockerCompose；Kubernetes Yaml、Helm、KubeVela 和Rainbond 支援有 Kubernetes 的環境。

toB應用私有化交付發展歷程、技術對比和選型

相關文章