由于數(shù)據(jù)隱私和網(wǎng)絡安全的考慮，大多數(shù)toB場景的客戶需要私有化應用交付，也就是需要交付到客戶的環(huán)境里，這樣的客戶有政府、金融、軍工、公安、大型企業(yè)、特色行業(yè)等，這些私有化場景限制很多，如何提高私有化應用交付的效率是個難題，本文將介紹，私有化應用交付有哪些技術(shù)？他們都各自有什么特點？私有化應用交付的發(fā)展歷程。

ToB應用私有化交付的困難點

環(huán)境網(wǎng)絡限制，影響交付效率

• 交付實施過程中不能方便查找資料；
• 在交付過程中，交付人員需要跟公司的開發(fā)進行溝通，網(wǎng)絡限制會影響協(xié)作工具的使用，有些客戶環(huán)境甚至不能帶手機，會影響解決問題的效率，環(huán)境越復雜影響越大；
• 在離線環(huán)境內(nèi)，安裝軟件包也沒辦法直接下載，我們需要將安裝文件或配置文件打包成離線包，在客戶環(huán)境導入。由于業(yè)務的復雜性會導致鏡像很多且很大，只能有交付人員帶移動硬盤到客戶現(xiàn)場導入，導致在導入離線包就會花費較多時間。甚至有些環(huán)境只能刻錄光盤在客戶環(huán)境導入，光盤本身存不了太大的包，只能分多個光盤刻錄；

客戶基礎設施差異，需要適配過程

• 在私有化場景，不同客戶的安裝環(huán)境也不一樣，有些使用物理服務器，有些使用虛擬機，不同的虛擬機廠商也有差異。操作系統(tǒng)也各有不同，例如常見的操作系統(tǒng)有CentOS/Debian/Ubuntu/Redhat，當前還有很多國產(chǎn)化操作系統(tǒng)。CPU架構(gòu)也可能不同，有X86、ARM等；
• 資源準備周期長，需要審批流程；
• 交付的應用需要很重的適配過程，要么在公司適配，要么在客戶現(xiàn)場適配；
• 由于環(huán)境差異很大，應用交付完需要完整測試和驗證，需要大量的人力和時間投入；

交付人員的技術(shù)門檻高

• 交付人員需要懂底層硬件和網(wǎng)絡；
• 交付人員需要懂操作系統(tǒng)和系統(tǒng)運維，需要懂服務治理、高可用、安全、性能分析、備份恢復、交付開發(fā)等等；
• 交付人員要能獨立排查交付應用的問題，需要很強的技術(shù)基礎；

定制化交付迭代效率低

• 在定制化交付場景，客戶會參與到開發(fā)過程中，客戶需要看到效果后反饋問題，再持續(xù)迭代，直到客戶滿意，過程中需要頻繁升級產(chǎn)品；
• 如果開發(fā)人員在公司定制開發(fā)，升級過程復雜，溝通低效；
• 如果開發(fā)人員在客戶現(xiàn)場，沒有好的開發(fā)工具和環(huán)境，開發(fā)效率低，人力投入大；

后期維護難度大

• 應用交付完成后，后期需要保障應用運行的穩(wěn)定性，離線環(huán)境遠程沒辦法運維，報警沒辦法發(fā)出來，運維的難度大；
• 產(chǎn)品有bug、一些預期內(nèi)的變更或產(chǎn)品升級都需要出差客戶現(xiàn)場，支持的成本比較高；

傳統(tǒng)應用交付

傳統(tǒng)的應用交付是直接交付二進制的可執(zhí)行文件或軟件包：

• 二進制的可執(zhí)行文件： java 的Jar，Linux 的可執(zhí)行文件，windows的exe等。
• 軟件包： CentOS 使用 RPM 包，Debian 使用 DEB 包，Java Web 使用 WAR 包。

安裝他們都需要先安裝依賴的環(huán)境和基礎軟件，YUM 和DEB 有自己的管理依賴的軟件源，但離線環(huán)境用不了，如果客戶的操作系統(tǒng)不同，還需要另外想辦法解決，運行這類服務為了解決啟動和自動重啟的問題，還需要通過 systemd 或 supervisor 的方式來管理。如果交付單體架構(gòu)的應用傳統(tǒng)應用交付方式還能勝任，但如果是復雜的微服務架構(gòu)，傳統(tǒng)應用交付方式將難以勝任。

在傳統(tǒng)應用交付過程中，管理這些運行環(huán)境和操作系統(tǒng)差異是一個痛點，容器的出現(xiàn)解決了這個問題。

當前云原生技術(shù)應用交付

云原生應用交付主要使用的容器 和 kubernetes相關(guān)技術(shù)。

Docker 鏡像交付

Docker 將業(yè)務和依賴的庫一起打包成 Docker 鏡像，在這個鏡像中包含所有環(huán)境和應用，這樣就可以達成一處打包、到處使用，我們可以將該鏡像在任何支持 Docker 的操作系統(tǒng)上運行。Docker 的特性的確解決了很多開發(fā)、交付以及其他許多問題，因此 Docker 容器概念迅速的被普及。

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

Docker-Compose應用交付

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

對于單機場景docker-compose可以適用，當應用需要高可用或多節(jié)點分布式部署，docker-compose就不能勝任，Kubernetes的出現(xiàn)解決了容器的高可用和分布式調(diào)度問題。

Kubernetes YAML應用交付

在 Kubernetes 中部署業(yè)務我們需要定義 Deployment Statefulset Service 等資源類型，通過調(diào)整副本的方式 Kubernetes 會自動調(diào)度到多個節(jié)點實現(xiàn)業(yè)務高可用，在交付時我們只需要將這些 YAML 資源和 Image 導出，在客戶的 Kubernetes 環(huán)境中部署并交付給客戶。這種交付方式需要客戶環(huán)境有Kubernetes或在客戶環(huán)境安裝Kubernetes。

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

Helm 應用交付

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

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

面向未來的云原生應用模型交付

應用模型強調(diào)以應用為中心的理念，讓開發(fā)者專注在業(yè)務本身，在應用級抽象和包裝底層復雜的技術(shù)，應用模型跟底層基礎設施完全解耦，根據(jù)對接和交付的基礎設施不同，自動轉(zhuǎn)換和適配，真正實現(xiàn)一次開發(fā)，處處自動化部署。

基于OAM的KubeVela應用交付

OAM（Open Application Model） 是一個描述應用的標準規(guī)范。有了這個規(guī)范，應用描述就可以徹底與基礎設施部署和管理應用的細節(jié)分開。通過將應用定義與集群的運維能力分離，可以讓應用開發(fā)者更專注于應用本身，而不是”應用部署在哪“這樣的運維細節(jié)。KubeVela基于OAM實現(xiàn)了應用跨云、跨環(huán)境持續(xù)交付。當前KubeVela對離線場景的應用交付支持較弱。

基于RAM的Rainbond應用交付

Rainbond 是一個云原生應用多云管理平臺，Rainbond 遵循以應用為中心的核心理念，統(tǒng)一封裝容器、Kubernetes 等復雜技術(shù)，將 Kubernetes 資源統(tǒng)一抽象成 RAM（Rainbond Application Model）應用模型，使用戶能非常簡單的使用 Kubernetes，降低用戶使用的門檻，使用戶專注于應用開發(fā)、應用交付和應用運維。

在對于離線交付場景，Rainbond基于RAM可以導出三種離線交付包：

• Rainbond應用模版包，其中包含了復雜微服務架構(gòu)交付的所有要素，支持升級和回滾，但要求客戶環(huán)境安裝Kubernetes和Rainbond；
• 非容器的軟件包，非容器包按照傳統(tǒng)應用交付方式打包，但易用性更好，包中包含了環(huán)境依賴，并采用靜態(tài)編譯，適合大多數(shù)操作系統(tǒng)，使用 Systemd 管理；
• Docker-Compose離線包，支持在標準Docker Compose 環(huán)境一鍵啟動和管理；

綜合對比

• 應用交付門檻，傳統(tǒng)方式交付門檻最高；Docker、Docker-Compose、Kubernetes Yaml、Helm 和 KubeVela交付的門檻中等，因為需要學習會容器和Kubernetes相關(guān)技術(shù)；Rainbond使用最簡單，不需要學習容器和Kubernetes。
• 微服務支持，除傳統(tǒng)應用交付和Docker鏡像，其他方式都支持微服務編排和打包交付。
• 多節(jié)點調(diào)度和自動化運維，Kubernetes Yaml、Helm、KubeVela和Rainbond支持Kubernetes的多節(jié)點調(diào)度。
• 離線迭代效率，傳統(tǒng)方式交付效率最低；Docker鏡像有版本，而且一個命令就可以導出一個離線包，所以迭代效率高；Docker-Compose、Kubernetes Yaml、Helm 和 KubeVela需要手工逐個打出鏡像離線包，復雜架構(gòu)效率不高，而且手工容易出錯；Rainbond支持自動化導出一個離線包，導入離線環(huán)境，可以一鍵升級和回滾，迭代效率很高。
• 客戶環(huán)境支持，不同客戶有不同的運行環(huán)境，交付的包需要根據(jù)客戶環(huán)境選擇，傳統(tǒng)應用交付方式適合老的一些基礎設施，操作系統(tǒng)版本老，沒辦法安裝運行容器；客戶環(huán)境沒有Kubernetes，也不允許安裝Kubernetes，可以選擇Docker鏡像和Docker-Compose；Kubernetes Yaml、Helm、KubeVela 和 Rainbond 支持有 Kubernetes 的環(huán)境。