由于數據隱私和網絡安全的考慮，大多數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 容器概念迅速的被普及。

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

Docker-Compose應用交付

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

對于單機場景docker-compose可以適用，當應用需要高可用或多節點分布式部署，docker-compose就不能勝任，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 環境一鍵啟動和管理；

綜合對比

• 應用交付門檻，傳統方式交付門檻最高；Docker、Docker-Compose、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鏡像和Docker-Compose；Kubernetes Yaml、Helm、KubeVela 和 Rainbond 支持有 Kubernetes 的環境。