作者：京東科技 王曉飛

前言

本文不談論具體的技術和方案，在對於每一個產品來講，都有其特殊性存在。單一的產品解決方法並不適合所有的產品。但是我們可以提供一種思路，一種通用方法，甚至我們曾經在某個技術點走的彎路，旨在為各位在離線設計上有更多的案例可循。

對離線的理解

相對於公網應用，可以從公共鏡像倉庫拉取鏡像，比如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. 儘可能的使用自動化維護整個離線包；