云棲號(hào)案例庫(kù)：【點(diǎn)擊查看更多上云案例】
不知道怎么上云？看云棲號(hào)案例庫(kù)，了解不同行業(yè)不同發(fā)展階段的上云方案，助力你上云決策！

業(yè)務(wù)痛點(diǎn)

• 自2016年開(kāi)發(fā)遷移工具主要面向私有云環(huán)境，但是隨著公有云用戶越來(lái)越多，我們迫切的希望以一種SaaS形態(tài)提供給所有有公有云遷移的客戶使用。快速的將工具平臺(tái)化、并且具有擴(kuò)展性、可靠性是我們?cè)谵D(zhuǎn)型過(guò)程中深入思考的問(wèn)題。同時(shí)，如何在不增加人力的情況下，完成平臺(tái)的運(yùn)維變得尤為重要。所以使用云原生服務(wù)方式去構(gòu)建我們的平臺(tái)是唯一的捷徑。
• 傳統(tǒng)行業(yè)用戶從傳統(tǒng)環(huán)境過(guò)渡到云平臺(tái)時(shí)，上云往往是第一步要做的。但是大部分客戶是想遷移而不敢遷移，究其原因就是擔(dān)心遷移過(guò)程對(duì)業(yè)務(wù)系統(tǒng)的影響，遷移人員對(duì)原架構(gòu)和云平臺(tái)的技術(shù)能力，遷移周期管控，遷移成本，以及遷移后業(yè)務(wù)系統(tǒng)的穩(wěn)定性。
• 用戶在遷移過(guò)程中最關(guān)心的問(wèn)題是：業(yè)務(wù)連續(xù)性如何保障？怎么可以自動(dòng)智能適配不同平臺(tái)的驅(qū)動(dòng)？怎么減少人員干預(yù)帶來(lái)的風(fēng)險(xiǎn)？怎么控制遷移周期和成本？怎么可以批量高效遷移？失敗是否可以回退？

解決方案

解決方案邏輯圖

?

方案細(xì)節(jié)：

上云需求的產(chǎn)生——從工具到SaaS

從2016年開(kāi)始，我們團(tuán)隊(duì)開(kāi)發(fā)了針對(duì)私有云整機(jī)遷移的工具HyperMotion，這款工具基于云原生API接口開(kāi)發(fā)，實(shí)現(xiàn)高度自動(dòng)化的遷移。隨著時(shí)間的發(fā)展，越來(lái)越多的企業(yè)選擇將一部分負(fù)載運(yùn)行在公有云上，混合云的形態(tài)越來(lái)越多。公有云遷移的需求也隨之增多。所以，我們?cè)?019年初增加了對(duì)阿里云遷移的支持。不同于私有云的遷移，如何讓我們的客戶更快的進(jìn)入遷移流程，不把時(shí)間花在介質(zhì)下載和安裝的步驟呢？SaaS化是解決這個(gè)問(wèn)題的最佳選擇。

云遷移的痛點(diǎn)

2016年開(kāi)始，在建設(shè)金融行業(yè)私有云建設(shè)過(guò)程中，我們發(fā)現(xiàn)遷移是私有云建設(shè)中非常強(qiáng)烈的剛需。同時(shí)，對(duì)后續(xù)云平臺(tái)擴(kuò)容起著至關(guān)重要的作用。但是用戶在上云時(shí)卻謹(jǐn)小慎微，總結(jié)其原因主要有以下幾個(gè)方面：

• 如何保障業(yè)務(wù)在上云過(guò)程和上云運(yùn)行的穩(wěn)定性

在任何行業(yè)中，穩(wěn)定、可靠是當(dāng)仁不讓的第一原則，對(duì)于關(guān)乎民生的金融行業(yè)更是如此。所以在實(shí)際云平臺(tái)建設(shè)過(guò)程中，原有業(yè)務(wù)系統(tǒng)上云時(shí)往往受到的阻力最大。究其原因就是在上云過(guò)程中沒(méi)有一套完整的、科學(xué)的方法論及工具讓用戶打消對(duì)上云的顧慮。

• 業(yè)務(wù)連續(xù)性

在上云過(guò)程中，如何保障業(yè)務(wù)系統(tǒng)連續(xù)性是用戶尤為關(guān)注的一點(diǎn)，任何客戶都希望在遷移過(guò)程中全程無(wú)感知，業(yè)務(wù)中斷為0。但是在實(shí)際從云下到云上遷移過(guò)程中，是一個(gè)極其復(fù)雜的建設(shè)過(guò)程中，如果沒(méi)有強(qiáng)有力的工具支撐，很難做到這一點(diǎn)。

• 如何選擇上云方式

用戶在上云方式上面臨多種選擇，常見(jiàn)的七種策略：重新托管(Rehosting), 更換平臺(tái)（Replatforming), 重新購(gòu)買(mǎi)(Repurchasing), 重構(gòu)(Refactoring/Re-architecting), 退役（Retire), 保留(Retian)。那么對(duì)于傳統(tǒng)行業(yè)客戶最簡(jiǎn)單、高效的就是Reshot方式。傳統(tǒng)客戶由于歷史原因，積累下大量的業(yè)務(wù)系統(tǒng)，這些老舊的業(yè)務(wù)系統(tǒng)只能勉強(qiáng)維持運(yùn)行，可能由于開(kāi)發(fā)廠商的消失，根本談不到重新部署、升級(jí)和新功能開(kāi)發(fā)。所以在實(shí)際遷移時(shí)，對(duì)應(yīng)用本身依賴程度越低越好。所以在眾多遷移方式中，Rehost成為快速上云的不二選擇。Rehost方式通常是從操作系統(tǒng)底層即塊級(jí)別實(shí)施整體搬遷，對(duì)應(yīng)用影響最小。同時(shí)，用戶在快速上云后，可以逐步改造自己的業(yè)務(wù)系統(tǒng)，逐步將應(yīng)用過(guò)渡到云原生方式。

• 遷移可驗(yàn)證，失敗可回退

為了保障遷移后的穩(wěn)定性，在正式將業(yè)務(wù)切換到云平臺(tái)前，需要進(jìn)行必要的驗(yàn)證工作。驗(yàn)證過(guò)程中，不能影響原有業(yè)務(wù)的運(yùn)行狀態(tài)。如果遷移失敗，需要快速的將系統(tǒng)回滾至原有系統(tǒng)。

• 如何減少人員依賴和人為干預(yù)的風(fēng)險(xiǎn)

遷移涉及業(yè)務(wù)系統(tǒng)、涉及原架構(gòu)、目標(biāo)云架構(gòu)的技術(shù)特性，因此對(duì)人員技術(shù)能力要求較高；然而過(guò)多人為干預(yù)又會(huì)導(dǎo)致諸如業(yè)務(wù)影響、周期控制、成本居高的問(wèn)題。因此，將遷移過(guò)程工具化，將技術(shù)邏輯抽象處理并融合到操作流程中，以此降低人員技術(shù)能力要求，通過(guò)遷移工具底層運(yùn)行最大化自動(dòng)化遷移過(guò)程。

如何基于云原生資源進(jìn)行云遷移

在開(kāi)發(fā)之初，我們堅(jiān)持使用云原生的方式構(gòu)建我們整個(gè)遷移流程。我們對(duì)云原生使用方式包括：云原生的API和云原生資源。

使用云原生API，能夠大幅度簡(jiǎn)化繁瑣的遷移流程，減少用戶操作，降低出現(xiàn)錯(cuò)誤的概率。并且通過(guò)對(duì)遷移流程的抽象，使遷移軟件能夠支持多云平臺(tái)。在對(duì)接一朵新的云平臺(tái)時(shí)，開(kāi)發(fā)周期僅為2周。

使用云原生的資源，能夠減少在遷移過(guò)程中資源轉(zhuǎn)換的時(shí)間損耗。在遷移過(guò)程中，將數(shù)據(jù)直接存儲(chǔ)在云平臺(tái)塊存儲(chǔ)上，之后能夠快速的將存儲(chǔ)轉(zhuǎn)換為云主機(jī)，達(dá)成遷移中驗(yàn)證和切換的需求。

下面以遷移中最常見(jiàn)的兩個(gè)流程：數(shù)據(jù)同步和啟動(dòng)主機(jī)來(lái)說(shuō)明對(duì)云原生資源的使用方式。

• 數(shù)據(jù)同步

為了實(shí)現(xiàn)Rehost的效果，需要使用塊級(jí)別的差量同步技術(shù)來(lái)滿足整機(jī)遷移的效果。如圖所示，我們分別在10點(diǎn)和12點(diǎn)進(jìn)行了同步，10點(diǎn)同步時(shí)為第一次同步數(shù)據(jù)，所以我們會(huì)同步磁盤(pán)中的所有有效塊。在阿里云側(cè)，我們利用阿里云EBS作為接收端，創(chuàng)建一個(gè)與源端同樣大小的云硬盤(pán)，將該EBS掛載到云代理同步的ECS上后，將數(shù)據(jù)直接寫(xiě)入該EBS設(shè)備上。在10點(diǎn)完成后，這塊EBS設(shè)備的狀態(tài)與源端數(shù)據(jù)狀態(tài)一致。在同步完成后，遷移平臺(tái)會(huì)調(diào)用EBS快照接口，進(jìn)行快照，保留當(dāng)時(shí)狀態(tài)。后續(xù)我們可以使用該時(shí)間點(diǎn)對(duì)遷移后的系統(tǒng)進(jìn)行驗(yàn)證。

在12點(diǎn)同步時(shí)，通過(guò)對(duì)10點(diǎn)到12點(diǎn)變化塊序列的記錄，同步邏輯發(fā)現(xiàn)系統(tǒng)刪除了兩個(gè)塊，并新增了一個(gè)塊。同步程序在接收端的EBS上也執(zhí)行刪除兩個(gè)快，并復(fù)制一個(gè)塊的動(dòng)作，此時(shí)磁盤(pán)的狀態(tài)又和源端磁盤(pán)保持了一致。完成后再次執(zhí)行EBS快照操作。此時(shí)用戶可以使用10點(diǎn)和12點(diǎn)的快照進(jìn)行遷移驗(yàn)證操作。

?

• 啟動(dòng)主機(jī)

啟動(dòng)主機(jī)的過(guò)程其實(shí)就是由云平臺(tái)的塊存儲(chǔ)轉(zhuǎn)換為云主機(jī)的過(guò)程。由于阿里云目前并不支持直接用云硬盤(pán)直接作為系統(tǒng)盤(pán)啟動(dòng)，所以在阿里云處理上，我們采用了其他策略。整個(gè)流程如下：

第一步：根據(jù)用戶選擇的快照時(shí)間點(diǎn)進(jìn)行主機(jī)啟動(dòng)。
第二步：通過(guò)驅(qū)動(dòng)修復(fù)主機(jī)鏡像和用戶選擇時(shí)間點(diǎn)的快照，重組成用于驅(qū)動(dòng)修復(fù)的鏡像。
第三步：使用該鏡像模板啟動(dòng)主機(jī)后，進(jìn)行驅(qū)動(dòng)修復(fù)。驅(qū)動(dòng)修復(fù)主要是解決源端環(huán)境和目標(biāo)環(huán)境的驅(qū)動(dòng)差異、符合目標(biāo)平臺(tái)管制需求。例如：在KVM平臺(tái)上需要使用virtio驅(qū)動(dòng)，在云平臺(tái)上使用DHCP方式獲取IP地址。
第四步：對(duì)修復(fù)好的磁盤(pán)再次進(jìn)行快照，重組用于啟動(dòng)的遷移主機(jī)鏡像。
第五步：進(jìn)行主機(jī)啟動(dòng)，完成遷移驗(yàn)證或啟動(dòng)流程。用戶可以登錄修復(fù)后的主機(jī)，進(jìn)行驗(yàn)證。此時(shí)，源端主機(jī)仍然處于運(yùn)行狀態(tài)。

?

從工具到平臺(tái)

?

在工具階段，我們?yōu)橛脩籼峁┊a(chǎn)品時(shí)往往以私有化方式部署為主。用戶通過(guò)鏡像方式下載安裝介質(zhì)到本地環(huán)境進(jìn)行安裝。我們提供的介質(zhì)大小在3.6G左右，由于目前很多網(wǎng)盤(pán)都有速度限制，所以用戶往往下載好需要幾個(gè)小時(shí)。平臺(tái)化后，用戶無(wú)須再在將時(shí)間花在下載介質(zhì)的時(shí)間上，而可以快速的進(jìn)入整個(gè)遷移流程。

在單機(jī)版本軟件上，往往都是一個(gè)用戶進(jìn)行操作，并無(wú)太多的并發(fā)壓力。到了SaaS版本，首先需要實(shí)現(xiàn)多租戶模式，意味著軟件需要承受更多的并發(fā)壓力，這就要求平臺(tái)具備高度擴(kuò)展能力，滿足用戶量激增的壓力。

原有單機(jī)版本并發(fā)遷移時(shí)，需要用戶手動(dòng)對(duì)云代理節(jié)點(diǎn)進(jìn)行擴(kuò)容，在SaaS版本里為了更好的用戶體驗(yàn)，云代理節(jié)點(diǎn)也應(yīng)當(dāng)具備彈性擴(kuò)展能力。
研發(fā)團(tuán)隊(duì)需要用最短的時(shí)間將單機(jī)版本改造為線上SaaS版本。由于人力資源的限制，實(shí)施團(tuán)隊(duì)需要兼顧私有項(xiàng)目和線上運(yùn)維，這就要求平臺(tái)穩(wěn)定、高可靠、易運(yùn)維。所以對(duì)云原生的應(yīng)用就變得尤為關(guān)鍵。

?

在由工具向平臺(tái)改造過(guò)程中，必須要解決以下幾個(gè)問(wèn)題：

• 應(yīng)用本身改造

為了支持多租戶的需要，我們?cè)黾恿藛为?dú)的用戶管理模塊，來(lái)滿足多租戶的需要；同時(shí)為了滿足線上運(yùn)營(yíng)的需求，還針對(duì)性的開(kāi)發(fā)了運(yùn)營(yíng)模塊來(lái)支撐不同角色用戶的操作需求。在原有單機(jī)版本中由于客戶在實(shí)施過(guò)程中基本都是本地局域網(wǎng)，所以源端和控制端通訊時(shí)不受制約，但是SaaS平臺(tái)上線后。為了降低用戶網(wǎng)絡(luò)配置成本，需要將源端和控制端的通訊變?yōu)閱蜗颉＜丛炊丝梢栽L問(wèn)控制端，無(wú)須控制端直接與源端連接。

• 平臺(tái)部署和運(yùn)維

在阿里云服務(wù)選擇上，我們盡量選擇云原生的服務(wù)來(lái)滿足我們的需求，通過(guò)價(jià)格比對(duì)，尋找適合我們的方案。
使用云原生服務(wù)另外的一個(gè)好處就是服務(wù)之間的關(guān)聯(lián)性，幾乎不需要復(fù)雜配置就可以完成，例如：監(jiān)控、日志等運(yùn)維支持服務(wù)。
平臺(tái)上線初期采用按量計(jì)費(fèi)的方式，尋找到規(guī)律后，再轉(zhuǎn)為包年包月或改為資源包購(gòu)買(mǎi)方式。
我們的所有服務(wù)都是以容器化方式進(jìn)行部署，所以在選擇Kubernetes托管服務(wù)商，我們對(duì)比了自建、專(zhuān)有版本、托管版本和Serverless版本的價(jià)格。最初為了節(jié)約成本，我們選擇了Serverless版本，Serverless版本使用按量計(jì)費(fèi)的方式，是集中模式下性價(jià)比最高的，但是隨著平臺(tái)上線后，我們?cè)谑褂迷圃O(jiān)控時(shí)發(fā)現(xiàn)Serverless版并不支持插件的安裝，導(dǎo)致監(jiān)控和告警服務(wù)無(wú)法使用。最終，基于成本的考慮，我們選擇了托管版本，能夠滿足我們的需求。

?

• CI流程的改造

在之前的CI流程，我們只需要提供鏡像文件（QCOW2）和ISO文件。在SaaS平臺(tái)上線后，我們的流程出現(xiàn)了很大的變化。一方面我們搭建了三套環(huán)境：本地的Kubernetes、阿里云上的QA和生產(chǎn)環(huán)境。本地環(huán)境采用及時(shí)更新的策略，研發(fā)代碼Review入庫(kù)后，立即會(huì)更新到研發(fā)環(huán)境中。而QA和線上環(huán)境采用手動(dòng)部署方式，從特定的代碼分支進(jìn)行部署。在鏡像倉(cāng)庫(kù)選擇上，線下環(huán)境使用Harbor，而線上環(huán)境直接使用阿里云的鏡像倉(cāng)庫(kù)服務(wù)。CI控制采用Jenkins觸發(fā)方式，所有腳本都使用代碼倉(cāng)庫(kù)進(jìn)行統(tǒng)一管理。

?

上云價(jià)值

得益于云原生的使用，我們從7月份提出需求，9月份在阿里云上線內(nèi)部測(cè)試版本，到今年春節(jié)之后正式邀請(qǐng)客戶進(jìn)行使用，并且今年春節(jié)后推出了“零接觸”云遷移免費(fèi)3個(gè)月時(shí)間。能在這么短的時(shí)間內(nèi)，將一款單機(jī)版本的軟件具有多用戶并發(fā)支持能力的SaaS平臺(tái)，云原生提供的支持功不可沒(méi)。

• 在沒(méi)有增加人力的情況下，運(yùn)維壓力并沒(méi)有過(guò)多增加，云原生的方式提供天然的容災(zāi)、備份服務(wù)，使得運(yùn)維人員很輕松的簡(jiǎn)單配置就可以實(shí)現(xiàn)傳統(tǒng)運(yùn)維需要大量安裝和配置的效果。
• 利于成本控制，具有高度可擴(kuò)展性。由于遷移本身是具有一定專(zhuān)業(yè)性的產(chǎn)品，用戶以企業(yè)用戶為主。所以客戶增長(zhǎng)的速度可能不會(huì)像C端增長(zhǎng)明顯，所以采用按量計(jì)費(fèi)的方式可以更精細(xì)化的控制成本。同時(shí)，基于云的擴(kuò)展性，用戶量一旦激增后，也可以輕松應(yīng)對(duì)。
• 函數(shù)計(jì)算服務(wù)的使用，簡(jiǎn)化了開(kāi)發(fā)成本，運(yùn)維成本直接降為零。目前將License服務(wù)使用函數(shù)計(jì)算提供，如果使用傳統(tǒng)方式構(gòu)建，我們至少需要http服務(wù)端、定義接口等開(kāi)發(fā)，再加上部署上打包成容器、部署等操作，成本很高。但是如果使用阿里的函數(shù)計(jì)算服務(wù)，天然支持http trigger方式，我們只需要在函數(shù)中定義接口，發(fā)布一下馬上就可以使用了。并且函數(shù)計(jì)算擁有詳細(xì)的監(jiān)控，調(diào)用統(tǒng)計(jì)等信息一目了然，通過(guò)日志服務(wù)收集日志信息，可以用于后續(xù)的分析。

選用的產(chǎn)品

?

云棲號(hào)案例庫(kù)：【點(diǎn)擊查看更多上云案例】
不知道怎么上云？看云棲號(hào)案例庫(kù)，了解不同行業(yè)不同發(fā)展階段的上云方案，助力你上云決策！

本文為阿里云原創(chuàng)內(nèi)容，未經(jīng)允許不得轉(zhuǎn)載。

云棲號(hào) - 上云就看云棲號(hào)

總結(jié)

以上是生活随笔為你收集整理的万博智云上云 单机软件升级多并发SaaS平台的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問(wèn)題。

如果覺(jué)得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。