業務痛點
- 自2016年開發遷移工具主要面向私有云環境，但是隨著公有云用戶越來越多，我們迫切的希望以一種SaaS形態提供給所有有公有云遷移的客戶使用。快速的將工具平臺化、並且具有擴展性、可靠性是我們在轉型過程中深入思考的問題。同時，如何在不增加人力的情況下，完成平臺的運維變得尤為重要。所以使用雲原生服務方式去構建我們的平臺是唯一的捷徑。
- 傳統行業用戶從傳統環境過渡到雲平臺時，上雲往往是第一步要做的。但是大部分客戶是想遷移而不敢遷移，究其原因就是擔心遷移過程對業務系統的影響，遷移人員對原架構和雲平臺的技術能力，遷移週期管控，遷移成本，以及遷移後業務系統的穩定性。
- 用戶在遷移過程中最關心的問題是：業務連續性如何保障？怎麼可以自動智能適配不同平臺的驅動？怎麼減少人員干預帶來的風險？怎麼控制遷移週期和成本？怎麼可以批量高效遷移？失敗是否可以回退？
解決方案
解決方案邏輯圖
方案細節：
上雲需求的產生——從工具到SaaS
從2016年開始，我們團隊開發了針對私有云整機遷移的工具HyperMotion，這款工具基於雲原生API接口開發，實現高度自動化的遷移。隨著時間的發展，越來越多的企業選擇將一部分負載運行在公有云上，混合雲的形態越來越多。公有云遷移的需求也隨之增多。所以，我們在2019年初增加了對阿里雲遷移的支持。不同於私有云的遷移，如何讓我們的客戶更快的進入遷移流程，不把時間花在介質下載和安裝的步驟呢？SaaS化是解決這個問題的最佳選擇。
雲遷移的痛點
2016年開始，在建設金融行業私有云建設過程中，我們發現遷移是私有云建設中非常強烈的剛需。同時，對後續雲平臺擴容起著至關重要的作用。但是用戶在上雲時卻謹小慎微，總結其原因主要有以下幾個方面：
- 如何保障業務在上雲過程和上雲運行的穩定性
在任何行業中，穩定、可靠是當仁不讓的第一原則，對於關乎民生的金融行業更是如此。所以在實際雲平臺建設過程中，原有業務系統上雲時往往受到的阻力最大。究其原因就是在上雲過程中沒有一套完整的、科學的方法論及工具讓用戶打消對上雲的顧慮。
- 業務連續性
在上雲過程中，如何保障業務系統連續性是用戶尤為關注的一點，任何客戶都希望在遷移過程中全程無感知，業務中斷為0。但是在實際從雲下到雲上遷移過程中，是一個極其複雜的建設過程中，如果沒有強有力的工具支撐，很難做到這一點。
- 如何選擇上雲方式
用戶在上雲方式上面臨多種選擇，常見的七種策略：重新託管(Rehosting), 更換平臺（Replatforming), 重新購買(Repurchasing), 重構(Refactoring/Re-architecting), 退役（Retire), 保留(Retian)。那麼對於傳統行業客戶最簡單、高效的就是Reshot方式。傳統客戶由於歷史原因，積累下大量的業務系統，這些老舊的業務系統只能勉強維持運行，可能由於開發廠商的消失，根本談不到重新部署、升級和新功能開發。所以在實際遷移時，對應用本身依賴程度越低越好。所以在眾多遷移方式中，Rehost成為快速上雲的不二選擇。Rehost方式通常是從操作系統底層即塊級別實施整體搬遷，對應用影響最小。同時，用戶在快速上雲後，可以逐步改造自己的業務系統，逐步將應用過渡到雲原生方式。
- 遷移可驗證，失敗可回退
為了保障遷移後的穩定性，在正式將業務切換到雲平臺前，需要進行必要的驗證工作。驗證過程中，不能影響原有業務的運行狀態。如果遷移失敗，需要快速的將系統回滾至原有系統。
- 如何減少人員依賴和人為干預的風險
遷移涉及業務系統、涉及原架構、目標雲架構的技術特性，因此對人員技術能力要求較高；然而過多人為干預又會導致諸如業務影響、週期控制、成本居高的問題。因此，將遷移過程工具化，將技術邏輯抽象處理並融合到操作流程中，以此降低人員技術能力要求，通過遷移工具底層運行最大化自動化遷移過程。
如何基於雲原生資源進行雲遷移
在開發之初，我們堅持使用雲原生的方式構建我們整個遷移流程。我們對雲原生使用方式包括：雲原生的API和雲原生資源。
使用雲原生API，能夠大幅度簡化繁瑣的遷移流程，減少用戶操作，降低出現錯誤的概率。並且通過對遷移流程的抽象，使遷移軟件能夠支持多雲平臺。在對接一朵新的雲平臺時，開發週期僅為2周。
使用雲原生的資源，能夠減少在遷移過程中資源轉換的時間損耗。在遷移過程中，將數據直接存儲在雲平臺塊存儲上，之後能夠快速的將存儲轉換為雲主機，達成遷移中驗證和切換的需求。
下面以遷移中最常見的兩個流程：數據同步和啟動主機來說明對雲原生資源的使用方式。
- 數據同步
為了實現Rehost的效果，需要使用塊級別的差量同步技術來滿足整機遷移的效果。如圖所示，我們分別在10點和12點進行了同步，10點同步時為第一次同步數據，所以我們會同步磁盤中的所有有效塊。在阿里雲側，我們利用阿里雲EBS作為接收端，創建一個與源端同樣大小的雲硬盤，將該EBS掛載到雲代理同步的ECS上後，將數據直接寫入該EBS設備上。在10點完成後，這塊EBS設備的狀態與源端數據狀態一致。在同步完成後，遷移平臺會調用EBS快照接口，進行快照，保留當時狀態。後續我們可以使用該時間點對遷移後的系統進行驗證。
在12點同步時，通過對10點到12點變化塊序列的記錄，同步邏輯發現系統刪除了兩個塊，並新增了一個塊。同步程序在接收端的EBS上也執行刪除兩個塊，並複製一個塊的動作，此時磁盤的狀態又和源端磁盤保持了一致。完成後再次執行EBS快照操作。此時用戶可以使用10點和12點的快照進行遷移驗證操作。
- 啟動主機
啟動主機的過程其實就是由雲平臺的塊存儲轉換為雲主機的過程。由於阿里雲目前並不支持直接用雲硬盤直接作為系統盤啟動，所以在阿里雲處理上，我們採用了其他策略。整個流程如下：
第一步：根據用戶選擇的快照時間點進行主機啟動。第二步：通過驅動修復主機鏡像和用戶選擇時間點的快照，重組成用於驅動修復的鏡像。第三步：使用該鏡像模板啟動主機後，進行驅動修復。驅動修復主要是解決源端環境和目標環境的驅動差異、符合目標平臺管制需求。例如：在KVM平臺上需要使用virtio驅動，在雲平臺上使用DHCP方式獲取IP地址。第四步：對修復好的磁盤再次進行快照，重組用於啟動的遷移主機鏡像。第五步：進行主機啟動，完成遷移驗證或啟動流程。用戶可以登錄修復後的主機，進行驗證。此時，源端主機仍然處於運行狀態。
從工具到平臺
在工具階段，我們為用戶提供產品時往往以私有化方式部署為主。用戶通過鏡像方式下載安裝介質到本地環境進行安裝。我們提供的介質大小在3.6G左右，由於目前很多網盤都有速度限制，所以用戶往往下載好需要幾個小時。平臺化後，用戶無須再在將時間花在下載介質的時間上，而可以快速的進入整個遷移流程。
在單機版本軟件上，往往都是一個用戶進行操作，並無太多的併發壓力。到了SaaS版本，首先需要實現多租戶模式，意味著軟件需要承受更多的併發壓力，這就要求平臺具備高度擴展能力，滿足用戶量激增的壓力。
原有單機版本併發遷移時，需要用戶手動對雲代理節點進行擴容，在SaaS版本里為了更好的用戶體驗，雲代理節點也應當具備彈性擴展能力。研發團隊需要用最短的時間將單機版本改造為線上SaaS版本。由於人力資源的限制，實施團隊需要兼顧私有項目和線上運維，這就要求平臺穩定、高可靠、易運維。所以對雲原生的應用就變得尤為關鍵。
在由工具向平臺改造過程中，必須要解決以下幾個問題：
- 應用本身改造
為了支持多租戶的需要，我們增加了單獨的用戶管理模塊，來滿足多租戶的需要；同時為了滿足線上運營的需求，還針對性的開發了運營模塊來支撐不同角色用戶的操作需求。在原有單機版本中由於客戶在實施過程中基本都是本地局域網，所以源端和控制端通訊時不受制約，但是SaaS平臺上線後。為了降低用戶網絡配置成本，需要將源端和控制端的通訊變為單向。即源端可以訪問控制端，無須控制端直接與源端連接。
- 平臺部署和運維
在阿里雲服務選擇上，我們儘量選擇雲原生的服務來滿足我們的需求，通過價格比對，尋找適合我們的方案。使用雲原生服務另外的一個好處就是服務之間的關聯性，幾乎不需要複雜配置就可以完成，例如：監控、日誌等運維支持服務。平臺上線初期採用按量計費的方式，尋找到規律後，再轉為包年包月或改為資源包購買方式。我們的所有服務都是以容器化方式進行部署，所以在選擇Kubernetes託管服務商，我們對比了自建、專有版本、託管版本和Serverless版本的價格。最初為了節約成本，我們選擇了Serverless版本，Serverless版本使用按量計費的方式，是集中模式下性價比最高的，但是隨著平臺上線後，我們在使用雲原生監控時發現Serverless版並不支持插件的安裝，導致監控和告警服務無法使用。最終，基於成本的考慮，我們選擇了託管版本，能夠滿足我們的需求。
- CI流程的改造
在之前的CI流程，我們只需要提供鏡像文件（QCOW2）和ISO文件。在SaaS平臺上線後，我們的流程出現了很大的變化。一方面我們搭建了三套環境：本地的Kubernetes、阿里雲上的QA和生產環境。本地環境採用及時更新的策略，研發代碼Review入庫後，立即會更新到研發環境中。而QA和線上環境採用手動部署方式，從特定的代碼分支進行部署。在鏡像倉庫選擇上，線下環境使用Harbor，而線上環境直接使用阿里雲的鏡像倉庫服務。CI控制採用Jenkins觸發方式，所有腳本都使用代碼倉庫進行統一管理。
上雲價值
得益於雲原生的使用，我們從7月份提出需求，9月份在阿里雲上線內部測試版本，到今年春節之後正式邀請客戶進行使用，並且今年春節後推出了“零接觸”雲遷移免費3個月時間。能在這麼短的時間內，將一款單機版本的軟件具有多用戶併發支持能力的SaaS平臺，雲原生提供的支持功不可沒。
- 在沒有增加人力的情況下，運維壓力並沒有過多增加，雲原生的方式提供天然的容災、備份服務，使得運維人員很輕鬆的簡單配置就可以實現傳統運維需要大量安裝和配置的效果。
- 利於成本控制，具有高度可擴展性。由於遷移本身是具有一定專業性的產品，用戶以企業用戶為主。所以客戶增長的速度可能不會像C端增長明顯，所以採用按量計費的方式可以更精細化的控制成本。同時，基於雲的擴展性，用戶量一旦激增後，也可以輕鬆應對。
- 函數計算服務的使用，簡化了開發成本，運維成本直接降為零。目前將License服務使用函數計算提供，如果使用傳統方式構建，我們至少需要http服務端、定義接口等開發，再加上部署上打包成容器、部署等操作，成本很高。但是如果使用阿里的函數計算服務，天然支持http trigger方式，我們只需要在函數中定義接口，發佈一下馬上就可以使用了。並且函數計算擁有詳細的監控，調用統計等信息一目瞭然，通過日誌服務收集日誌信息，可以用於後續的分析。
選用的產品
閱讀更多 孫琦Ray 的文章
