关于云原生-cloud-native:云原生赋能传统行业软件离线交付

一. 离线交付的痛点

在传统行业，如政府、能源、军工、公安、工业、交通等行业，为了避免数据泄露和运行平安思考，个别状况下网络会采取内外网隔离的策略，以防备不必要的危险，毕竟在平安防护方面，网络物理隔离是网络安全进攻最无效的伎俩，而网络隔离在软件交付过程中，对于内部软件开发厂商来说将会带来一系列的交付难题，也减少大量老本投入。例如：

1. 现场装置部署和验收测试，效率低下

交付过程中须要将应用程序及依赖的所有资源装置到离线客户环境，而客户环境有可能是物理服务器、虚拟机、公有云及 K8s 容器等各种环境，加上离线环境网络的限度，就会导致离线环境装置和部署效率低下。因为装置配置过程简约，容易出错，在最终交付环境中须要从新进行验证测试工作，也须要节约很多工夫。如果部署的是微服务架构的利用零碎复杂性更高，工作量还会加倍。

2. 离线环境定制开发和产品升级，老本高

定制开发须要开发人员投入，老本原本就高，在离线环境须要依据客户反馈继续迭代，迭代过程产品一直降级，每降级一次就要走一次装置部署和验证测试过程，老本很高。如果有些工作必须驻场开发，老本更高。

3. 网络不通，无奈近程运维

交付实现后，利用须要继续运维，保障运行稳定性和性能继续可用，在网络无奈联通的状况下，出任何问题都须要安顿人员现场反对，甚至须要安顿人员长期驻场。

二. 技术选型

上述问题的根本原因是因为，利用零碎的 多环境适配 、 利用装置部署 、 利用降级 、 利用运维 等操作自动化水平不高，须要大量人员手工操作，所以效率很低，解决问题的重点在解决利用治理的自动化。
以后，云原生技术曾经越来越成熟，而云原生技术次要解决的就是利用治理的自动化问题，具体有两种开源实现计划：
1. Rancher+Helm

Rancher 是一款 K8s 管理工具，他提供 K8s 的治理 UI，包治理应用 Helm。对应离线交付的问题，Rancher 能够装置在多种运行环境（物理服务器、虚拟机、公有云），并且提供局部利用自动化运维性能，它能够解决 多环境适配 和 利用运维 问题，而 利用装置部署 和 利用降级 问题能够通过 Helm 包解决。

2. Rainbond+ 利用模版

Rainbond 是“以利用为核心”的利用治理平台，利用模版是 Rainbond 对利用打包的计划，Rainbond 提供利用的全生命周期治理（利用开发、利用编排、利用交付和利用运维）。Rainbond 能够部署到各种运行环境上（物理服务器、虚拟机、公有云），还能够部署到已有 K8s 集群和 Ranchar 上，解决客户 多环境适配 问题；Rainbond 提供利用运维面板解决 利用运维 问题，应用比较简单，不须要懂容器概念；Rainbond 的利用模版是一个亮点，只有在 Rainbond 上运行起来的利用就能够一键公布成利用模版，简化了利用模版的制作，而且利用模版能够导出离线包，特地适宜离线环境的 利用装置部署 和 利用降级。

上面别离比拟一下两个计划

Rainbond 相比 Rancher 最大的长处就是易用性，不须要学习 K8s 和容器相干技术和概念，另外，Rainbond 提供的一体化开发环境和模块编排性能，能大幅度提高定制开发的效率。Rancher 最大的长处是齐全兼容 K8s 体系，如果理解 K8s 能很快上手。

Helm 和利用模版比拟

Rainbond 的利用模版 跟 OAM 的设计思路完全一致，“以利用为核心”的设计理念，屏蔽掉容器基础设施的复杂性和差异性，为平台的使用者带来低心智累赘的、标准化的、统一的利用治理与交付体验。

综合比照，在离线交付场景 Rainbond+ 利用模版的计划劣势显著，上面咱们结合实际例子，来解说 Rainbond+ 利用模版交付离线客户的整个过程。

三. 应用 Rainbond 利用模版进行离线环境的利用交付

基于 Rainbond 进行离线环境的利用交付，只需将开发环境已开发好的业务公布至利用市场，基于利用市场导出利用模板的离线包，在交付环境中进行导入操作，导入后基于利用市场 一键装置 即可主动运行。

事后筹备环境

• 领有两套 Rainbond 集群，模仿开发环境及交付环境(开发环境为在线环境，交付环境为离线环境)。
• 开发环境装置，参考 在线装置 文档；
• 交付环境装置，参考 离线装置 文档；
• 领有 U 盘、光盘等离线环境下利用模板离线包传输介质。

1. 业务部署
整个流程始于开发环境，咱们首先须要将业务搬迁至 Rainbond 之上。在开发环境基于部署本人的业务，能够反对源代码或是镜像。以后以 Spring Cloud 微服务框架 Pig 为例，部署参考 SpringCloud Pig 在 Rainbond 部署及利用制作。

2. 利用公布

将开发测试环境已开发实现的利用公布至外部组件库：点击利用左侧导航栏 公布 按钮，抉择 公布到组件库 ，该过程须要 新建利用模板，利用模板定义了以下信息:

创立利用模板后定义利用公布版本：

公布组件模型配置：

公布插件模型信息：

要公布的利用中其组件携带有插件时，会进行展现并在公布过程中追随组件公布。

所有信息配置结束后，点击 公布 按钮进行公布，业务开发过程中定义的组件间依赖关系、环境配置、长久化存储、插件、运行环境及上述定义的所有信息都将会被打包公布。

3. 利用导出

将利用模板进行本地化导出，在首页 利用市场 中找到已公布的利用，点击最初方 扩大 按钮，抉择 导出利用模板 ，抉择利用版本后点击 利用模板标准 下的导出按钮，导出过程齐全自动化，待导出实现后点击 下载 按钮即可将利用模板下载至本地，保留至 U 盘等挪动存储设备中，带到离线交付环境中去。

接下来进入离线交付流程，交付人员携带着装有离线包的 U 盘等挪动存储设备，开始导入利用模版。

4. 利用导入

应用已导出的利用模板在交付环境中导入，点击利用市场界面的 离线导入按钮 ，抉择本地的利用模板上传，上传完毕后抉择 导入范畴： 企业或团队，企业为以后交付环境所有人可见，团队为指定团队下的人员可见；点击 确认导入 即进入自动化导入步骤。

5. 一键部署

利用导入后点击 装置 按钮在以后交付环境即可一键部署该业务零碎，该环境业务运行环境与开发环境完全一致，到此实现离线环境下的软件交付。

6. 增量降级

软件在更新迭代过程中须要进行某些模块的降级，进行此类降级时即可应用增量降级来节俭公布及导入导出工夫。

要达成增量降级的成果，须要从新进行 利用公布 操作，抉择之前已创立的利用模板，批改版本号，如之前版本设置为 2.9，则此次公布设置为 3.0。

在 利用公布 步骤抉择须要进行降级的组件进行公布，而不须要抉择所有组件。公布实现后，导出新版本的利用模版离线包，在交付环境中再次导入。

交付环境导入后，平台会对利用模板不同版本进行比照，并通过利用拓扑图中的 待降级选项 提醒用户进行降级。展现版本间属性变更状况，用户抉择须要降级的版本进行降级即可，平台将主动执行降级操作，变更组件构建版本。

降级过程中不会变动环境配置类信息，这类信息须要人为改变才会失效：

• 环境变量的值
• 配置文件的内容
• 长久化存储

7. 一键回滚

在降级版本上线后出现异常状况须要回滚时，平台提供了一键回滚性能，在 降级记录 界面抉择对应记录点击 回滚 按钮即可对降级操作进行回滚。

在回滚的过程中，新增组件并不会被删除，如需变更，须要人为操作。

8. 利用运维性能

软件产品交付实现当前须要进行长期的运维，在运维层面，交付人员须要思考服务的可用性、可伸缩性、资源监控，Rainbond 提供了诸多运维性能，例如：

• 服务性能剖析

  通过 Rainbond 插件机制扩大性能剖析性能，服务实时性能剖析插件运行在指标剖析服务同一个网络空间内，监控网卡的流量来统计分析服务的工作性能，对服务自身的工作流程和性能无影响，收集服务的均匀响应工夫，吞吐率等次要指标。

• 资源监控报警

  基于 Prometheus 对平台及业务进行监控，基于 ETCD 动静发现 须要监控的 targets，主动配置与治理 Prometheus 服务。

• 实例伸缩

  对服务组件进行垂直伸缩或程度伸缩，在流量高峰期灵便进行扩容。

• 网关治理

  利用网关反对灰度公布和 A / B 测试性能。

四. 场景拓展

下面的例子次要针对常见的离线软件交付场景，但在实在的离线交付场景中，还可能存在以下场景，如：

• 离线模块定制，每个客户交付的模块不肯定，依据须要在客户现场开启或敞开模块，或者模块编排。
• 离线定制开发，在离线场景下进行残缺的软件开发过程，包含源码治理、源码编译、开发测试环境治理、团队合作、版本公布流程等。

下面两个性能定制场景，通过 Rainbond 也能够反对，大家可先自行摸索。或者关注公众号「好雨云」，后续会公布上述场景的具体教程。

五. 总结

本文咱们剖析了离线交付场景的问题，比照了可能的技术计划，并应用一个例子残缺解说离线交付全过程，整个过程自动化水平很高。应用 Rainbond 进行离线交付必定能够提高效率，但到底在哪些方面进步咱们的效率，我再总结一下：

• 离线环境利用零碎一键导出和导入

  交付过程中只须要携带基于 Rainbond 导出的利用模板离线包在交付环境进行导入，即可一键装置整套业务零碎。

• 开发环境和离线环境完全一致

  Rainbond 屏蔽了底层环境的差别，基于利用模板进行交付，模板对利用的运行环境、依赖关系进行打包，开发环境和离线环境完全一致，不须要进行重复性测试。

• 一体化客户定制环境

  软件交付过程中，不同的客户会有不同的定制需要，也就意味着须要为不同客户开发不同的模块，这些定制的模块在不同我的项目中都不尽相同，通过 Rainbond 提供的利用编排，就能够针对不同客户编排和开启不同功能模块；如果须要定制开发，就可基于交付环境已部署的 Rainbond 间接进行离线代码开发工作，包含源码编译、配置组件运行环境等，在交付环境中实现所有定制工作。

• 离线环境客户继续交付

  对于我的项目施行团队而言，在施行过程中须要一直将 新性能、缺点修复 等疾速落实到交付环境或用户手中，传统的继续交付过程中，离线环境下须要交付人员驻场，手动执行更新上线操作，该过程不仅减少了交付工夫，且长期的手动执行操作会减少部署的危险；而 Rainbond 的继续交付能力，可能实现利用后续的 增量导入、导出和版本升级，可能带来以下劣势:

  • 通过自动化形式实现，无效缩短代码提交到部署上线的工夫。
  • 软件在整个生命周期内都处于可部署降级的状态。
  • 简化降级步骤，使软件版本更加清晰。
  • 让交付过程成为可预期的、可视化的过程。

• 离线环境下自动化运维

  服务高可用，自容错和自复原机制，缩小人工运维，进步业务零碎稳定性。

六. 对于 Rainbond

Rainbond 是一个开源的云原生利用治理平台，应用简略，不须要懂容器和 Kubernetes，反对治理多个 Kubernetes 集群，提供企业级利用的全生命周期治理，性能包含利用开发环境、利用市场、微服务架构、利用继续交付、利用运维、利用级多云治理等。

已有上百家企业应用 Rainbond 治理要害业务场景，涵盖制作、能源、高校、公安、政府、交通、军工等十几个行业。客户有 京东方、百胜中国、中航信、中公高科等大型企业。