设为首页 - 加入收藏 ASP站长网(Aspzz.Cn)- 科技、建站、经验、云计算、5G、大数据,站长网!
热搜: 手机 数据 公司
当前位置: 首页 > 云计算 > 正文

ToB应用私有化交付技术发展历程和对照

发布时间:2022-11-23 09:52 所属栏目:124 来源:互联网
导读:由于数据隐私和网络安全的考虑,大多数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 的特性的确解决了很多开发、交付以及其他许多问题,因此 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镜像
 
  中
 
  不支持
 
  不支持
 
  高
 
  容器/K8s
 
  Docker Compose
 
  中
 
  支持
 
  不支持
 
  中
 
  容器
 
  K8s Yaml
 
  中
 
  支持
 
  支持
 
  中
 
  K8s
 
  Helm Chart
 
  中
 
  支持
 
  支持
 
  中
 
  K8s
 
  KubeVela
 
  中
 
  支持
 
  支持
 
  中
 
  K8s
 
  Rainbond
 
  低
 
  支持
 
  支持
 
  高
 
  K8s/容器/服务器
 
  应用交付门槛,传统方式交付门槛最高;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 的环境。
 

(编辑:ASP站长网)

    网友评论
    推荐文章
      热点阅读