查看下篇文章，點擊這裡。
以下是直播內容精華整理，主要分為五個部分：
一、關於遷移那些事；
二、腳本時代遷移；
三、雲API實現遷移自動化；
四、利用阿里雲原生服務構建遷移平臺；
五、未來展望。
一、關於遷移那些事
一提到遷移，大家可能想到的就是複雜，正如《企業遷雲之路》這本書中寫的那樣，上雲需要從戰略、組織、風險、財務和技術等方面統籌思考，才能保證方向正確，並通過嚴格的項目管理對業務產生助力。
雲計算對於企業T架構的衝擊和變革是非常大的，因此需要一個較長的觀察期，以便對業務和技術有足夠的理解和思考。企業如果要上雲，至少要從業務技術能力、項目開發能力和數據應用這三個方面綜合考慮應怎樣逐步遷移、哪些不能或者不需要遷移、遷移的時候是複製還是重構。上雲前企業在思考什麼，決定了上雲後企業能夠獲得什麼。
下圖是Gartner在2018年發佈的關於雲計算的重複度曲線，預測雲遷移將在4-5年內發生，私有云遷移是在最近兩年內發生，該預測與目前的實際狀況比較類似。注意圖中的MultiCloud同樣被預測在2-5年內出現，也印證了混合雲的興起。正是有了多雲的出現，用戶才有意願將業務在不同雲之間進行切換，雲遷移的重要性才得以凸顯。
Gartner對運管平臺定義的十大模塊中，遷移和容災被單獨列為一個模塊，為了方便企業管制的一些需求，多數企業均會建立雲管平臺，也為多雲的混合調度提供了很大的便利。但是雲管平臺實際上是在控制流做管理，數據和通訊還是用戶去做的，無法實現從A雲到B雲的靈活遷移；而且在傳統遷移的時候往往需要專業人員來幫助用戶使用，但是在雲遷移的概念下，遷移和容災的行動，應該是一個自助的行為，那麼就對雲遷移提出了更高的操作簡便性，使得普通用戶也能便捷的使用。
二、腳本時代遷移
（一）遷移方式的選擇
從下圖中我們可以看到，遷移的方式有很多，比如重裝、Re-Host、重構等等，而在這些方式中，最經濟、最快的方式就是Re-Host方式。
如果想用Re-Host方式的話，從遷移的文件存儲級別來看，我們有下面2中方法：
（1）文件級別
該方式缺陷有一個缺陷，是需要提前在雲上把待遷移主機建立起來，但是由於線下的主機系統可能比較老，雲上不一定能找到完全對應的版本，那麼在這種情況下進行遷移的時候，很可能影響應用的穩定性問題。
（2）塊級別
塊級別的遷移方式和我們的需求是比較接近的，但是從市面上的產品來看，都是需要在遷移過程中遠端停機，會對用戶的業務穩定性產生很大的影響；另外就是這些方式需要大量的手動操作，在雲遷移的方式下，其實並不適用。
（二）雲遷移與傳統遷移的區別
雲遷移與傳統遷移的最本質區別在於API接口的利用：在物理環境下，我們很難利用命令或者相關的API控制服務器來完成遷移工作，但是在雲的環境下，一切被虛擬化，所以很容易的調用雲平臺的計算、存儲、網絡等資源，從而能夠更快速的幫助用戶將應用遷移到雲端。所以，API的利用是一個雲原生遷移平臺要具備的第一個特性。
（三）雲遷移誕生之緣
如下圖所示，我們團隊在實際業務中發現了雲遷移的潛在需求，進而基於雲原生的方式，開發了這樣一款產品，大大提升了用戶的遷移效率與安全性。
三、雲API實現遷移自動化
（一）雲遷移的主要技術與架構
當雲API和遷移流程能夠完美結合的時候，對遷移效率的提升非常明顯：用雲API實現遷移自動化的整個過程比人工方式快10倍以上，比其他工具要快5倍以上。
如果想要用雲原生API實現遷移自動化，對於工具應該至少滿足以下6點要求：
- 面向小白用戶的設計，步驟簡單，界面清晰，無須培訓就可以開始使用；
- 實現在線“熱遷移”效果，即遷移不影響業務；
- 能夠支持私有云、阿里雲公有云、專有云平臺；
- 遷移過程中無須進入命令行操作，實現全自動、一鍵式遷移效果；
- 微服務設計，模塊之間的通訊全部使用REST接口，不允許跨模塊訪問數據庫；
- 對外提供REST API接口，能夠被第三方產品進行整合。
雲遷移過程中，想要滿足以上幾點需求，需要實現的關鍵技術有如下：
（1）塊級別複製
塊級別全量、增量複製，保證業務連續性，塊級別差異捕獲。業務系統可以整體恢復、無須重裝或應用改造。
（2）數據傳輸
數據的傳輸支持多種傳輸協議和方式，能夠支持大容量窄帶寬傳輸方式，支持傳輸到存儲設備。
（3）API接口
支持遷移到多個雲平臺，使用雲原生API接口，形成高度自動化流程，使用雲原生資源，在遷移過程中無須轉換，提高效率。
（4）驅動適配
通過對驅動注入，保證操作系統可以在目標平臺正常啟動，規避在源端安裝驅動的風險。
只有以上幾個關鍵技術被滿足之後，我們才能建立一個面向雲原生方式的遷移平臺。下圖所示是單機版本的業務邏輯架構。
根據業務邏輯的抽象將模塊分為三大類：源端代理、遷移調度管理和雲平臺代理端。其中，源端代理主要負責將塊數據用全量和增量的方式讀出，雲平臺代理端主要負責接收數據以及通過API調度雲平臺的資源配合遷移流程，而遷移調度管理平臺主要負責整個遷移調度工作，降低整個遷移工作的複雜性。
三個模塊中，除了源端代理無法部署在容器上，前遷移調度管理和雲平臺代理端都部署在容器上。底層上，我們即可以對接雲平臺，也可以對接傳統存儲，就解決了在大容量、窄帶寬下的遷移工作。架構中的每個模塊都是微服務架構，包括API與Worker服務，模塊都是異步調用為主，滿足了調用的靈活性和可擴展性。
其中，對於每個模塊內的技術棧如下圖所示。
這裡特別介紹下關於存儲抽象層的設計，在這裡我們實際上用到了軟件存儲控制層的概念。一開始存儲控制層的作用是將不同型號存儲的API接口進行統一的管理，能夠讓應用層和編排層使用統一的接口去調度不同的存儲。但是，如下圖所示，在設計該平臺的時候，我們做了一個創新的操作，將雲平臺也變成了一個存儲，因此上層的應用層和編排層就能像普通的應用層一樣使用阿里雲，我們只管理到控制流，數據流還是之前的路徑。除此之外，我們還能管理離線的設備，就解決了傳統存儲和雲存儲統一的問題。
（二）利用雲原生資源進行數據同步
數據同步就是將源端的數據同步到阿里雲的EBS上，並且每次同步之後會進行EBS快照，方便進行驗證，完整的過程如下圖所示。在該過程中，全量同步與增量同步進行配合，提高了同步效率，快照技術保障了數據的安全性。
（三）利用阿里雲API將EBS變為ECS
在阿里雲的接口裡面其實並沒有可以直接將EBS變為ECS的API，我們利用了主機鏡像的方式來實現了該功能，具體的流程如下圖所示。在這種方式下，無論是數據同步還是啟動主機的過程，對源端業務系統都沒有造成任何影響。實際上該過程類似於容災體系中的容災接管的過程，通過這種方式，大家可以對上雲之後雲主機的穩定性經過充分的驗證之後再去完成同步增量等，進而完成完整的遷移過程。
（四）阿里雲接口需求
從遷移的角度來講，在各個階段對阿里雲的接口需求如下圖所示。正式因為有了如下接口，整個遷移的過程才會更加的快速、便捷。
