toB应用私有化交付发展历程、技术对比和选型

由于数据隐私和网络安全的考虑，大多数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 容器概念迅速的被普及。

在微服务架构场景，需要多个服务或应用一起交付，服务之间有依赖，还有复杂的配置，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 环境一键启动和管理；

综合对比

• 应用交付门槛: 传统方式交付门槛最高；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 的环境。