趨勢
雲原生發展趨勢
雲原生（Cloud Native）是最近幾年非常火爆的話題，在2020年7月由信通院釋出的《雲原生發展白皮書（2020）年》明确指出：雲計算的拐點已到，雲原生成為驅動業務增長的重要引擎。我們不難發現雲原生帶給IT産業一次重新洗牌，從應用開發過程到IT從業者的技術能力，都是一次颠覆性的革命。在此基礎上，出現了基于雲原生平台的Open Application Model定義，在雲原生平台基礎上進一步抽象，更加關注應用而非基礎架構。同時，越來越多的公有雲開始支援Serverless服務，更加說明了未來的發展趨勢：應用為核心，輕量化基礎架構層在系統建設過程中的角色。但是無論如何變化，IT整體發展方向，一定是向着更有利于業務快速疊代、滿足業務需求方向演進的。
2020年9月，Snowflake以每股120美金IPO，創造了今年規模最大的IPO，也是有史以來最大的軟體IPO。Snowflake利用雲原生方式重構了資料倉庫，成功颠覆了行業競争格局。這正是市場對雲原生發展趨勢的最佳認可，是以下一個雲原生颠覆的領域會不會是在傳統的容災領域呢？
我認為在建構雲原生容災的解決方案上，要以業務為核心去思考建構方法，利用雲原生服務的編排能力實作業務系統的連續性。
2、資料安全性
AWS CTO Werner Vogels曾經說過：Everything fails, all the time。通過AWS的責任共擔模型，我們不難發現雲商對底層基礎架構負責，使用者仍然要對自身自身資料安全性和業務連續性負責。
我認為在雲原生趨勢下，使用者最直接訴求的來自資料安全性即備份，而遷移、恢複、高可靠等都是基于備份表現出的業務形态，而備份能力可能是由雲原生能力提供的，也有可能是第三方能力提供的，但最終實作業務形态，是由編排産生的。
使用者上雲并不等于高枕無憂，相反使用者要學習雲的正确打開方式，才能最大程度來保證業務的連續性。雖然雲在底層設計上上是高可靠的，但是仍然避免不了外力造成的影響，例如：光纜被挖斷、斷電、人為誤操作導緻的雲平台可用區無法使用，是以才有了類似“藍翔決定了中國雲計算穩定性”的調侃。我認為使用者決定将業務遷移到雲上的那一刻開始，備份、遷移、恢複、高可靠是一個連續的過程，如何合理利用雲原生服務的特性實作業務連續性，同時進行成本優化，降低總體擁有成本（TCO）。
3、防止廠商鎖定
某種意義上說，雲原生的方向是新一輪廠商鎖定，就像當年盛極一時的IOE架構一樣，隻不過現在換成了雲廠商作為底座承載應用。在IOE時代，使用者很難找到完美的替代品，但是在雲時代，這種差異并不那麼明顯。是以大部分的客戶通常選用混合雲作為雲建設政策，為了讓應用在不同雲之間能夠平滑移動，利用容災技術的遷移一定是作為一個常态化需求存在的。Gartnar也在多雲管平台定義中，将遷移和DR作為單獨的一項能力。充分說明遷移與容災在多雲環境的的常态化趨勢。
雲遷移與雲容災的關系
雲遷移需求的産生
在傳統環境下，遷移的需求并不十分突出，除非是遇到機房搬遷或者硬體更新，才會想到遷移，但這裡的遷移更像是搬鐵，遷移工具化與自動化的需求并不明顯。當VMware出現後，從實體環境到虛拟化的遷移需求被放大，但由于是單一的虛拟化平台，基本上虛拟化廠商自身的工具就完全能夠滿足需求了。在虛拟化平台上，大家突然發現原來隻能人工操作的實體環境一下子輕盈起來，簡單來說，我們的傳統伺服器從一堆鐵變成了一個檔案，并且這個檔案還能夠被來回移動、複制。再後來，進入雲時代，各家雲平台風生水起，國内雲計算市場更是百家争鳴，上雲更是成為了一種剛性需求。随着時間的推移，出于對成本、廠商鎖定等諸多因素的影響，在不同雲之間的互相遷移更是會成為一種常态化的需求。
底層技術一緻
這裡提到的雲遷移和容災，并不是堆人提供的遷移服務，而是強調的高度自動化的手段。目标就是在遷移過程中保證業務連續性，縮短停機時間甚至不停機的效果。這裡就借助了容災的存儲級别同步技術來實作在異構環境下的的“熱遷移”。現有解決方案裡，既有傳統實體機搬遷時代的遷移軟體，也有基于雲原生開發的工具。但無論何種形式，都在不同程度上都解決了使用者上雲的基本訴求。最大的差別在于人效比，這一點與你的利益直接相關。
從另外一個角度也不難發現，所謂的遷移在正式切換之前實質上就是容災的中間過程。同時，業務系統遷移到雲平台後，災備是一個連續的動作，這裡既包含了傳統的備份和容災，還應該包含雲上高可靠的概念。這樣，使用者業務系統在上雲後，才能擺脫傳統基礎架構的負擔，做到“零運維”，真正享受到雲所帶來的的紅利。是以，我認為在雲原生狀态下，雲遷移、雲容災、雲備份本質上就是一種業務形态，底層采用的技術手段可以是完全一緻的。
發展方向
在上述的痛點和趨勢下，必然會出現一種全新的平台來幫助客戶解決資料的安全性和業務連續性問題，今天就從這個角度來分析一下，在雲原生的趨勢下如何建構應用系統的遷移與容災方案。
雲遷移發展趨勢
雲遷移方式
遷移是一項重度的咨詢業務，網上各家雲商、MSP都有自己的方法論，其實看下來差别都不大，之前也有很多人在分享相關話題，本文就不再贅述。這裡我們重點讨論，在實際落地過程中到底該采用哪種工具，哪種方式的效率最高。所謂雲遷移工具，就是将源端遷移至目标端，保證源端在目标端正确運作。常見的方式包括：實體機到虛拟化、虛拟化到虛拟化、實體機到雲平台、虛拟化到雲平台等。
這是經典的6R遷移理論（現在已經更新為了7R，多了VMware出來攪局），在這個圖中與真正遷移相關的其實隻有Rehosting, Replatforming, Repurchasing和Refactoring，但是在這4R中，Refactoring明顯是一個長期的疊代過程，需要使用者和軟體開發商共同參與解決，Repurchasing基本上與人為重新部署沒有太大的差別。是以真正由使用者或MSP在短期完成的隻剩下Rehosting和Replatofrming。
與上面這張經典的遷移理論相比，我更喜歡下面這張圖，這張圖更能反應一個傳統應用到雲原生成長的全過程。與上述的結論相似，我們在真正擁抱雲的時候，路徑基本為上述的三條
- Lift & Shift是Rehost方式的另一種稱呼，這種方式路面最寬，寓意這條路是上雲的最短路徑，應用不需要任何改造直接上雲使用
- Evolve和Go Native都屬于較窄的路徑，寓意為相對于Rehost方式，這兩條路徑所消耗的時間更久，難度更高
- 在圖的最右側，三種形态是存在互相轉換的可能，最終演進為徹底的雲原生，寓意為遷移并不是一蹴而就，需要循序漸進完成
重新托管（Rehost）方式
常用的重新托管方式為冷遷移和熱遷移，冷遷移往往涉及到步驟比較繁瑣，需要大量人力投入，并且容易出錯效率低，對業務連續性有較大的影響，不适合生産系統遷移。而熱遷移方案基本都是商用化的解決方案，這裡又分為塊級别和檔案級别，再細分為傳統方案與雲原生方案。
冷遷移
我們先來看一下冷遷移的手動方案，以VMware到OpenStack為例，最簡單的方式就是将VMware虛拟機檔案(VMDK)通過qemu-img工具進行格式轉換，轉換為QCOW2或者RAW格式，上傳至OpenStack Glance服務，再重新在雲平台上進行啟動。當然這裡面需要進行virtio驅動注入，否則主機無法正常在雲平台啟動。這個過程中最耗時的應該是虛拟機檔案上傳至OpenStack Glance服務的過程，在我們最早期的實踐中，一台主機從開始遷移到啟動完成足足花了24小時。同時，在你遷移這段時間的資料是有增量産生的，除非你将源端關機等待遷移完成，否則，你還要将上述步驟重新來一遍。是以說這種方式真的不适合有業務連續性的生産系統進行遷移。
那如果是實體機的冷遷移方案怎麼做呢？經過我們的最佳實踐，這裡為大家推薦的是老牌的備份工具CloneZilla，中文名為再生龍。是一款非常老牌的備份軟體，常用于進行整機備份與恢複，與我們常見的Norton Ghost原理非常相似。CloneZilla從底層的塊級别進行複制，可以進行整盤的備份，并且支援多種目标端，例如我們将磁盤儲存至移動硬碟，實際格式就是RAW，你隻需要重複上述的方案即可完成遷移。但是在使用CloneZilla過程中，需要使用Live CD方式進行引導，同樣會面臨長時間業務系統中斷的問題，這也是上面我們提到的冷遷移并不适合生産環境遷移的原因。
傳統熱遷移方案
傳統的熱遷移方案基本分為塊級别和檔案級别，兩者相似之處都是利用差量同步技術進行實作，即全量和增量交叉同步方式。
檔案級别的熱遷移方案往往局限性較大，并不能算真正的ReHost方式，因為前期需要準備于源端完全一樣的作業系統，無法實作整機搬遷，從操作的複雜性更大和遷移的穩定性來說都不高。我們在Linux上常用的Rsync其實可以作為檔案級别熱遷移的一種解決方案。
真正可以實作熱遷移的方案，還要使用塊級别同步，降低對底層作業系統依賴，實作整機的搬遷效果。傳統的塊級别熱遷移方案基本上來自于傳統容災方案的變種，利用記憶體作業系統WIN PE或其他Live CD實作，基本原理和過程如下圖所示。從過程中我們不難發現這種方式雖然在一定程度解決了遷移的目标，但是作為未來混合雲常态化遷移需求來說，仍然有以下幾點不足：
- 由于傳統熱遷移方案是基于實體環境建構的，是以我們發現在整個過程中人為介入非常多，對于使用者的技能要求比較高
- 無法滿足雲原生時代多租戶、自服務的需求
- 安裝代理是使用者心中永遠的芥蒂
- 一比一同步方式，從成本角度來說不夠經濟
- 最好的遷移驗證方式，就是将業務系統叢集在雲端完全恢複，但是手動驗證的方式，對遷移人力成本是再一次增加
雲原生熱遷移方案
正是由于傳統遷移方案的弊端，應運而生了雲原生的熱遷移方案，這一方面的代表廠商當屬AWS在2019年以2.5億美金擊敗Google Cloud收購的以色列雲原生容災、遷移廠商CloudEndure。
雲原生熱遷移方案是指利用塊級别差量同步技術結合雲原生API接口和資源實作高度自動化遷移效果，同時提供多租戶、API接口滿足混合雲租戶自服務的需求。我們先從原理角度分析一下，為什麼相對于傳統方案，雲原生的方式能夠滿足高度自動化、使用者自服務的使用者體驗。通過兩個方案對比，我們不難發現雲原生方式的幾個優勢：
- 利用雲原生API接口和資源，操作簡便，完全取代了傳統方案大量繁瑣的人為操作，對使用者技術要求降低，學習陡峭程度大幅度降低
- 由于操作簡便，遷移效率提高，有效提高遷移實施的人效比
- 一對多的同步方式，大幅度降低計算資源使用，計算資源隻在驗證和最終切換時使用
- 能夠滿足多租戶、自服務的要求
- 源端也可以支援無代理方式，打消使用者疑慮，并且适合大規模批量遷移
- 高度自動化的驗證手段，在完成遷移切換前，能夠反複進行驗證
這是CloudEndure的架構圖，當然你也可以利用CloudEndure實作跨區域的容災。
不過可惜的一點是由于被AWS收購，CloudEndure目前隻能支援遷移至AWS，無法滿足國内各種雲遷移的需求。是以這裡為大家推薦一款純國産化的遷移平台——萬博智雲的HyperMotion(
https://hypermotion.oneprocloud.com/)，從原理上與CloudEndure非常相似，同時支援了VMware及OpenStack無代理的遷移，更重要的是覆寫了國内主流的公有雲、專有雲和私有雲的遷移。
平台重建（Replatforming）方式
随着雲原生提供越來越多的服務，降低了應用架構的複雜度，使得企業能夠更專注自己的業務本身開發。但是研發側工作量的減少意味着這部分成本被轉嫁到部署及運維環節，是以DevOps成為在雲原生運用中比不可少的一個緩解，也讓企業能夠更靈活的應對業務上的複雜變化。
正如上面所提到的，使用者通過少量的改造可以優先使用一部分雲原生服務，這種遷移方式我們成為平台重建（Replatforming），目前選擇平台重建方式的遷移，多以與使用者資料相關的服務為主。常見的包括：資料庫服務RDS、對象存儲服務、消息隊列服務、容器服務等。這些雲原生服務的引入，降低了使用者運維成本。但是由于雲原生服務自身封裝非常嚴密，底層的基礎架構層對于使用者完全不可見，是以無法用上述Rehost方式進行遷移，必須采用其他的輔助手段完成。
以關系型資料庫為例，每一種雲幾乎都提供了遷移工具，像AWS DMS，阿裡雲的DTS，騰訊雲的資料傳輸服務DTS，這些雲原生工具都可以支援 MySQL、MariaDB、PostgreSQL、Redis、MongoDB 等多種關系型資料庫及 NoSQL 資料庫遷移。以MySQL為例，這些服務都巧妙的利用了binlog複制的方式，實作了資料庫的線上遷移。
再以對象存儲為例，幾乎每一種雲都提供了自己的遷移工具，像阿裡雲的ossimport，騰訊雲COS Migration工具，都可以實作本地到雲端對象存儲的增量遷移。但是在實際遷移時，還應考慮成本問題，公有雲的對象存儲在存儲資料上比較便宜，但是在讀出資料時是要根據網絡流量和請求次數進行收費的，這就要求我們在設計遷移方案時，充分考慮成本因素。如果資料量過大，還可以考慮采用離線裝置方式，例如：AWS的Snowball，阿裡雲的閃電立方等。這部分就不展開介紹，以後有機會再單獨為大家介紹。
如果選擇平台重建方式上雲，除了要進行必要的應用改造，還需要選擇一款适合你的遷移工具，保證資料能夠平滑上雲。結合上面的Rehost方式遷移，能夠實作業務系統的整體上雲效果。由于涉及的服務較多，這裡為大家提供一張遷移工具表格供大家參考。
雲原生下的容災發展趨勢
目前為止，還沒有一套平台能夠完全滿足雲原生狀态下的統一容災需求，我們通過以下場景來分析一下，如何才能建構一套統一的容災平台滿足雲原生的需求。
傳統架構
我們以一個簡單的Wordpress + MySQL環境為例，傳統下的部署環境一般是這樣架構的：
如果為這套應用架構設計一套容災方案，可以采用以下的方式：
- 負載均衡節點容災：負載均衡分為硬體和軟體層面，硬體負載均衡高可靠和容災往往通過自身的解決方案實作。如果是軟體負載均衡，往往需要安裝在基礎作業系統上，而同城的容災可以使用軟體高可靠的方式實作，而異地的容災往往是通過提前建立對等節點，或者幹脆采用容災軟體的塊或者檔案級别容災實作。是容災切換（Failover）很重要的一個環節。
- Web Server的容災：Wordpress的運作環境無非是Apache + PHP，由于分離了用于存放使用者上傳的檔案系統，是以該節點幾乎是無狀态的，通過擴充節點即可實作高可靠，而異地容災也比較簡單，傳統的塊級别和檔案級别都可以滿足容災的需求
- 共享檔案系統的容災，圖中采用了Gluster的檔案系統，由于分布式系統的一緻性通常由内部維護，單純使用塊級别很難保證節點的一緻性，是以這裡面使用檔案級别容災更為精确
- 資料庫的容災，單純依靠存儲層面是無法根本實作資料庫0丢失資料的，是以一般采用從資料庫層面實作，當然如果為了降低成本，資料庫的容災可以簡單的使用周期Dump資料庫的方式實作，當然如果對可靠性要求較高，還可以使用CDP方式實作
從以上的案例分析不難看出，傳統基礎架構下的容災往往以存儲為核心，無論是磁盤陣列的存儲鏡像，還是基于I/O資料塊、位元組級的捕獲技術，結合網絡、資料庫和叢集的應用級别技術完成高可靠和容災體系的建構。在整個容災過程的參與者主要為：主機、存儲、網絡和應用軟體，相對來說比較單一。是以在傳統容災方案中，如何正确解決存儲的容災也就成為了解決問題的關鍵。
混合雲容災
這應該是目前最常見的混合雲的方案，也是各大容災廠商主推的一種方式。這裡我們相當于将雲平台當成了一套虛拟化平台，幾乎沒有利用雲平台任何特性。在恢複過程中，需要大量人為的接入才能将業務系統恢複到可用狀态。這樣的架構并不符合雲上的最佳實踐，但的确是很多業務系統備份或遷移上雲後真實的寫照。
這樣的架構确實能解決容災的問題，但是從成本上來說很高，現在我們來換一種方式。我們利用了對象存儲和資料庫進行一次優化。我們将原有存儲服務存放至對象存儲中，而使用資料傳輸服務來進行實時的資料庫複制。雲主機仍然采用傳統的塊級别進行同步。一旦出現故障，則需要自動化編排能力，重新将備份進行恢複，在最短時間内根據我們預設的方案進行恢複，完成容災。
雲上同城容災架構
上述的備份方式，實質上就是利用平台重建的方式進行的遷移，既然已經利用遷移進行了備份，那完全可以對架構進行如下改造，形成同城的容災架構。我們根據雲平台的最佳實踐，對架構進行了如下調整：
這個架構不僅實作了應用級高可靠，還能夠支撐一定的高并發性，使用者在最少改造代價下就能夠在同城實作雙活的效果。我們來分析一下在雲上利用了多少雲原生的服務：
- 域名解析服務
- VPC服務
- 負載均衡服務
- 自動伸縮服務
- 雲主機服務
- 對象存儲服務
- 關系型資料庫RDS服務
除了雲主機外，其他服務均是天然就支援跨可用區的高可用特性，對于雲主機我們可以制作鏡像方式，由自動伸縮服務負責執行個體的狀态。由于雲上可用區就是同城容災的概念，這裡我們就實作了同城的業務系統容災。
經過調整的架構在一定程度上滿足了業務連續性的要求，但是對于資料的安全性仍然缺乏保障。近幾年，勒索病毒橫行，大量企業為此蒙受巨大損失，是以資料備份是上雲後必須實施的。雲原生服務本身提供了備份方案，例如雲主機的定期快照等，但往往服務比較分散，不容易統一進行管理。同時，在恢複時往往也是隻能每一個服務進行恢複，如果業務系統規模較大，也會增加大量的恢複成本。雖然雲原生服務解決了自身備份問題，但是将備份重新組織成應用是需要利用自動化的編排能力實作。
同雲異地容災架構
大部分的雲原生服務都在可用區内，提供了高可靠能力，但是對于跨區域上通常提供的是備份能力。例如：可以将雲主機變為鏡像，将鏡像複制到其他區域内；關系型資料庫和對象存儲也具備跨域的備份能力。利用這些元件自身的備份能力，外加上雲自身資源的編排能力，我們可以實作在容災可用域将系統恢複至可用狀态。那如何觸發切換呢？
這裡我們根據業務系統的特點，在雲原生的監控上定制告警，利用告警平台的觸發能力觸發函數計算，完成業務系統的跨域切換，形成異地容災的效果。
跨雲容災
但跨雲容災不像同雲容災時，在不同的可用區之間至少服務是一緻的，那麼此時，在同雲上使用的方法基本失效，完全需要目标雲平台的能力或者中立的第三方的解決方案。這裡除了資料的備份，還有一點是服務配置的互相比對。才能完全滿足跨雲容災恢複的需求。另外需要考慮的一點就是成本為例，以對象存儲為例，是典型的的“上雲容易下雲難”。是以如何利用雲原生資源特性合理設計容災方案是對成本的極大考驗。
總結
雲原生容災還處于早期階段，目前尚沒有完整的平台能夠支援以上各種場景的容災需求，是值得持續探索的話題。雲原生容災以備份為核心，以遷移、恢複和高可靠為業務場景，實作多雲之間的自由流轉，最終滿足使用者的業務需求。
是以，作為面向雲原生的容災平台要解決好三方面的能力：
一、以資料為核心，讓資料在多雲之間互相流轉。資料是使用者核心價值，是以無論底層基礎架構如何變化，資料備份一定是使用者的剛醒需求。對于不同雲原生服務如何解決好資料備份，是資料流轉的必要基礎。
二、利用雲原生編排能力，實作高度自動化，在資料基礎上建構業務場景。利用自動化編排能力實作更多的基于資料層的應用，幫助使用者完成更多的業務創新。
三、靈活運用雲原生資源特點，降低總體擁有成本。解決傳統容災投入巨大的問題，讓使用者的成本真的能像水、電一樣按需付費。