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

ToB應(yīng)用私有化交付的困難點(diǎn)

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

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

客戶基礎(chǔ)設(shè)施差異，需要適配過程

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

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

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

定制化交付迭代效率低

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

后期維護(hù)難度大

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

傳統(tǒng)應(yīng)用交付

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

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

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

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

當(dāng)前云原生技術(shù)應(yīng)用交付

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

Docker 鏡像交付

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

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

Docker-Compose應(yīng)用交付

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

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

Kubernetes YAML應(yīng)用交付

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

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

Helm 應(yīng)用交付

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

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

面向未來的云原生應(yīng)用模型交付

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

基于OAM的KubeVela應(yīng)用交付

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

基于RAM的Rainbond應(yīng)用交付

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

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

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

綜合對比

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