跳到主要内容

微服务架构离线交付

离线交付的痛点

在传统行业,如政府、能源、军工、公安、工业、交通等行业,为了防止数据泄露和运行安全考虑,一般情况下网络会采取内外网隔离的策略,以防范不必要的风险,毕竟在安全防护方面,网络物理隔离是网络安全防御最有效的手段,而网络隔离在软件交付过程中,对于外部软件开发厂商来说将会带来一系列的交付难题,也增加大量成本投入。例如:

环境网络限制,影响交付效率

在交付过程中不能方便查找资料,网络限制会影响协作工具的使用,有些客户环境甚至不能带手机,会影响解决问题的效率,环境越复杂影响越大;交付完成后,应用需要持续运维,保障运行稳定性和功能持续可用,在网络无法联通的情况下,出任何问题都需要安排人员现场支持,甚至需要安排人员长期驻场。

客户基础设施差异,需要适配过程

在私有化场景,不同客户的安装环境也不一样,有些使用物理服务器,有些使用虚拟机,不同的虚拟机厂商也有差异。操作系统也各有不同,例如常见的操作系统有CentOS/Debian/Ubuntu/Redhat,当前还有很多国产化操作系统。CPU架构也可能不同,有X86、ARM等;因此交付的应用需要很重的适配过程,要么在公司适配,要么在客户现场适配。由于环境差异很大,应用交付完需要完整测试和验证,需要大量的人力和时间投入;

交付人员的技术门槛高

交付人员需要懂底层硬件和网络、操作系统和系统运维,需要懂服务治理、高可用、安全、性能分析、备份恢复、交付开发等。

交付技术发展历程

交付技术大致有以下三个发展阶段:传统应用交付->云原生技术应用交付->面向未来的云原生应用模型交付。从传统软件包的交付模式,逐渐过渡到以 Docker、Kubernetes 为代表的云原生技术交付阶段。

而未来,一定是以应用为中心的交付模式,在应用级抽象和包装底层复杂的技术,使得应用模型跟底层基础设施完全解耦,根据对接和交付的基础设施不同,自动转换和适配,真正实现一次开发,处处自动化部署。

1. 传统应用交付
  • 二进制的可执行文件: java 的Jar,Linux 的可执行文件,windows的exe等。
  • 软件包: CentOS 使用 RPM 包,Debian 使用 DEB 包,Java Web 使用 WAR 包。

安装他们都需要先安装依赖的环境和基础软件,YUM 和DEB 有自己的管理依赖的软件源,但离线环境用不了,如果客户的操作系统不同,还需要另外想办法解决,运行这类服务为了解决启动和自动重启的问题,还需要通过 systemd 或 supervisor 的方式来管理。如果交付单体架构的应用传统应用交付方式还能胜任,但如果是复杂的微服务架构,传统应用交付方式将难以胜任。

在传统应用交付过程中,管理这些运行环境和操作系统差异是一个痛点,容器的出现解决了这个问题。

2. 云原生技术应用交付

云原生应用交付主要使用容器和 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,学习和使用的门槛太高。抽象的应用模型是一个解决方案。

3. 面向未来的云原生应用模型交付

应用模型强调以应用为中心的理念,让开发者专注在业务本身,在应用级抽象和包装底层复杂的技术,应用模型跟底层基础设施完全解耦,根据对接和交付的基础设施不同,自动转换和适配,真正实现一次开发,处处自动化部署。

基于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 环境一键启动和管理;

使用 Rainbond 实现微服务架构的离线交付

使用 Rainbond 交付流程如下图所示,当在开发环境开发好不同的微服务架构应用后,经过完整测试验证功能没有问题后。即可以应用模版的形式一键发布至本地应用市场,形成 1.0 版本。接下来可以将其导出完整的 Rainbond 应用模版包。其中包含了复杂微服务架构交付的所有要素。

接下来在客户环境一键导入该应用模版包,通过一键安装即可完成交付。当在客户环境出现问题时,还可以在开发环境修改后,发布 1.1 版本。重复以上流程,用户即可完成应用的一键升级。后续也可以基于该应用模版实现整个应用的回滚。

offline-delivery

操作步骤

准备工作

  1. 拥有两套 Rainbond 集群,模拟开发环境及交付环境(开发环境为在线环境,交付环境为离线环境)。

  2. 开发环境安装,参考快速安装,交付环境安装,参考离线安装

  3. 在开发环境已有正常运行的应用,可参考快速入门

制作应用模版

  1. 在应用拓扑图页面左侧,选择 发布->发布到组件库, 即可进入模版设置页面。各个参数详细说明参考附录1: 模版设置页面参数说明

  2. 新建一个应用模版,可选择发布范围为企业,设定好发布的版本,点击提交,接下来将会同步所有组件的镜像,推送到本地镜像仓库中。同步完成后,点击确认发布,即发布完成。接下来在 平台管理->应用市场->本地组件库,即可看到发布好的应用模版。

caution

注:仅有企业管理员可以看到平台管理按钮。

导出应用模版

  1. 平台管理->应用市场->本地组件库中,在刚刚发布完成的应用模版最右侧,选择导出应用模版,你可以选择需要导出的版本,和导出哪种类型的包。这里我们选择应用模型规范,点击导出。这个包将包含应用完整的运维特性,用于持续交付和升级。

  2. 导出完成后,将应用模版下载到本地,保存至U盘/光盘等移动存储设备中,带到离线交付环境中去。

离线环境中交付应用

  1. 在已经部署好 Rainbond 的离线环境中,我们先打开平台管理->应用市场,选择离线导入,上传刚刚下载好的应用模版。上传完成后,点击确认导入

  2. 等待导入完成后,会自动跳转回应用市场。在导入完成的应用模版后,点击安装,即可一键部署该业务系统,该环境业务运行环境与开发环境完全一致,到此完成离线环境下的软件交付。