云采用框架（Cloud Adoption Framework，簡稱CAF）為企業(yè)上云提供策略和技術(shù)的指導(dǎo)原則和最佳實(shí)踐，幫助企業(yè)上好云、用好云、管好云，并成功實(shí)現(xiàn)業(yè)務(wù)目標(biāo)。本云采用框架是基于服務(wù)大量企業(yè)客戶的經(jīng)驗(yàn)總結(jié)，將企業(yè)云采用分為四個階段，并詳細(xì)探討企業(yè)應(yīng)在每個階段采取的業(yè)務(wù)和技術(shù)策略；同時，還提供了一系列最佳實(shí)踐、文檔和輔助工具，幫助云架構(gòu)師、云管理團(tuán)隊(duì)等干系人能夠?qū)崿F(xiàn)組織協(xié)同達(dá)成目標(biāo)。

關(guān)注【TechLeadCloud】，分享互聯(lián)網(wǎng)架構(gòu)、云服務(wù)技術(shù)的全維度知識。作者擁有10+年互聯(lián)網(wǎng)服務(wù)架構(gòu)、AI產(chǎn)品研發(fā)經(jīng)驗(yàn)、團(tuán)隊(duì)管理經(jīng)驗(yàn)，同濟(jì)本復(fù)旦碩，復(fù)旦機(jī)器人智能實(shí)驗(yàn)室成員，阿里云認(rèn)證的資深架構(gòu)師，項(xiàng)目管理專業(yè)人士，上億營收AI產(chǎn)品研發(fā)負(fù)責(zé)人。

一、什么是云采用框架CAF

云采用框架（Cloud Adoption Framework，簡稱CAF）為企業(yè)上云提供策略和技術(shù)的指導(dǎo)原則和最佳實(shí)踐，幫助企業(yè)上好云、用好云、管好云，并成功實(shí)現(xiàn)業(yè)務(wù)目標(biāo)。

本云采用框架是基于服務(wù)大量企業(yè)客戶的經(jīng)驗(yàn)總結(jié)，將企業(yè)云采用分為四個階段：上云戰(zhàn)略、上云準(zhǔn)備、應(yīng)用上云和運(yùn)營治理，并詳細(xì)探討企業(yè)應(yīng)在每個階段采取的業(yè)務(wù)和技術(shù)策略；同時，還提供了一系列最佳實(shí)踐、文檔和輔助工具，幫助云架構(gòu)師、云管理團(tuán)隊(duì)等干系人能夠?qū)崿F(xiàn)組織協(xié)同達(dá)成目標(biāo)。

ITIL（Information Technology Infrastructure Library） 是IT服務(wù)管理的經(jīng)典方法論，被企業(yè)廣泛采用。ITIL中核心的概念是IT服務(wù)，IT服務(wù)是用來支持企業(yè)業(yè)務(wù)發(fā)展的技術(shù)服務(wù)，它的全生命周期包含服務(wù)戰(zhàn)略、服務(wù)設(shè)計、服務(wù)轉(zhuǎn)換、服務(wù)運(yùn)營以及服務(wù)的持續(xù)改進(jìn)五個階段，其中

• 服務(wù)戰(zhàn)略階段：定義服務(wù)、明確服務(wù)的價值以及服務(wù)管理與業(yè)務(wù)之間的關(guān)系。
• 服務(wù)設(shè)計階段：定義服務(wù)的目標(biāo)和要素、模型和風(fēng)險，定義管理服務(wù)的流程。
• 服務(wù)轉(zhuǎn)換階段：提供發(fā)展和改進(jìn)能力將服務(wù)交付到運(yùn)營階段。
• 服務(wù)運(yùn)營階段：在服務(wù)交付和支持中保證效率和效果，為客戶提供價值。

云服務(wù)是當(dāng)下最流行的IT服務(wù)之一，云服務(wù)的采用應(yīng)遵循上述生命周期。我們的云采用框架就是以這樣的理論體系為指導(dǎo)，定義了企業(yè)引入云服務(wù)的四個階段：

• 在上云戰(zhàn)略階段，領(lǐng)導(dǎo)層需要思考上云能為業(yè)務(wù)帶來什么價值，并在公司層面確定相應(yīng)的戰(zhàn)略。
• 在上云準(zhǔn)備階段，IT團(tuán)隊(duì)需要制定云采用的頂層設(shè)計，確保組織協(xié)同和可管可控。
• 在應(yīng)用上云階段，開始遷移原有的系統(tǒng)上云或者在云上開展新的業(yè)務(wù)。
• 在運(yùn)營治理階段，企業(yè)不斷發(fā)現(xiàn)和解決運(yùn)營過程中的問題和風(fēng)險，提升服務(wù)質(zhì)量。

二、企業(yè)上云的主要動機(jī)

我們可以根據(jù)上云的業(yè)務(wù)對上云動機(jī)進(jìn)行分類。如果上云的業(yè)務(wù)是一個在云下已經(jīng)存在的業(yè)務(wù)，那么上云主要是把云下的應(yīng)用遷移到云上，這稱為業(yè)務(wù)遷移上云。如果上云的業(yè)務(wù)是一個新構(gòu)建的業(yè)務(wù)，首次部署運(yùn)行就在云上，這稱為業(yè)務(wù)創(chuàng)新上云。

業(yè)務(wù)遷移上云

業(yè)務(wù)遷移上云是最為常見的一類上云動機(jī)，也是云計算技術(shù)商業(yè)化后最早期的企業(yè)普遍采用的上云方式。業(yè)務(wù)遷移上云的主要目的是：

• 加速資源的交付效率，提高對業(yè)務(wù)需求的反應(yīng)速度。

  傳統(tǒng)IDC采購周期從一個月到幾個月不等。如果涉及到出海，對于企業(yè)來說IDC的規(guī)劃甚至長達(dá)數(shù)年。而云上資源的交付效率近乎實(shí)時。

• 降低成本。

  云計算將IT資產(chǎn)的成本由傳統(tǒng)的Capex資產(chǎn)折舊模型轉(zhuǎn)變?yōu)镺pex的按量付費(fèi)模型。這樣做一方面減少企業(yè)的一次性IT投入，另一方面也可以讓企業(yè)按時按量購買需要的資源，以節(jié)省成本。

• 使用云提供的最新技術(shù)。

  云廠商通常在產(chǎn)品技術(shù)的投入非常大。因此，云廠商提供的云服務(wù)通常在行業(yè)中比較領(lǐng)先，例如我們常說的云原生服務(wù)，如容器、中間件。

• 提高服務(wù)的安全性。

  云廠商提供的是規(guī)?；诰€服務(wù)。在安全性方面，云廠商有大量的數(shù)據(jù)能夠幫助客戶更好的應(yīng)對互聯(lián)網(wǎng)上的攻擊。

業(yè)務(wù)創(chuàng)新上云

隨著數(shù)字化轉(zhuǎn)型的浪潮，當(dāng)前許多企業(yè)開始業(yè)務(wù)創(chuàng)新。云上提供了較為豐富的PaaS和SaaS服務(wù)，因此云也是這部分轉(zhuǎn)型的最佳選擇。業(yè)務(wù)創(chuàng)新上云的主要目的是：

• 云上提供豐富的創(chuàng)新能力，例如IoT、大數(shù)據(jù)、業(yè)務(wù)中臺，能夠大幅降低企業(yè)業(yè)務(wù)創(chuàng)新的門檻。
• 需要將業(yè)務(wù)快速推向新的市場。

三、上云所需的企業(yè)組織模型

企業(yè)上云和用云的整個生命周期，需要專業(yè)團(tuán)隊(duì)進(jìn)行合理的規(guī)劃、實(shí)施以及持續(xù)優(yōu)化云采用方案，推進(jìn)企業(yè)更好的利用上云的優(yōu)勢促進(jìn)業(yè)務(wù)發(fā)展。企業(yè)通常至少有一個云管理團(tuán)隊(duì)，或由相關(guān)負(fù)責(zé)人組建一個云卓越中心（Cloud Center of Excellence，簡稱CCoE）負(fù)責(zé)規(guī)劃和對接上云的整體方案，包括在公司層面確認(rèn)上云的整體計劃、步驟，以及收集業(yè)務(wù)團(tuán)隊(duì)的具體需求。

上云所需的企業(yè)組織模型

首先，我們看一下一個典型的企業(yè)組織架構(gòu)。為了便于理解，我們對這個組織結(jié)構(gòu)進(jìn)行了適當(dāng)?shù)暮喕?。在這個架構(gòu)中，不同的團(tuán)隊(duì)對公司的整體目標(biāo)進(jìn)行拆解，例如業(yè)務(wù)團(tuán)隊(duì)主要貢獻(xiàn)公司的營收、流入目標(biāo)，財務(wù)、法務(wù)等團(tuán)隊(duì)對公司的整體運(yùn)營風(fēng)險進(jìn)行控制，產(chǎn)品技術(shù)團(tuán)隊(duì)則為業(yè)務(wù)團(tuán)隊(duì)提供技術(shù)支撐。

核心職責(zé)

企業(yè)采用云服務(wù)的過程中有以下核心工作項(xiàng)：

• 上云策略：從公司戰(zhàn)略層面確定企業(yè)上云的動機(jī)和期望的業(yè)務(wù)結(jié)果。在充分論證企業(yè)上云的收益和風(fēng)險后，最重要的是在公司上下充分傳達(dá)和教育，確保公司高層、業(yè)務(wù)、研發(fā)、運(yùn)維、財務(wù)、人力資源等各個相關(guān)團(tuán)隊(duì)統(tǒng)一認(rèn)識，明確上云戰(zhàn)略，各團(tuán)隊(duì)能夠配合做出相應(yīng)的計劃和調(diào)整。制定企業(yè)上云計劃，包括業(yè)務(wù)范圍、上云的計劃節(jié)奏、各階段目標(biāo)以及最終結(jié)果。協(xié)調(diào)各部門準(zhǔn)備相應(yīng)的預(yù)算、調(diào)配人員和組建必要的團(tuán)隊(duì)。

• 上云準(zhǔn)備：準(zhǔn)備上云的基礎(chǔ)環(huán)境，對云服務(wù)進(jìn)行學(xué)習(xí)和測試，選擇小規(guī)模的業(yè)務(wù)進(jìn)行遷移驗(yàn)證。設(shè)計業(yè)務(wù)上云的整體架構(gòu)，其中包括遷移方案和基于云技術(shù)的創(chuàng)新。規(guī)劃業(yè)務(wù)上云的流程，協(xié)調(diào)業(yè)務(wù)部門配合實(shí)施業(yè)務(wù)上云。分階段逐步實(shí)施業(yè)務(wù)遷移上云，并在過程中調(diào)整方案，確保業(yè)務(wù)連續(xù)性和穩(wěn)定性。

• 應(yīng)用上云：梳理企業(yè)應(yīng)用系統(tǒng)清單，調(diào)研應(yīng)用上云兼容性等相關(guān)特征，篩選需要上云的應(yīng)用，制定應(yīng)用的上云策略。

• 持續(xù)治理：充分預(yù)見和評估企業(yè)安全合規(guī)等風(fēng)險，規(guī)劃企業(yè)IT治理的整體方案、策略和基本規(guī)則，包括資源結(jié)構(gòu)、身份權(quán)限、費(fèi)用賬單、合規(guī)審計、網(wǎng)絡(luò)架構(gòu)、安全策略以及監(jiān)控規(guī)則等。在企業(yè)上云和用云過程中，通過治理規(guī)則預(yù)防、發(fā)現(xiàn)和及時治理風(fēng)險。

為了適應(yīng)云采用框架，組織需要進(jìn)行以下準(zhǔn)備：

• 企業(yè)管理層：企業(yè)管理層需要明確云在公司的戰(zhàn)略地位以及各個團(tuán)隊(duì)?wèi)?yīng)該如何使用云。

• 云卓越中心：該團(tuán)隊(duì)可以是虛擬的組織，設(shè)計提供云服務(wù)的模式和管理體系，并提供相應(yīng)的技術(shù)準(zhǔn)備。其中的成員包括

  • 架構(gòu)師和專業(yè)技術(shù)人員，負(fù)責(zé)上云架構(gòu)設(shè)計和業(yè)務(wù)上云遷移工作；

  • 安全、合規(guī)等領(lǐng)域?qū)＜?，?fù)責(zé)設(shè)計企業(yè)IT治理方案、預(yù)估風(fēng)險和制定治理規(guī)則；

  • 財務(wù)專家，負(fù)責(zé)制定財務(wù)的管理流程，成本分?jǐn)傇瓌t。

• 云管理團(tuán)隊(duì)：在企業(yè)業(yè)務(wù)全面上云之后，持續(xù)優(yōu)化上云架構(gòu)，為新業(yè)務(wù)提供云上環(huán)境。建立企業(yè)云上運(yùn)維體系，搭建運(yùn)維平臺，以及通過自動化運(yùn)維的方式，對云上環(huán)境進(jìn)行持續(xù)治理和管理。根據(jù)新業(yè)務(wù)需求，分配所需云資源和所需權(quán)限，并對資源進(jìn)行初始化配置后交付。應(yīng)用運(yùn)維團(tuán)隊(duì)只需用云，無需關(guān)注基礎(chǔ)設(shè)施搭建。綜上，平臺運(yùn)維工作也可細(xì)分為架構(gòu)優(yōu)化、云平臺建設(shè)、資產(chǎn)管理、權(quán)限管理、云自動化等多種職責(zé)。

四、云上管理和治理框架

定義

如果把上云框架的搭建比作建設(shè)社區(qū)，那么企業(yè)的中心IT團(tuán)隊(duì)就是社區(qū)的總設(shè)計師。一個好的社區(qū)通常具備較為完善的頂層設(shè)計，最終才能提供優(yōu)質(zhì)服務(wù)給社區(qū)租戶。社區(qū)規(guī)劃首先要考慮的是基礎(chǔ)設(shè)施的布局和建設(shè)，包括道路的規(guī)劃、門禁的管理、停車場的布局、樓房規(guī)格的規(guī)劃等。其次，社區(qū)一般也會提供通用服務(wù)，例如垃圾分類、水電維修等，以及制定相應(yīng)的社區(qū)規(guī)約來管理租戶，例如裝修時間規(guī)定、噪音規(guī)定。作為增值服務(wù)，高檔社區(qū)還會提供統(tǒng)一的不同類型的樣板間，比如統(tǒng)一水電、裝修等。

在阿里云，我們建議企業(yè)在第一個應(yīng)用上云前，需要有一整套頂層設(shè)計和一系列基礎(chǔ)框架，為后續(xù)的業(yè)務(wù)上云掃清障礙。否則，可能會導(dǎo)致后續(xù)業(yè)務(wù)上云面臨成本、網(wǎng)絡(luò)、安全、效率等多方面的問題。業(yè)界通常把這些基礎(chǔ)框架叫做Landing Zone，我們也遵循這一命名方法。

如上所述，在成熟的運(yùn)維模型中，通常由企業(yè)的中心IT團(tuán)隊(duì)負(fù)責(zé)集中管理和管控，然后將云環(huán)境交付到業(yè)務(wù)團(tuán)隊(duì)。為了高效地提供安全、穩(wěn)定的云環(huán)境，中心IT團(tuán)隊(duì)需要搭建一套企業(yè)級的管理和治理框架作為云環(huán)境的基礎(chǔ)設(shè)施，為企業(yè)上云打好基礎(chǔ)。

例如，某跨國企業(yè)使用阿里云支撐公司多個業(yè)務(wù)系統(tǒng)，其中包含公司的互聯(lián)網(wǎng)業(yè)務(wù)和ERP，以及內(nèi)部的OA等系統(tǒng)，這些系統(tǒng)由不同的團(tuán)隊(duì)負(fù)責(zé)。為了更高效地使用云，公司成立新的“云平臺”部門負(fù)責(zé)和云的對接?！霸破脚_”的內(nèi)部定位是公司負(fù)責(zé)提供云能力的部門，以此加速IT和業(yè)務(wù)升級。具體而言，“云平臺”部門負(fù)責(zé)云上資源的快速交付、成本控制、質(zhì)量保證，同時賦能業(yè)務(wù)部門在安全的前提下進(jìn)行創(chuàng)新。“云平臺”在阿里云提供的Landing Zone的基礎(chǔ)上，構(gòu)建了整個云服務(wù)體系。

架構(gòu)

那么，一個完整的Landing Zone，究竟包括哪些方面？在參考了眾多企業(yè)客戶的實(shí)踐之后，我們定義了Landing Zone，其包含如下幾個功能模塊。

下表簡要描述了上述功能模塊。

五、企業(yè)應(yīng)用上云規(guī)劃

隨著企業(yè)信息系統(tǒng)的持續(xù)建設(shè)，IT與業(yè)務(wù)不斷的融合，企業(yè)應(yīng)用類型及模板不斷發(fā)展，如何從大量企業(yè)應(yīng)用系統(tǒng)中篩選需要上云的應(yīng)用，確定應(yīng)用上云的策略及優(yōu)先級，是上云實(shí)施前需要做的事情。所以，建議企業(yè)在上云遷移實(shí)施前，對企業(yè)總體應(yīng)用進(jìn)行上云規(guī)劃。以企業(yè)上云戰(zhàn)略及規(guī)劃為指導(dǎo)方向，梳理企業(yè)應(yīng)用系統(tǒng)清單，調(diào)研應(yīng)用上云兼容性等相關(guān)特征，制定應(yīng)用的上云策略，以及應(yīng)用上云遷移優(yōu)先級。阿里云上云評估模型如下圖所示。

上云兼容相關(guān)特征

上云兼容特性主要包含基礎(chǔ)設(shè)施相關(guān)兼容性以及應(yīng)用架構(gòu)兼容性特征；

基礎(chǔ)設(shè)施兼容性特征

• 硬件依賴性

  • 是否有特殊硬件要求，比如USB加密狗等；

• 性能要求

  • 是否有特殊性能要求，比如運(yùn)行環(huán)境CPU、內(nèi)存規(guī)格，IO或網(wǎng)絡(luò)要求等，云上是否能滿足；

• 操作系統(tǒng)要求

  • 是否有特殊版本操作系統(tǒng)要求，云上是否能提供；

應(yīng)用架構(gòu)兼容性特征

• 集中式/分布式架構(gòu)

  • 應(yīng)用是否分布式架構(gòu)，以及使用的分布式架構(gòu)框架，是否有對應(yīng)的PAAS產(chǎn)品支持兼容

• 源代碼可控性

  • 源代碼是否可操作及維護(hù)，是否有能力支持上云遷移或改造；

• 技術(shù)組件上云兼容性

  • 包含數(shù)據(jù)庫、存儲、中間件等技術(shù)組件，是否有對應(yīng)兼容的云產(chǎn)品；

其他特征

• 業(yè)務(wù)/技術(shù)痛點(diǎn)或訴求

  • 是否有業(yè)務(wù)或技術(shù)上的痛點(diǎn)或訴求，比如當(dāng)前集中式架構(gòu)迭代速度無法支持業(yè)務(wù)快速發(fā)展，需要做微服務(wù)改造；

• 資源/數(shù)據(jù)增長需求

  • 當(dāng)前基礎(chǔ)設(shè)施環(huán)境，是否滿足業(yè)務(wù)預(yù)期的資源或數(shù)據(jù)增長需求，以及數(shù)據(jù)增長要求對架構(gòu)提供優(yōu)化需求，比如數(shù)據(jù)庫容量無法滿足業(yè)務(wù)未來數(shù)據(jù)增量，在上云同時，需要做水平拆分；

• 安全合規(guī)要求

  • 是否有行業(yè)特征的安全合規(guī)要求，云的安全合規(guī)等級是否滿足行業(yè)要求；

• 容災(zāi)要求

  • 是否容災(zāi)或數(shù)據(jù)災(zāi)備要求，云產(chǎn)品能力是否支持；

上云策略

上云規(guī)劃階段，需要確認(rèn)應(yīng)用的上云策略，是否平遷或改造上云，根據(jù)阿里云的以往項(xiàng)目實(shí)踐，我們建議的上云策略包含以下幾點(diǎn)。

保持現(xiàn)狀

保留應(yīng)用程序在當(dāng)前的IT環(huán)境，作為非云基礎(chǔ)設(shè)施的一部分；

平遷上云

應(yīng)用比較容易移植到云環(huán)境上，使用云產(chǎn)品可替兼容替換技術(shù)組件，少量修改應(yīng)用配置后重新部署到新的云平臺。

優(yōu)化上云

通過使用云上PaaS產(chǎn)品及服務(wù)，對應(yīng)用進(jìn)行局部優(yōu)化，提升性能或穩(wěn)定性。

重構(gòu)上云

應(yīng)用組件不適配云的架構(gòu)，或者不符合成本效益，因此需要對應(yīng)用進(jìn)行重構(gòu)，基于新的云平臺構(gòu)建云原生架構(gòu)的應(yīng)用。

決策流程

根據(jù)業(yè)務(wù)調(diào)研階段輸出的應(yīng)用系統(tǒng)清單及應(yīng)用特征數(shù)據(jù)，每個應(yīng)用最終對應(yīng)上云評估策略的中一個類別。其決策流程可以參考下圖。

考慮到企業(yè)應(yīng)用系統(tǒng)規(guī)模較大，各方面資源無法保障所有應(yīng)用系統(tǒng)并行上云。所以，我們建議制定應(yīng)用上云優(yōu)先級，并明確遷移批次及計劃，使得所有資源能夠有效被利用，并降低上云風(fēng)險。

我們建議應(yīng)用上云優(yōu)先級的制定，以“速贏”為原則，即優(yōu)先遷移上云難度低且上云收益高的應(yīng)用。根據(jù)應(yīng)用的上云難度及上云價值收益，可以將應(yīng)用上云優(yōu)先級，劃分低中高三個象限，應(yīng)用上云優(yōu)化級制定方法如下圖所示。

應(yīng)用上云批次確認(rèn)后，根據(jù)企業(yè)上云戰(zhàn)略及規(guī)劃，制定企業(yè)應(yīng)用上云總體實(shí)施計劃，示例如下圖所示。

六、企業(yè)應(yīng)用上云實(shí)施流程

阿里云基于業(yè)界最佳實(shí)踐和大量上云項(xiàng)目的經(jīng)驗(yàn)累積，總結(jié)出以下遷云流程，這一過程建立在完成了企業(yè)應(yīng)用上云規(guī)劃后，以應(yīng)用為單位進(jìn)行進(jìn)一步的遷移計劃和實(shí)施。

在上云實(shí)施階段，應(yīng)用調(diào)研的目標(biāo)，是為了解應(yīng)用的應(yīng)用架構(gòu)以及使用的技術(shù)組件，以制定云上目標(biāo)詳細(xì)方案，包含云上應(yīng)用架構(gòu)設(shè)計，產(chǎn)品選型及容量評估、遷移方案以及割接方案，所以這一階段調(diào)研的信息比較詳細(xì)。

應(yīng)用架構(gòu)及依賴

• 應(yīng)用架構(gòu)

  • 應(yīng)用模塊及模塊間關(guān)系，節(jié)點(diǎn)配置及數(shù)量；應(yīng)用開發(fā)語言及框架。

• 應(yīng)用依賴

  • 其他應(yīng)用間的依賴關(guān)系，以及外部依賴，主要用于割接方案參考；

技術(shù)組件

• 數(shù)據(jù)庫

  • 數(shù)據(jù)庫類型，版本，數(shù)據(jù)量，性能要求等；

• 中間件

  • 中間件類型，版本，集群規(guī)模及容量【可選】，如消息隊(duì)列、緩存等；

• 存儲

  • 使用存儲設(shè)備的接口協(xié)議，及數(shù)據(jù)量；

應(yīng)用性能基線

• 應(yīng)用的性能指標(biāo)要求，用于測試驗(yàn)證階段性能測試目標(biāo)參考；

調(diào)研工具

如果企業(yè)系統(tǒng)非常龐大，應(yīng)用之間耦合多，各系統(tǒng)的負(fù)責(zé)部門不同，人工收集的方式難免會有疏漏，難以完整厘清所有應(yīng)用系統(tǒng)以及系統(tǒng)間的復(fù)雜依賴關(guān)系。我們建議使用阿里云提供針對企業(yè)應(yīng)用上云場景提供應(yīng)用發(fā)現(xiàn)服務(wù)（Application Discovery Service），滿足企業(yè)在遷云階段的評估、規(guī)劃、建設(shè)、遷移的需求評估。采用無侵入式采集技術(shù)，不影響在線業(yè)務(wù)的性能前提下從主機(jī)和進(jìn)程兩個維度構(gòu)建架構(gòu)拓?fù)?，自動分析識別主機(jī)和進(jìn)程信息、資源使用水位以及各應(yīng)用和組件之間的依賴關(guān)系。更多詳情，請參見應(yīng)用發(fā)現(xiàn)服務(wù)。

平遷上云方案

產(chǎn)品選型策略

針對傳統(tǒng)應(yīng)用平遷上云場景，常見產(chǎn)品對標(biāo)選型策略如下圖所示。

場景示例1：單體應(yīng)用遷移

云上重部署應(yīng)用

針對平遷方式的應(yīng)用上云場景，對于已有成熟CI/CD工具及流程的企業(yè)，我們建議優(yōu)先使用現(xiàn)有CI/CD工具，在云上重新部署應(yīng)用。

對于還沒有構(gòu)建CI/CD能力的企業(yè)，我們建議先使用云上DevOps產(chǎn)品構(gòu)建企業(yè)的CI/CD自動化平臺，通過CI/CD流水線，在云上重新部署應(yīng)用?；诎⒗镌圃菩Мa(chǎn)品構(gòu)建CI/CD流水線如下圖所示。

鏡像遷移

對于普通單體應(yīng)用，也可以使用阿里云自主研發(fā)的遷移平臺服務(wù)器遷移中心（Server Migration Center，簡稱SMC），可將單臺或多臺遷移源遷移至阿里云。遷移源（或源服務(wù)器）概指企業(yè)待遷移IDC服務(wù)器、虛擬機(jī)、其他云平臺的云主機(jī)或其他類型的服務(wù)器。在應(yīng)用服務(wù)遷移過程中，使用SMC服務(wù)將在IDC部署的業(yè)務(wù)應(yīng)用服務(wù)自動、快速、一站式遷移到云上ECS，同時提供工具支持將自建Kubernetes的應(yīng)用遷移到云上。更多詳細(xì)信息，請參見最佳實(shí)踐概覽。

場景示例2：微服務(wù)應(yīng)用遷移

對于微服務(wù)應(yīng)用上云，可以使用阿里云企業(yè)級分布式應(yīng)用服務(wù)EDAS（Enterprise Distributed Application Service），它是一個應(yīng)用托管和微服務(wù)管理的PaaS平臺，提供應(yīng)用開發(fā)、部署、監(jiān)控、運(yùn)維等全棧式解決方案，支持SpringCloud、Dubbo等微服務(wù)運(yùn)行環(huán)境。

對于Spring Cloud Edgware及以上版本和Dubbo 2.5.3及以上版本的微服務(wù)應(yīng)用，無需修改任何一行代碼即可遷移至EDAS。

針對Spring Cloud和Dubbo微服務(wù)框架應(yīng)用遷移上EDAS，有兩種方案，切流遷移、雙注冊和雙訂閱遷移。這兩種方案都可以保證您的應(yīng)用正常運(yùn)行且不中斷地完成遷移。

切流遷移

使用Dubbo將原有的服務(wù)注冊中心切換到微服務(wù)引擎（Micro Service Engine，簡稱MSE），在云上部署一套新的應(yīng)用，最后通過SLB和域名配置來進(jìn)行切流。

雙注冊和雙訂閱遷移

• 在應(yīng)用遷移時同時接入兩個注冊中心（原有注冊中心和EDAS注冊中心），保證已遷移的應(yīng)用和未遷移的應(yīng)用之間能夠相互調(diào)用。通過雙注冊和雙訂閱遷移應(yīng)用的架構(gòu)圖如下。

• 支持在不重啟應(yīng)用的情況下，動態(tài)地變更服務(wù)注冊的策略和服務(wù)訂閱的策略，只需要重啟一次應(yīng)用就可以完成遷移。

• 已遷移的應(yīng)用和未遷移的應(yīng)用可以互相發(fā)現(xiàn)，從而實(shí)現(xiàn)互相調(diào)用，保證了業(yè)務(wù)的連續(xù)性。

• 使用方式簡單，只需要添加依賴，并修改一行代碼，就可以實(shí)現(xiàn)雙注冊和雙訂閱。

• 支持查看消費(fèi)者服務(wù)調(diào)用列表詳情，實(shí)時地查看遷移進(jìn)度。

• 更多詳細(xì)信息，請參見產(chǎn)品最佳實(shí)踐平滑遷移微服務(wù)應(yīng)用至EDAS

優(yōu)化上云方案

場景示例：應(yīng)用容器化上云

以Kubernetes為代表的容器技術(shù)正成為云計算新界面。容器提供了應(yīng)用分發(fā)和交付標(biāo)準(zhǔn)，將應(yīng)用與底層運(yùn)行環(huán)境進(jìn)行解耦。Kubernetes 作為資源調(diào)度和編排的標(biāo)準(zhǔn)，屏蔽底層架構(gòu)差異性，幫助應(yīng)用平滑運(yùn)行在不同基礎(chǔ)設(shè)施上。

應(yīng)用容器化規(guī)范化改造

容器化的應(yīng)用必須要規(guī)范化，我們不希望所完成的容器鏡像只能在生產(chǎn)環(huán)境中運(yùn)行，也不希望該容器有著外部依賴，我們希望應(yīng)用在容器化之前，最少滿足這三項(xiàng)要求：

• 與操作系統(tǒng)解耦，能在各種系統(tǒng)中運(yùn)行并有極大的可移植性

• 適合部署在現(xiàn)代的云平臺上，配置與代碼分離

• 開發(fā)與生產(chǎn)環(huán)境對等，能夠使用現(xiàn)代的包管理工具實(shí)施封裝打包

所以，對應(yīng)用進(jìn)行容器化前，必須對應(yīng)用進(jìn)行檢查并實(shí)施類似的改造，也就是進(jìn)行應(yīng)用規(guī)范化，規(guī)范化的過程根據(jù)已有應(yīng)用的實(shí)際情況有較大的不同，一般來說，越是現(xiàn)代的、面向互聯(lián)網(wǎng)的應(yīng)用越容易容器化。對容器化應(yīng)用的規(guī)范化改造有以下內(nèi)容：

• ·準(zhǔn)代碼：明確一份代碼，多分部署的原則，一個應(yīng)用程序只能有且只有一個代碼庫或一個主庫，確保該代碼庫中能夠支持開發(fā)、測試、構(gòu)建操作。

• 依賴管理：大多數(shù)編程語言都會提供一個打包系統(tǒng)，用來為各個類庫提供打包服務(wù)，我們期望應(yīng)用程序能夠顯式的表示自己的依賴，使用pom.xml或者package.json來描述自己的全部依賴，不要有隱式依賴。這樣能夠?yàn)殚_發(fā)者和流水線簡化配置流程，可以完成一句話構(gòu)建。

• 配置注入：數(shù)據(jù)庫地址、三方證書、API Key等等這些在不同環(huán)境下有區(qū)別的配置應(yīng)該能夠獨(dú)立注入，我們要求在不同環(huán)境下，容器一致，但配置不同?？梢允褂铆h(huán)境變量或 Config Service 方式進(jìn)行管理，使用Config Service時也需要做到無依賴。

• 服務(wù)配置化：后端依賴的服務(wù)比如數(shù)據(jù)庫MySQL、PostgreSQL、緩存、隊(duì)列等都需要做到可配置化，將配置拿出，系統(tǒng)不應(yīng)該區(qū)別對待這些服務(wù)。

• 進(jìn)程整理：應(yīng)用程序盡量做到一個進(jìn)程運(yùn)行，如果使用多個進(jìn)程比如Nginx + PHP也可以接受，但一定要目的單一，易于管理。同時也需要保證進(jìn)程的無狀態(tài)特性，使用內(nèi)存存儲 session 造成粘性是無法接受的，并且狀態(tài)應(yīng)該持久化入數(shù)據(jù)庫。單一的、無狀態(tài)的進(jìn)程也可以反映到并發(fā)上。

• 易處理：表示可以瞬間開啟或停止，這有利于快速、彈性的伸縮應(yīng)用，迅速部署變化的代碼或配置 ，穩(wěn)健的部署應(yīng)用。當(dāng)然也需要支持優(yōu)雅的終止，即受到SIGTERM后會處理完任務(wù)，或者在服務(wù)中心注銷，再進(jìn)行關(guān)閉。

容器化上云流程

傳統(tǒng)應(yīng)用容器化大致分為五個階段：

• 應(yīng)用現(xiàn)狀分析：梳理應(yīng)用使用的資源、系統(tǒng)的邏輯架構(gòu)拓樸、應(yīng)用服務(wù)的所有數(shù)據(jù)依賴、應(yīng)用上下游服務(wù)依賴關(guān)系、服務(wù)所依賴的進(jìn)程、系統(tǒng)中需要保留的重要日志及數(shù)據(jù)、數(shù)據(jù)和文件權(quán)限等；

• 方案規(guī)劃和設(shè)計：根據(jù)前期對應(yīng)用系統(tǒng)現(xiàn)狀的調(diào)研和分析結(jié)合容器平臺特性，應(yīng)用系統(tǒng)產(chǎn)出新的系統(tǒng)架構(gòu)圖和遷移的改造計劃，比如是直接容器化上云還是改造后再容器化上云，以及容器化后業(yè)務(wù)系統(tǒng)功能和性能測試方案、系統(tǒng)的割接方案等。

• 編寫Dockerfile：若要打包應(yīng)用程序以供在Docker中運(yùn)行，需要編寫腳本文件Dockerfile，用于自動執(zhí)行所有應(yīng)用程序部署時需要執(zhí)行的步驟。這通常包括一些Shell配置命令，以及用于復(fù)制應(yīng)用程序包、設(shè)置所有依賴項(xiàng)的指令，也可以解壓縮已壓縮的存檔或安裝包。Docker鏡像是一個特殊的文件系統(tǒng)，除了提供容器運(yùn)行時所需的程序、庫、資源、配置等文件外，還包含了一些為運(yùn)行時準(zhǔn)備的一些配置參數(shù)（如匿名卷、環(huán)境變量、用戶等）。在Docker鏡像使用中，我們最好把經(jīng)常變化的內(nèi)容和基本不會變化的內(nèi)容要分開，把不怎么變化的內(nèi)容放在下層，創(chuàng)建一個基礎(chǔ)鏡像供上層使用。

• 生成鏡像：使用docker commit命令將某個container的環(huán)境提交成為持久化的docker image。使用docker build命令基于dockerfile構(gòu)建。 這種構(gòu)建方式的優(yōu)勢在于可以通過docker history命令溯源鏡像的生成過程。并且消除了docker commit可能把一些不需要的東西誤提交的隱患。鏡像構(gòu)建成功后，只要有docker環(huán)境就可以使用，通過利用docker push命令將鏡像推送到鏡像倉庫中去。

• 應(yīng)用部署：將docker鏡像部署到對應(yīng)Kubernetes集群應(yīng)用。在Kubernetes集群上需要用到的部署模板，在具體實(shí)施過程中，可以根據(jù)不同的模板來部署到對應(yīng)不同的集群。

重構(gòu)上云方案

傳統(tǒng)單體應(yīng)用架構(gòu)問題

• 單體應(yīng)用復(fù)雜度高，應(yīng)用迭代發(fā)布周期慢，無法支撐業(yè)務(wù)快速發(fā)展的需求。

• 開發(fā)者需要關(guān)注架構(gòu)的所有細(xì)節(jié)（限流、熔斷、降級等服務(wù)治理，數(shù)據(jù)訪問及消息通信）。

• 運(yùn)維需要負(fù)責(zé)底層基礎(chǔ)設(shè)施（包括數(shù)據(jù)庫、緩存、虛擬機(jī)等）的穩(wěn)定性。

云原生應(yīng)用架構(gòu)

云原生應(yīng)用架構(gòu)特點(diǎn)

• 應(yīng)用代碼按業(yè)務(wù)域拆分解耦，降低復(fù)雜度。

• 開發(fā)者只需關(guān)注業(yè)務(wù)邏輯，與業(yè)務(wù)不相關(guān)功能下沉到云基礎(chǔ)設(shè)施。

• 技術(shù)體系走向開放和標(biāo)準(zhǔn)。

• 運(yùn)維無需關(guān)注基礎(chǔ)設(shè)施穩(wěn)定性，更多精力專注于自動化。

云原生應(yīng)用架構(gòu)建議

云原生應(yīng)用架構(gòu)示例，如下圖所示。

• 微服務(wù)解決“應(yīng)用架構(gòu)復(fù)雜度”問題。

• 服務(wù)治理解決“業(yè)務(wù)開發(fā)關(guān)注與業(yè)務(wù)無關(guān)的限流、熔斷、降級能力”。

• 容器解決應(yīng)用“部署問題”問題。

• Kubernetes解決應(yīng)用“編排和調(diào)度”問題。

• Service Mesh解決“侵入性微服務(wù)改造”問題。

場景示例：應(yīng)用微服務(wù)化重構(gòu)上云

對于復(fù)雜應(yīng)用系統(tǒng)來說，單體應(yīng)用架構(gòu)代碼復(fù)雜度高、可擴(kuò)展性差、業(yè)務(wù)開發(fā)及部署周期慢，不能滿足現(xiàn)業(yè)務(wù)發(fā)展需要。對于業(yè)務(wù)復(fù)雜的單體應(yīng)用系統(tǒng)上云需求，我們建議以微服務(wù)化重構(gòu)改造上云。

核心問題

• 服務(wù)拆分

  如何將單體應(yīng)用進(jìn)行服務(wù)化改造，是“一步到位，推倒重來”還是“循序漸進(jìn)的蠶食”，選取哪些功能或業(yè)務(wù)進(jìn)行服務(wù)化改造，如何減少對原單體應(yīng)用的修改等，這些都是在服務(wù)拆分時首要面對的問題。

• 跨服務(wù)查詢

  單體應(yīng)用里實(shí)現(xiàn)查詢相對簡單，因?yàn)榫哂薪y(tǒng)一的數(shù)據(jù)庫。但在微服務(wù)架構(gòu)下，一個查詢可能需要檢索分布在不同的服務(wù)中數(shù)據(jù)，而這些服務(wù)都會擁有自己的數(shù)據(jù)庫。傳統(tǒng)的分布式數(shù)據(jù)查詢機(jī)制不適用，因?yàn)闀蚱品?wù)之間的數(shù)據(jù)隔離性，該隔離性要求以服務(wù)的形式提供數(shù)據(jù)，不能直接暴露數(shù)據(jù)庫。

改造原則

• 漸進(jìn)式，不要“推倒重來，一步到位”

  • 快速見效、快速收到回報、可挑選出高價值的模塊先進(jìn)行服務(wù)化改造，更早的拿到結(jié)果來獲得業(yè)務(wù)團(tuán)隊(duì)的支持。

• 減少對單體應(yīng)用的改動

  • 單體應(yīng)用的修改是不可避免的，重要的是要減少改動同時保持?jǐn)?shù)據(jù)一致性。

• 改造主要從業(yè)務(wù)維度入手，少量的技術(shù)維度。

• 拆分時做“垂直切片”

  • 含業(yè)務(wù)邏輯、庫表結(jié)構(gòu)等前后端邏輯。

改造策略

（1）新業(yè)務(wù)構(gòu)建為服務(wù)

將新的業(yè)務(wù)或功能以服務(wù)的形式進(jìn)行構(gòu)建，這不僅會阻止單體擴(kuò)大和繼續(xù)發(fā)展，快速開發(fā)出新業(yè)務(wù)功能，更體現(xiàn)出微服務(wù)架構(gòu)的價值。常見的辦法是對新業(yè)務(wù)進(jìn)行領(lǐng)域建模，得到領(lǐng)域模型、服務(wù)接口等必要元素。但同時會帶來問題，即新舊系統(tǒng)結(jié)合，即微服務(wù)與單體應(yīng)用怎么協(xié)作。

• 問題識別

  無論是新構(gòu)建的微服務(wù)，還是舊系統(tǒng)提取的新服務(wù)，都會面臨新舊系統(tǒng)如何結(jié)合的問題。新的微服務(wù)與單體應(yīng)用同時存在，許多業(yè)務(wù)還需要新舊系統(tǒng)彼此協(xié)作才能完成。但新舊系統(tǒng)存在各種差異，如：協(xié)議不同（微服務(wù)以REST為主，而單體式可能基于SOAP或TCP），模型不同（實(shí)體、名稱及屬性等）。我們推薦的方案是使用雙向代理層來完成新舊系統(tǒng)的交互與對接。

• 解決方案

  • 雙向代理層

  在微服務(wù)和單體應(yīng)用之間構(gòu)建一個雙向代理層，通過代理層完成新舊系統(tǒng)的對接集成，避免相互干擾，保持彼此松耦合狀態(tài)。代理層還可以對單體式應(yīng)用進(jìn)行服務(wù)化封裝，讓其像微服務(wù)一樣以 REST的方式對外服務(wù)。代理層支持雙向通訊，重點(diǎn)解決新舊系統(tǒng)對接集成、協(xié)議適配和模型轉(zhuǎn)換等問題，按照此功能定位我們可以將代理層劃分成三個模塊：

  • • 舊系統(tǒng)側(cè)的集成對接：采用外觀（Facade）模式，屏蔽舊系統(tǒng)內(nèi)部細(xì)節(jié)，簡化新系統(tǒng)對接的復(fù)雜度。

    • 舊系統(tǒng)側(cè)的協(xié)議適配：采用Adapter模式，向新系統(tǒng)提供所需的服務(wù)實(shí)體，負(fù)責(zé)請求和應(yīng)答的協(xié)議適配。

    • 領(lǐng)域模型轉(zhuǎn)換器：負(fù)責(zé)請求和應(yīng)答中新舊系統(tǒng)領(lǐng)域模型的轉(zhuǎn)換，新舊系統(tǒng)都需要。

  • 領(lǐng)域事件

  單體與微服務(wù)之間的數(shù)據(jù)交互，使用API是較為直接的方式。但當(dāng)一方數(shù)據(jù)變化后，API方式無法主動進(jìn)行通知。因此，另一個方式是基于領(lǐng)域事件的數(shù)據(jù)同步。比如：單體應(yīng)用發(fā)布領(lǐng)域事件，微服務(wù)進(jìn)行訂閱。當(dāng)單體數(shù)據(jù)產(chǎn)生變化時，可以通過領(lǐng)域事件的方式通知微服務(wù)，微服務(wù)獲取事件，更新本地數(shù)據(jù)，供本地業(yè)務(wù)查詢使用。

（2）業(yè)務(wù)功能提取為微服務(wù)

• 挑戰(zhàn)：對單體應(yīng)用做拆分時，采取的策略是自上而下的“垂直切分”，要涵蓋被拆分的業(yè)務(wù)的全部邏輯，主要包含業(yè)務(wù)邏輯及數(shù)據(jù)庫表。為此帶來了一些挑戰(zhàn)：

  • 領(lǐng)域模型的拆分：跨服務(wù)的對象引用、通用類的拆分等

  • 數(shù)據(jù)庫表的拆解分，如：從已有的表中拆出新表

• 提取入口：關(guān)于提取哪些部分進(jìn)行服務(wù)化，一個重要判斷點(diǎn)是否能給業(yè)務(wù)快速帶來價值，而價值可以從新業(yè)務(wù)上線效率，或解決棘手的性能及擴(kuò)展性等方面來考慮。一般來說，具有下面特點(diǎn)的功能模塊可以入手來做改造，提取功能為服務(wù)后，同時也需要重構(gòu)數(shù)據(jù)庫。如：改造數(shù)據(jù)庫的庫表結(jié)構(gòu)，提取并創(chuàng)建新服務(wù)對應(yīng)的表及數(shù)據(jù)。

  • 頻繁變化（業(yè)務(wù)維度）

  • 頻繁調(diào)用

  • 相對獨(dú)立

  • 共享的基礎(chǔ)數(shù)據(jù)

  • 計算密集型（利于彈性伸縮，技術(shù)維度）

• 最小化改造：對單體應(yīng)用進(jìn)行改造，勢必會帶來領(lǐng)域模型、庫表結(jié)構(gòu)等的變化。例如：我們拆分訂單業(yè)務(wù)，提取出送貨子業(yè)務(wù)。這些變化會直接影響代碼，即要求對變化的部分做出代碼調(diào)整。由于每一處訪問變化部分的代碼都需要，這會直接修改單體應(yīng)用的代碼，可能帶來較大工作量，這是我們不愿意看到的，因?yàn)榇罅抗ぷ骰ㄙM(fèi)在要被替代的單體應(yīng)用上。理想的方式是，在拆分出新服務(wù)的同時，不修改或盡量減少修改原有單體應(yīng)用。

  • 保持單體應(yīng)用的數(shù)據(jù)庫結(jié)構(gòu)基本不變；

  • 拆分出的新服務(wù)使用獨(dú)立的新庫表結(jié)構(gòu)；

  • 新服務(wù)獲取數(shù)據(jù)后寫入新的庫表；

  • 使用觸發(fā)器之類機(jī)制將新庫表的數(shù)據(jù)同步到單體應(yīng)用庫表；

  • 在單體應(yīng)用里，只需修改代碼去調(diào)用新服務(wù)即可；數(shù)據(jù)讀取可依賴原有單體應(yīng)用。

專項(xiàng)上云方案

數(shù)據(jù)上云方案

數(shù)據(jù)上云架構(gòu)設(shè)計

數(shù)據(jù)在同一業(yè)務(wù)庫中采用多租戶隔離機(jī)制；為數(shù)據(jù)服務(wù)層建立一套統(tǒng)一的管理規(guī)范，所有業(yè)務(wù)用戶賬號在完成相關(guān)審批流程后對相應(yīng)的數(shù)據(jù)字段進(jìn)行授權(quán)安全訪問，對數(shù)據(jù)只有讀的權(quán)限，不能對原始數(shù)據(jù)進(jìn)行直接修改或刪除，做到數(shù)據(jù)不搬家，可用不可見；建立統(tǒng)一的數(shù)據(jù)資源視圖和數(shù)據(jù)血緣跟蹤能力，能夠?qū)λ械臄?shù)據(jù)的生命周期進(jìn)行溯源查詢，用以甄別數(shù)據(jù)變更過程中的真實(shí)性和準(zhǔn)確性；根據(jù)不同業(yè)務(wù)場景結(jié)合流程節(jié)點(diǎn)和風(fēng)險管控要求，對相關(guān)數(shù)據(jù)進(jìn)行分析、建模、挖掘，提高數(shù)據(jù)服務(wù)支持。

數(shù)據(jù)上云安全防護(hù)

在企業(yè)數(shù)據(jù)遷移上云的過程中,實(shí)施數(shù)據(jù)分層保護(hù)功能已成為一個關(guān)鍵優(yōu)先事項(xiàng)。同時，數(shù)據(jù)保護(hù)控制必須輔之以強(qiáng)大的監(jiān)控工具和訪問管理控制,以構(gòu)建數(shù)據(jù)的整體視圖，對數(shù)據(jù)的全生命周期進(jìn)行監(jiān)控。重點(diǎn)考慮以下關(guān)鍵數(shù)據(jù)保護(hù)領(lǐng)域。

• 數(shù)據(jù)分類：圍繞數(shù)據(jù)識別、清單、標(biāo)簽和分類的功能和流程；

• 靜態(tài)數(shù)據(jù)保護(hù)：有關(guān)加密/令牌化的解決方案和注意事項(xiàng),包括密鑰管理；

• 傳輸中數(shù)據(jù)保護(hù)：功能包括 TLS/SSL 層保護(hù)、數(shù)據(jù)丟失防護(hù)解決方案和安全數(shù)據(jù)傳輸；

• 數(shù)據(jù)監(jiān)控：通過操作中心 (SOC) 進(jìn)行日志記錄和監(jiān)視功能；

• 在云環(huán)境中,以數(shù)據(jù)為中心的保護(hù)需要在整個數(shù)據(jù)生命周期中進(jìn)行。

阿里云數(shù)據(jù)上云遷移最佳實(shí)踐

數(shù)據(jù)庫上云

包含關(guān)系數(shù)據(jù)庫及NoSQL數(shù)據(jù)庫上云等場景，以Mysql為例，主要考慮以下幾點(diǎn)：

• 根據(jù)性能場景需求，選擇匹配的產(chǎn)品及實(shí)例規(guī)格，以最低成本達(dá)到業(yè)務(wù)需求

  比如RDS和PolarDB，RDS主要是主備模式，讀寫IO在單機(jī)上執(zhí)行，走主機(jī)總線，RT相對較低，而PolarDB是云原生的讀寫分離架構(gòu)，讀寫IO會走網(wǎng)絡(luò)，RT相對較高。從產(chǎn)品架構(gòu)上分析，對于RT要求比較高的場景，建議使用RDS，其他情況，相同規(guī)格PolarDB實(shí)例一般比RDS QPS性能要高。

• 未來數(shù)據(jù)增長

  未來三年內(nèi)數(shù)據(jù)增長，如果超過單實(shí)例最高規(guī)格性能，建議PolarDB-X，通過水平切分的方式，將數(shù)據(jù)分布在多個底層mysql庫，通過并行的分布式數(shù)據(jù)庫操作來實(shí)現(xiàn)性能的提升。

• 遷移過程數(shù)據(jù)膨脹

  全量數(shù)據(jù)遷移過程并發(fā)INSERT導(dǎo)致目標(biāo)實(shí)例的表存在碎片，全量遷移完成后目標(biāo)實(shí)例的表空間會比源實(shí)例大（遷移完成后可通過optimize table合并碎片，優(yōu)化存儲空間），所以建議選擇實(shí)例規(guī)格時，預(yù)留一定的存儲空間以防存儲打滿；

• 識別無主鍵表

  無主鍵表不支持增量遷移，需要提前識別，對于無主鍵表單獨(dú)做全量遷移。

阿里云數(shù)據(jù)庫上云遷移工具及最佳實(shí)踐

數(shù)據(jù)傳輸（Data Transmission，簡稱DTS）是阿里云提供的一種支持關(guān)系型數(shù)據(jù)庫、 NoSQL、OLAP等多種數(shù)據(jù)源之間數(shù)據(jù)交互的數(shù)據(jù)服務(wù)。DTS的數(shù)據(jù)遷移功能支持同構(gòu)或異構(gòu)數(shù)據(jù)源之間的數(shù)據(jù)遷移，同時提供了庫表列三級映射、數(shù)據(jù)過濾等多種ETL特性，適用于多種數(shù)據(jù)庫遷移上云場景。

存儲數(shù)據(jù)上云

主要指非結(jié)構(gòu)化數(shù)據(jù)，常見于內(nèi)容管理類型的應(yīng)用系統(tǒng)，涉及大量文件對象的存儲和管理，傳統(tǒng)的解決方案包括：

• 本地磁盤存儲，數(shù)據(jù)定期備份。但這種方案存儲容量和性能的擴(kuò)展性、存儲自身的高可用性等問題。

• 采用IP-SAN、NAS等對數(shù)據(jù)做集中存儲，這種方案成本較高；

• 在數(shù)據(jù)庫中存儲文件。這種方案成本高，對數(shù)據(jù)庫的存儲資源消耗和性能影響都比較大。

針對文件對象存儲，阿里云提供開放存儲服務(wù)（OSS），具備高可用、高擴(kuò)展、高效性、低成本等特點(diǎn)，能有效解決內(nèi)容管理類型應(yīng)用的文件對象的存儲問題。 應(yīng)用系統(tǒng)需要基于OSS進(jìn)行相關(guān)改造，主要包括：

• 根據(jù)應(yīng)用系統(tǒng)文件的存儲結(jié)構(gòu)在OSS中規(guī)劃Bucket，以及文件目錄結(jié)構(gòu)；

• 設(shè)置Bucket訪問權(quán)限（public-read-write/public-read/private），對于安全級別要求高的應(yīng)用，可設(shè)置文件在OSS上以密文形式存儲；

• 對程序代碼進(jìn)行掃描，查找出涉及文件向存儲讀寫的代碼，將這些代碼改造為以O(shè)SS SDK接口的實(shí)現(xiàn)。

阿里云存儲數(shù)據(jù)上云遷移工具

阿里云在線遷移服務(wù)是阿里云提供的存儲產(chǎn)品數(shù)據(jù)通道。使用在線遷移服務(wù)，可以將第三方數(shù)據(jù)輕松遷移至阿里云對象存儲OSS，詳情請參見在線遷移服務(wù)。

建立上云遷移組織及保障機(jī)制

在上云遷移實(shí)施前，需要建立遷移組織及保障機(jī)制，明確各小組職責(zé)及成員，確定保障機(jī)制把握項(xiàng)目工作進(jìn)度和工作質(zhì)量。

遷移組織架構(gòu)

根據(jù)阿里云以往項(xiàng)目經(jīng)驗(yàn)，建議組織分為以下小組，如下圖所示，各小組職責(zé)如下。

• 項(xiàng)目管理辦公室

  • 負(fù)責(zé)項(xiàng)目進(jìn)度、風(fēng)險及問題管理，以及內(nèi)部宣貫。

• 實(shí)施架構(gòu)組

  • 負(fù)責(zé)總組上云方案、割接方案設(shè)計，以及項(xiàng)目實(shí)施過程中技術(shù)風(fēng)險把控。

• 應(yīng)用開發(fā)組

  • 負(fù)責(zé)應(yīng)用開發(fā)、部署及應(yīng)用遷移實(shí)施工作；

• 運(yùn)維組

  • 負(fù)責(zé)云上資源管理、數(shù)據(jù)組、中間件遷移實(shí)施及數(shù)據(jù)校驗(yàn)工作；

• 測試組

  • 負(fù)責(zé)功能測試、聯(lián)調(diào)測試及性能測試工作。

項(xiàng)目實(shí)施保障機(jī)制

建立項(xiàng)目管控機(jī)制，把握工作進(jìn)度和工作質(zhì)量，包含以下內(nèi)容：

• 內(nèi)部定期溝通計劃

• 項(xiàng)目周報制度

• 問題和風(fēng)險分析計劃

制定遷移實(shí)施計劃

由于上云遷移實(shí)施存在風(fēng)險，所以，在應(yīng)用上云實(shí)施執(zhí)行前，我們建議制定詳細(xì)的實(shí)施計劃。這個計劃表里面包含了上云遷移及割接過程的全部任務(wù)、時間段、各方人員等。項(xiàng)目實(shí)施過程按照這個計劃表跟蹤執(zhí)行即可。下圖給出一個示例模板，在具體的項(xiàng)目中可以根據(jù)項(xiàng)目需求來設(shè)計定制。

功能測試及聯(lián)調(diào)測試

在應(yīng)用上云割接前，需要進(jìn)行充分的功能測試與聯(lián)調(diào)測試，驗(yàn)證云上環(huán)境應(yīng)用運(yùn)行情況。功能測試及聯(lián)調(diào)測試依賴企業(yè)自己的測試團(tuán)隊(duì)及流程工作，不作過多描述，僅在此建議，對應(yīng)用功能點(diǎn)進(jìn)行分級，優(yōu)先測試驗(yàn)證核心功能點(diǎn)，對不同級別功能點(diǎn)測試問題，制定不同緊急程度的問題跟蹤。

性能測試

性能測試方案

性能測試流程

業(yè)務(wù)測試模型構(gòu)建

業(yè)務(wù)測試模型構(gòu)建主要是根據(jù)搜集到的性能測試需求和生產(chǎn)系統(tǒng)的相關(guān)信息完成性能模型的構(gòu)建工作，并指導(dǎo)性能測試過程以及測試結(jié)果的生成。

監(jiān)控性能指標(biāo)

監(jiān)控指標(biāo)包含業(yè)務(wù)監(jiān)控指標(biāo)、操作系統(tǒng)監(jiān)控指標(biāo)、中間件監(jiān)控指標(biāo)、數(shù)據(jù)庫監(jiān)控指標(biāo)，旨在監(jiān)控從各個維度描述壓測時性能表現(xiàn)。

構(gòu)建性能測試數(shù)據(jù)

測試數(shù)據(jù)主要包含兩類：

• 基礎(chǔ)測試數(shù)據(jù)

  基礎(chǔ)測試數(shù)據(jù)一般取自生產(chǎn)環(huán)境真實(shí)請求日志?；A(chǔ)測試數(shù)據(jù)非常適合真實(shí)業(yè)務(wù)模型，當(dāng)然，也可以對基礎(chǔ)測試數(shù)據(jù)進(jìn)行過濾處理，獲取單一業(yè)務(wù)場景測試數(shù)據(jù)。

• 采用參數(shù)化測試數(shù)據(jù)

  參數(shù)化測試數(shù)據(jù)主要根據(jù)業(yè)務(wù)請求參數(shù)，按測試模型場景構(gòu)建。參數(shù)化測試涉及的范圍很多，比如需要準(zhǔn)備大量用戶名及相應(yīng)密碼參數(shù)數(shù)據(jù)；模擬納稅人納稅申報，需要準(zhǔn)備大量的納稅人識別號、納稅人內(nèi)碼或納稅人系統(tǒng)內(nèi)部識別號等參數(shù)數(shù)據(jù)，這類數(shù)據(jù)準(zhǔn)備要求符合實(shí)際運(yùn)行要求并且保證數(shù)據(jù)表之間的關(guān)聯(lián)關(guān)系。

測試場景

常見性能測試場景，主要包含以下幾種：

• 基準(zhǔn)測試

  • 基準(zhǔn)測試的目的是檢查業(yè)務(wù)本身是否存在性能缺陷。同時為將來的混合場景的性能測試性能分析提供參考依據(jù)。

• 穩(wěn)定性測試

  • 穩(wěn)定性測試主要側(cè)重系統(tǒng)在持續(xù)的壓力情況下，長期運(yùn)行時的業(yè)務(wù)處理能力及系統(tǒng)可能存在的缺陷。

• 業(yè)務(wù)突變測試

  • 業(yè)務(wù)突變測試主要考察當(dāng)業(yè)務(wù)進(jìn)行突變以后，系統(tǒng)是否出現(xiàn)異常情況，資源在突變前后變化情況。

• 可靠性測試

  • 可靠性測試主要是模擬各種故障（網(wǎng)絡(luò)中斷，服務(wù)異常、HA切換）下，系統(tǒng)是否能正確切換，處理能力是否有明顯變化。

測試實(shí)施及報告

基于測試工具，構(gòu)建對應(yīng)測試場景的腳本，執(zhí)行后，通過測試結(jié)果，并根據(jù)觀測的性能指標(biāo)，撰寫測試報告；

測試工具

阿里云性能測試PTS（PerformanceTesting Service）產(chǎn)品是面向所有技術(shù)背景人員的云化測試工具。PTS是具備強(qiáng)大的分布式壓測能力的 SaaS 壓測平臺，可模擬海量用戶的真實(shí)業(yè)務(wù)場景，全方位驗(yàn)證業(yè)務(wù)站點(diǎn)的性能、容量和穩(wěn)定性。

PTS 目標(biāo)是將性能壓測本身的工作持續(xù)簡化，使您可以將更多的精力回歸到關(guān)注業(yè)務(wù)和性能問題本身。在PTS 平臺上，您可以用較低的人力和資源成本，構(gòu)造出最接近真實(shí)業(yè)務(wù)場景的復(fù)雜交互式流量，快速衡量系統(tǒng)的業(yè)務(wù)性能狀況，為性能問題定位、容量最佳配比、全鏈路壓測的流量構(gòu)造提供最好的幫助。進(jìn)而提升用戶體驗(yàn)，促進(jìn)業(yè)務(wù)發(fā)展，最大程度實(shí)現(xiàn)企業(yè)的商業(yè)價值。詳情參見什么是性能測試PTS

割接上線前的準(zhǔn)備

應(yīng)用的割接上線是整個應(yīng)用上云遷移實(shí)施的最關(guān)鍵環(huán)節(jié)，這一環(huán)節(jié)出問題，可能會造成重大故障。針對割接上線的重要性，我們建議在實(shí)施應(yīng)用割接前，制定詳細(xì)的割接前檢查清單,這個清單的嚴(yán)謹(jǐn)程度也許很大程度上決定了割接成功率。根據(jù)我們以往的經(jīng)驗(yàn)，對割接上線前的準(zhǔn)備工作，以下給出幾點(diǎn)經(jīng)驗(yàn)：

• 割接前需要嚴(yán)格確認(rèn)是否所有需要預(yù)先準(zhǔn)備的工具、遷移環(huán)境（客戶本地數(shù)據(jù)中心端、網(wǎng)絡(luò)、云端）等已經(jīng)就緒。

• 檢查和確認(rèn)云環(huán)境Landing Zone已經(jīng)就緒，并且確認(rèn)云環(huán)境中的規(guī)模，安全，控制，網(wǎng)絡(luò)以及身份驗(yàn)證與設(shè)計保持一致。

• 割接上線時需多方人員參與，軟件廠商、集成商、用戶方、云廠商等,確認(rèn)這些相關(guān)人員是否已經(jīng)就緒。支持的方式是現(xiàn)場、遠(yuǎn)程還是電話。

• 回滾預(yù)案是否就緒。割接過程好像在打一場大的戰(zhàn)役，很多的任務(wù)或子任務(wù)會分配半小時內(nèi)計劃執(zhí)行結(jié)束，整個過程可能會非常緊張。為降低壓力，即使因?yàn)槟硞€主客觀原因?qū)е逻w移無法成功進(jìn)行，如果有補(bǔ)救措施會讓整個遷移團(tuán)隊(duì)降低很多壓力。這個補(bǔ)救措施之一就是回滾預(yù)案，也即是失敗后回滾到客戶的原數(shù)據(jù)中心恢復(fù)業(yè)務(wù)應(yīng)用，需要在割接時預(yù)留回滾執(zhí)行的時間?；貪L執(zhí)行后，然后擁有充足的時間排查問題，以備下一個割接窗口期內(nèi)再次割接。

• 根據(jù)項(xiàng)目實(shí)際場景，設(shè)計一個檢查清單，這個清單包含了遷移割接任務(wù)的全部前置條件。下圖給出一個檢查清單的示例模板，在具體的項(xiàng)目中可以根據(jù)項(xiàng)目需求來設(shè)計定制。

制定詳細(xì)的割接實(shí)施方案

遷移項(xiàng)目是復(fù)雜的，大部分遷移割接的時候都會或多或少的遇到一些無法預(yù)料的問題。造成割接失敗，可能有主觀原因和客觀因素。主觀原因可能因?yàn)檫w移調(diào)研問題、遷移方案設(shè)計缺陷、遷移驗(yàn)證過程不夠全面等。客觀因素通常是客戶IDC、運(yùn)營商網(wǎng)絡(luò)、云數(shù)據(jù)中心故障等。無論哪種問題導(dǎo)致，都可能會對遷移割接造成失敗。根據(jù)以往的項(xiàng)目經(jīng)驗(yàn)，我們建議在割接前制定詳細(xì)的割接實(shí)施方案，以下是關(guān)于割接實(shí)施方案的一些建議。

• 數(shù)據(jù)驗(yàn)證，確認(rèn)割接時與割接前數(shù)據(jù)保持一致。通?？蛻舻拇蟛糠址?wù)器鏡像及數(shù)據(jù)會在割接前預(yù)先在云端復(fù)制完成。在割接窗口期開啟后需要確保云端復(fù)制的數(shù)據(jù)與客戶數(shù)據(jù)中心下線前保持嚴(yán)格一致。

• 并非所有問題都會導(dǎo)致遷移失敗。遇到問題的時候，首先評估問題的嚴(yán)重程度，如果不是關(guān)鍵業(yè)務(wù)應(yīng)用的重要的問題，可以將割接流程繼續(xù)進(jìn)行，同時該問題繼續(xù)解決。與客戶協(xié)商，該問題是否會對業(yè)務(wù)有很大影響，如果客戶可以接受的話，可以先上線，然后盡快解決該問題。

• 遷移時間拖延問題處理。如果割接時不夠順利，因?yàn)榉N種主客觀原因?qū)е逻w移割接時間長于計劃時間，可以與客戶協(xié)調(diào)，一起決定是否可以延遲一些時間上線。通常設(shè)計割接計劃時都會留出一些緩沖時間，如果需要延遲的時間過長是客戶無法接受的，那就只能執(zhí)行回滾預(yù)案了。

• 網(wǎng)絡(luò)切換問題處理。比如IP,端口，網(wǎng)絡(luò)配置,DNS等問題，在之前的調(diào)研和檢查中出現(xiàn)遺漏。這種問題在割接時經(jīng)常會遇到，出現(xiàn)這種問題緊急聯(lián)系相關(guān)負(fù)責(zé)方盡快解決，但并不一定會影響割接整體進(jìn)行。

• 遷移的不僅是服務(wù)器或數(shù)據(jù)。而是整個企業(yè)的IT應(yīng)用及環(huán)境，客戶應(yīng)用需要的身份管理、安全配置、數(shù)據(jù)及系統(tǒng)備份、高可用性架構(gòu)配置，容災(zāi)方案等都需要完成。

• 嚴(yán)格按照遷移設(shè)計方案中指定的云服務(wù)型號匹配云上資源。拿VM舉例，通常云上會提供十幾個系列，數(shù)百種VM型號，使用錯誤的VM即使能夠?qū)⒎?wù)啟動起來，但會帶來性能、功能以及成本的問題。

• 遷移過程確保安全合規(guī)。數(shù)據(jù)遷移嚴(yán)格使用加密數(shù)據(jù)傳輸，加密數(shù)據(jù)存儲。證書、密碼、權(quán)限按照合規(guī)的方式申請和使用，杜絕泄露隱患。避免因安全合規(guī)性問題帶給客戶嚴(yán)重?fù)p失。

• 制定詳細(xì)的割接及回滾步驟，明確每個步驟執(zhí)行時間點(diǎn)，前置條件，相關(guān)責(zé)任人等。以下是割接及回滾步驟的示例模板，在具體的項(xiàng)目中可以根據(jù)項(xiàng)目需求來設(shè)計定制。

割接實(shí)施步驟模板示例：

回滾實(shí)施步驟模板示例：

割接后持續(xù)觀察驗(yàn)證

割接后對遷移的應(yīng)用云上運(yùn)行情況持續(xù)觀察驗(yàn)證，做好業(yè)務(wù)和數(shù)據(jù)做好監(jiān)控，持續(xù)觀察業(yè)務(wù)的運(yùn)行狀態(tài)，直到確認(rèn)完全沒有問題，割接執(zhí)行工作才算基本結(jié)束。

關(guān)注【TechLeadCloud】，分享互聯(lián)網(wǎng)架構(gòu)、云服務(wù)技術(shù)的全維度知識。作者擁有10+年互聯(lián)網(wǎng)服務(wù)架構(gòu)、AI產(chǎn)品研發(fā)經(jīng)驗(yàn)、團(tuán)隊(duì)管理經(jīng)驗(yàn)，同濟(jì)本復(fù)旦碩，復(fù)旦機(jī)器人智能實(shí)驗(yàn)室成員，阿里云認(rèn)證的資深架構(gòu)師，項(xiàng)目管理專業(yè)人士，上億營收AI產(chǎn)品研發(fā)負(fù)責(zé)人。
如有幫助，請多關(guān)注
TeahLead KrisChang，10+年的互聯(lián)網(wǎng)和人工智能從業(yè)經(jīng)驗(yàn)，10年+技術(shù)和業(yè)務(wù)團(tuán)隊(duì)管理經(jīng)驗(yàn)，同濟(jì)軟件工程本科，復(fù)旦工程管理碩士，阿里云認(rèn)證云服務(wù)資深架構(gòu)師，上億營收AI產(chǎn)品業(yè)務(wù)負(fù)責(zé)人。文章來源地址http://www.zghlxwxcb.cn/news/detail-837603.html

到了這里，關(guān)于云計算 - 以阿里云為例，企業(yè)上云策略全覽與最佳實(shí)踐的文章就介紹完了。如果您還想了解更多內(nèi)容，請?jiān)谟疑辖撬阉鱐OY模板網(wǎng)以前的文章或繼續(xù)瀏覽下面的相關(guān)文章，希望大家以后多多支持TOY模板網(wǎng)！