業務痛點
自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方式，我們隻需要在函數中定義接口，釋出一下馬上就可以使用了。并且函數計算擁有詳細的監控，調用統計等資訊一目了然，通過日志服務收集日志資訊，可以用于後續的分析。
選用的産品