作者：京东科技 王晓飞

前言

本文不谈论具体的技术和方案，在对于每一个产品来讲，都有其特殊性存在。单一的产品解决方法并不适合所有的产品。但是我们可以提供一种思路，一种通用方法，甚至我们曾经在某个技术点走的弯路，旨在为各位在离线设计上有更多的案例可循。

对离线的理解

相对于公网应用，可以从公共镜像仓库拉取镜像，比如 Dockerhub，各大云厂商的公共镜像仓库。二进制编译文件，软件包也非常方便的从 github，各种 yum 源中获取。此时应用无论是部署，交付，生产都处于完全流程。那么离线就是用户环境是私有云，专有云用户的生产环境无法访问这些公开资源，并且从安全角度来讲，并不能保证其生产安全。在离线环境交付大型生产项目，一般要有成熟的基础设置（yum 源，镜像仓库，chart 仓库，NTP 服务等）

解决离线交付会减少 SRE 和交付团队试错成本，排障成本。并且在一定程度上能够保持交付环境的一致性。这里举一个场景例子：

我们在 K8S 集群时，会依赖特定的内核版本，那么离线交付工具会自动化的进行内核升级，并且按照统一的配置进行下发。

这样一来，整个环境的所有 OS 的内核版本，配置全部保持一致。

插拔式设计

插拔式设计在现代架构设计并不陌生，所以离线交付中需要考虑插拔式设计。有诸多可以看到的好处是对已有代码架构侵入不多，完全可以依据交付需求进行开关。

比如以下代码完全是判断开关才进行工作：

还有一种重要的考虑点是：数据解藕，即离线设计的实现不能对元数据进行强以来，元数据应该以配置或者模版的方式，在离线真正运行是动态读取。

并且能够依据不同的元数据（配置或者模版）进行执行行为的改变。

依赖感知

依赖模块感知

离线交付是一个链条，需要上下模块感知，并且动态修改配置的方式，传递离线的配置信息。

比如：A 模块需要获取一个镜像，那么在离线模式下，A 模块应该能够感知到离线，并且自动变更获取镜像的地址，指向离线仓库。

系统自动适配

在实际生产中，往往要兼容不同的 OS 或者平台，那么在离线设计时要进行充分的考虑，离线要能够做到自动识别 OS 或者平台，自动的适配合适的离线包。

下图展示了，我们在生产中进行分类的方法：

全自动化离线设计

离线的设计，对于用户或者终端来讲，他们并不关心，主要是交付方为了提升生产效率进行的行为。所以需要在模块与模块之间，组件与组件之间进行无缝对接。

形成全自动化流程。

比如：A，B，C 都依赖离线，那么当离线开启时，A，B，C 模块都能够根据离线的上下文信息自动修改，并且能够做到不中断。

下图中展示了完整的离线设计流程，流程虽然复杂，但是大多数都使用了流水线。并且在真正实现的部分，又可以做到流程化。

对于用户来讲，无需感知这些。

重在流程设计

离线本身不是独立的流程存在，整个离线需要在以下方面进行设计和实现：

1. 文档和培训，用于离线交付的使用手册以及指导手册；

2. 离线包的制作全自动化，使用流水线功能将离线包构建，版本控制，发行就行全自动化控制，减少人工参与；

3. 交付团队和 SRE 团队可以快速的获取离线包。

结论

1. 离线交付是在 ToB，ToG 中非常常见的交付方式；

2. 离线交付理念应该融资在整个架构设计中，而不是将它看成独立的模块功能；

3. 尽可能的使用自动化维护整个离线包；