雲計算 - 以阿里云爲例，企業上雲策略全覽與最佳實踐

雲採用框架（Cloud Adoption Framework，簡稱CAF）爲企業上雲提供策略和技術的指導原則和最佳實踐，幫助企業上好雲、用好雲、管好雲，併成功實現業務目標。本雲採用框架是基於服務大量企業客戶的經驗總結，將企業雲採用分爲四個階段，並詳細探討企業應在每個階段採取的業務和技術策略；同時，還提供了一系列最佳實踐、文檔和輔助工具，幫助雲架構師、雲管理團隊等干係人能夠實現組織協同達成目標。

關注【TechLeadCloud】，分享互聯網架構、雲服務技術的全維度知識。作者擁有10+年互聯網服務架構、AI產品研發經驗、團隊管理經驗，同濟本復旦碩，復旦機器人智能實驗室成員，阿里雲認證的資深架構師，項目管理專業人士，上億營收AI產品研發負責人。

一、什麼是雲採用框架CAF

雲採用框架（Cloud Adoption Framework，簡稱CAF）爲企業上雲提供策略和技術的指導原則和最佳實踐，幫助企業上好雲、用好雲、管好雲，併成功實現業務目標。

本雲採用框架是基於服務大量企業客戶的經驗總結，將企業雲採用分爲四個階段：上雲戰略、上雲準備、應用上雲和運營治理，並詳細探討企業應在每個階段採取的業務和技術策略；同時，還提供了一系列最佳實踐、文檔和輔助工具，幫助雲架構師、雲管理團隊等干係人能夠實現組織協同達成目標。

ITIL（Information Technology Infrastructure Library） 是IT服務管理的經典方法論，被企業廣泛採用。ITIL中核心的概念是IT服務，IT服務是用來支持企業業務發展的技術服務，它的全生命週期包含服務戰略、服務設計、服務轉換、服務運營以及服務的持續改進五個階段，其中

• 服務戰略階段：定義服務、明確服務的價值以及服務管理與業務之間的關係。
• 服務設計階段：定義服務的目標和要素、模型和風險，定義管理服務的流程。
• 服務轉換階段：提供發展和改進能力將服務交付到運營階段。
• 服務運營階段：在服務交付和支持中保證效率和效果，爲客戶提供價值。

雲服務是當下最流行的IT服務之一，雲服務的採用應遵循上述生命週期。我們的雲採用框架就是以這樣的理論體系爲指導，定義了企業引入雲服務的四個階段：

• 在上雲戰略階段，領導層需要思考上雲能爲業務帶來什麼價值，並在公司層面確定相應的戰略。
• 在上雲準備階段，IT團隊需要制定雲採用的頂層設計，確保組織協同和可管可控。
• 在應用上雲階段，開始遷移原有的系統上雲或者在雲上開展新的業務。
• 在運營治理階段，企業不斷髮現和解決運營過程中的問題和風險，提升服務質量。

---

二、企業上雲的主要動機

我們可以根據上雲的業務對上雲動機進行分類。如果上雲的業務是一個在雲下已經存在的業務，那麼上雲主要是把雲下的應用遷移到雲上，這稱爲業務遷移上雲。如果上雲的業務是一個新構建的業務，首次部署運行就在雲上，這稱爲業務創新上雲。

業務遷移上雲

業務遷移上雲是最爲常見的一類上雲動機，也是雲計算技術商業化後最早期的企業普遍採用的上雲方式。業務遷移上雲的主要目的是：

• 加速資源的交付效率，提高對業務需求的反應速度。

  傳統IDC採購週期從一個月到幾個月不等。如果涉及到出海，對於企業來說IDC的規劃甚至長達數年。而云上資源的交付效率近乎實時。

• 降低成本。

  雲計算將IT資產的成本由傳統的Capex資產折舊模型轉變爲Opex的按量付費模型。這樣做一方面減少企業的一次性IT投入，另一方面也可以讓企業按時按量購買需要的資源，以節省成本。

• 使用雲提供的最新技術。

  雲廠商通常在產品技術的投入非常大。因此，雲廠商提供的雲服務通常在行業中比較領先，例如我們常說的雲原生服務，如容器、中間件。

• 提高服務的安全性。

  雲廠商提供的是規模化在線服務。在安全性方面，雲廠商有大量的數據能夠幫助客戶更好的應對互聯網上的攻擊。

業務創新上雲

隨着數字化轉型的浪潮，當前許多企業開始業務創新。雲上提供了較爲豐富的PaaS和SaaS服務，因此雲也是這部分轉型的最佳選擇。業務創新上雲的主要目的是：

• 雲上提供豐富的創新能力，例如IoT、大數據、業務中臺，能夠大幅降低企業業務創新的門檻。
• 需要將業務快速推向新的市場。

---

三、上雲所需的企業組織模型

企業上雲和用雲的整個生命週期，需要專業團隊進行合理的規劃、實施以及持續優化雲採用方案，推進企業更好的利用上雲的優勢促進業務發展。企業通常至少有一個雲管理團隊，或由相關負責人組建一個雲卓越中心（Cloud Center of Excellence，簡稱CCoE）負責規劃和對接上雲的整體方案，包括在公司層面確認上雲的整體計劃、步驟，以及收集業務團隊的具體需求。

上雲所需的企業組織模型

首先，我們看一下一個典型的企業組織架構。爲了便於理解，我們對這個組織結構進行了適當的簡化。在這個架構中，不同的團隊對公司的整體目標進行拆解，例如業務團隊主要貢獻公司的營收、流入目標，財務、法務等團隊對公司的整體運營風險進行控制，產品技術團隊則爲業務團隊提供技術支撐。

核心職責

企業採用雲服務的過程中有以下核心工作項：

• 上雲策略：從公司戰略層面確定企業上雲的動機和期望的業務結果。在充分論證企業上雲的收益和風險後，最重要的是在公司上下充分傳達和教育，確保公司高層、業務、研發、運維、財務、人力資源等各個相關團隊統一認識，明確上雲戰略，各團隊能夠配合做出相應的計劃和調整。制定企業上雲計劃，包括業務範圍、上雲的計劃節奏、各階段目標以及最終結果。協調各部門準備相應的預算、調配人員和組建必要的團隊。

• 上雲準備：準備上雲的基礎環境，對雲服務進行學習和測試，選擇小規模的業務進行遷移驗證。設計業務上雲的整體架構，其中包括遷移方案和基於雲技術的創新。規劃業務上雲的流程，協調業務部門配合實施業務上雲。分階段逐步實施業務遷移上雲，並在過程中調整方案，確保業務連續性和穩定性。

• 應用上雲：梳理企業應用系統清單，調研應用上雲兼容性等相關特徵，篩選需要上雲的應用，制定應用的上雲策略。

• 持續治理：充分預見和評估企業安全合規等風險，規劃企業IT治理的整體方案、策略和基本規則，包括資源結構、身份權限、費用賬單、合規審計、網絡架構、安全策略以及監控規則等。在企業上雲和用雲過程中，通過治理規則預防、發現和及時治理風險。

爲了適應雲採用框架，組織需要進行以下準備：

• 企業管理層：企業管理層需要明確雲在公司的戰略地位以及各個團隊應該如何使用雲。

• 雲卓越中心：該團隊可以是虛擬的組織，設計提供雲服務的模式和管理體系，並提供相應的技術準備。其中的成員包括

  • 架構師和專業技術人員，負責上雲架構設計和業務上雲遷移工作；

  • 安全、合規等領域專家，負責設計企業IT治理方案、預估風險和制定治理規則；

  • 財務專家，負責制定財務的管理流程，成本分攤原則。

• 雲管理團隊：在企業業務全面上雲之後，持續優化上雲架構，爲新業務提供雲上環境。建立企業雲上運維體系，搭建運維平臺，以及通過自動化運維的方式，對雲上環境進行持續治理和管理。根據新業務需求，分配所需雲資源和所需權限，並對資源進行初始化配置後交付。應用運維團隊只需用雲，無需關注基礎設施搭建。綜上，平臺運維工作也可細分爲架構優化、雲平臺建設、資產管理、權限管理、雲自動化等多種職責。

---

四、雲上管理和治理框架

定義

如果把上雲框架的搭建比作建設社區，那麼企業的中心IT團隊就是社區的總設計師。一個好的社區通常具備較爲完善的頂層設計，最終才能提供優質服務給社區租戶。社區規劃首先要考慮的是基礎設施的佈局和建設，包括道路的規劃、門禁的管理、停車場的佈局、樓房規格的規劃等。其次，社區一般也會提供通用服務，例如垃圾分類、水電維修等，以及制定相應的社區規約來管理租戶，例如裝修時間規定、噪音規定。作爲增值服務，高檔社區還會提供統一的不同類型的樣板間，比如統一水電、裝修等。

在阿里雲，我們建議企業在第一個應用上雲前，需要有一整套頂層設計和一系列基礎框架，爲後續的業務上雲掃清障礙。否則，可能會導致後續業務上雲面臨成本、網絡、安全、效率等多方面的問題。業界通常把這些基礎框架叫做Landing Zone，我們也遵循這一命名方法。

如上所述，在成熟的運維模型中，通常由企業的中心IT團隊負責集中管理和管控，然後將雲環境交付到業務團隊。爲了高效地提供安全、穩定的雲環境，中心IT團隊需要搭建一套企業級的管理和治理框架作爲雲環境的基礎設施，爲企業上雲打好基礎。

例如，某跨國企業使用阿里雲支撐公司多個業務系統，其中包含公司的互聯網業務和ERP，以及內部的OA等系統，這些系統由不同的團隊負責。爲了更高效地使用雲，公司成立新的“雲平臺”部門負責和雲的對接。“雲平臺”的內部定位是公司負責提供雲能力的部門，以此加速IT和業務升級。具體而言，“雲平臺”部門負責雲上資源的快速交付、成本控制、質量保證，同時賦能業務部門在安全的前提下進行創新。“雲平臺”在阿里雲提供的Landing Zone的基礎上，構建了整個雲服務體系。

架構

那麼，一個完整的Landing Zone，究竟包括哪些方面？在參考了衆多企業客戶的實踐之後，我們定義了Landing Zone，其包含如下幾個功能模塊。

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

Landing Zone模塊	描述
資源規劃	規劃雲上賬號及其組織結構。根據公司的運維模式，定義所需要的管控關係。
財務管理	管理雲平臺的合同、優惠、付款關係、賬單，以及認證公司在雲平臺的實體、發票擡頭等財務相關的屬性。
網絡規劃	規劃雲上VPC的拓撲結構、混合雲網絡的互聯、網絡的流量走向、相關的安全措施，以及如何構建高可用和可擴展的網絡架構。
身份權限	規劃誰能夠訪問雲，並通過單點登錄SSO和細粒度授權實現人員按需訪問。
安全防護	通過在雲上構建基礎的安全環境，幫助業務系統在雲上快速的安全落地。
合規審計	設計治理的目標和流程，並通過相應的工具來實現對於治理規則的監督。
運維管理	構建以CMDB爲核心的運維管理體系，包含標準的發佈變更流程，應用和基礎設施的統一監控，集成企業的ITSM系統，提供自助服務。
自動化	定義自動化場景和目標，並通過相應的工具實現自動化。常見的場景如Landing Zone自身的搭建以及CI/CD流水線的自動化。

---

五、企業應用上雲規劃

隨着企業信息系統的持續建設，IT與業務不斷的融合，企業應用類型及模板不斷髮展，如何從大量企業應用系統中篩選需要上雲的應用，確定應用上雲的策略及優先級，是上雲實施前需要做的事情。所以，建議企業在上雲遷移實施前，對企業總體應用進行上雲規劃。以企業上雲戰略及規劃爲指導方向，梳理企業應用系統清單，調研應用上雲兼容性等相關特徵，制定應用的上雲策略，以及應用上雲遷移優先級。阿里雲上雲評估模型如下圖所示。

上雲兼容相關特徵

上雲兼容特性主要包含基礎設施相關兼容性以及應用架構兼容性特徵；

基礎設施兼容性特徵

• 硬件依賴性

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

• 性能要求

  • 是否有特殊性能要求，比如運行環境CPU、內存規格，IO或網絡要求等，雲上是否能滿足；

• 操作系統要求

  • 是否有特殊版本操作系統要求，雲上是否能提供；

應用架構兼容性特徵

• 集中式/分佈式架構

  • 應用是否分佈式架構，以及使用的分佈式架構框架，是否有對應的PAAS產品支持兼容

• 源代碼可控性

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

• 技術組件上雲兼容性

  • 包含數據庫、存儲、中間件等技術組件，是否有對應兼容的雲產品；

其他特徵

• 業務/技術痛點或訴求

  • 是否有業務或技術上的痛點或訴求，比如當前集中式架構迭代速度無法支持業務快速發展，需要做微服務改造；

• 資源/數據增長需求

  • 當前基礎設施環境，是否滿足業務預期的資源或數據增長需求，以及數據增長要求對架構提供優化需求，比如數據庫容量無法滿足業務未來數據增量，在上雲同時，需要做水平拆分；

• 安全合規要求

  • 是否有行業特徵的安全合規要求，雲的安全合規等級是否滿足行業要求；

• 容災要求

  • 是否容災或數據災備要求，雲產品能力是否支持；

上雲策略

上雲規劃階段，需要確認應用的上雲策略，是否平遷或改造上雲，根據阿里雲的以往項目實踐，我們建議的上雲策略包含以下幾點。

保持現狀

保留應用程序在當前的IT環境，作爲非雲基礎設施的一部分；

平遷上雲

應用比較容易移植到雲環境上，使用雲產品可替兼容替換技術組件，少量修改應用配置後重新部署到新的雲平臺。

優化上雲

通過使用雲上PaaS產品及服務，對應用進行局部優化，提升性能或穩定性。

重構上雲

應用組件不適配雲的架構，或者不符合成本效益，因此需要對應用進行重構，基於新的雲平臺構建雲原生架構的應用。

決策流程

根據業務調研階段輸出的應用系統清單及應用特徵數據，每個應用最終對應上雲評估策略的中一個類別。其決策流程可以參考下圖。

考慮到企業應用系統規模較大，各方面資源無法保障所有應用系統並行上雲。所以，我們建議制定應用上雲優先級，並明確遷移批次及計劃，使得所有資源能夠有效被利用，並降低上雲風險。

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

應用上雲批次確認後，根據企業上雲戰略及規劃，制定企業應用上雲總體實施計劃，示例如下圖所示。

---

六、企業應用上雲實施流程

阿里雲基於業界最佳實踐和大量上雲項目的經驗累積，總結出以下遷雲流程，這一過程建立在完成了企業應用上雲規劃後，以應用爲單位進行進一步的遷移計劃和實施。

在上雲實施階段，應用調研的目標，是爲了解應用的應用架構以及使用的技術組件，以制定雲上目標詳細方案，包含雲上應用架構設計，產品選型及容量評估、遷移方案以及割接方案，所以這一階段調研的信息比較詳細。

應用架構及依賴

• 應用架構

  • 應用模塊及模塊間關係，節點配置及數量；應用開發語言及框架。

• 應用依賴

  • 其他應用間的依賴關係，以及外部依賴，主要用於割接方案參考；

技術組件

• 數據庫

  • 數據庫類型，版本，數據量，性能要求等；

• 中間件

  • 中間件類型，版本，集羣規模及容量【可選】，如消息隊列、緩存等；

• 存儲

  • 使用存儲設備的接口協議，及數據量；

應用性能基線

• 應用的性能指標要求，用於測試驗證階段性能測試目標參考；

調研工具

如果企業系統非常龐大，應用之間耦合多，各系統的負責部門不同，人工收集的方式難免會有疏漏，難以完整釐清所有應用系統以及系統間的複雜依賴關係。我們建議使用阿里雲提供針對企業應用上雲場景提供應用發現服務（Application Discovery Service），滿足企業在遷雲階段的評估、規劃、建設、遷移的需求評估。採用無侵入式採集技術，不影響在線業務的性能前提下從主機和進程兩個維度構建架構拓撲，自動分析識別主機和進程信息、資源使用水位以及各應用和組件之間的依賴關係。更多詳情，請參見應用發現服務。

平遷上雲方案

產品選型策略

針對傳統應用平遷上雲場景，常見產品對標選型策略如下圖所示。

場景示例1：單體應用遷移

雲上重部署應用

針對平遷方式的應用上雲場景，對於已有成熟CI/CD工具及流程的企業，我們建議優先使用現有CI/CD工具，在雲上重新部署應用。

對於還沒有構建CI/CD能力的企業，我們建議先使用雲上DevOps產品構建企業的CI/CD自動化平臺，通過CI/CD流水線，在雲上重新部署應用。基於阿里云云效產品構建CI/CD流水線如下圖所示。

鏡像遷移

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

場景示例2：微服務應用遷移

對於微服務應用上雲，可以使用阿里雲企業級分佈式應用服務EDAS（Enterprise Distributed Application Service），它是一個應用託管和微服務管理的PaaS平臺，提供應用開發、部署、監控、運維等全棧式解決方案，支持SpringCloud、Dubbo等微服務運行環境。

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

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

切流遷移

使用Dubbo將原有的服務註冊中心切換到微服務引擎（Micro Service Engine，簡稱MSE），在雲上部署一套新的應用，最後通過SLB和域名配置來進行切流。

雙註冊和雙訂閱遷移

• 在應用遷移時同時接入兩個註冊中心（原有註冊中心和EDAS註冊中心），保證已遷移的應用和未遷移的應用之間能夠相互調用。通過雙註冊和雙訂閱遷移應用的架構圖如下。

• 支持在不重啓應用的情況下，動態地變更服務註冊的策略和服務訂閱的策略，只需要重啓一次應用就可以完成遷移。

• 已遷移的應用和未遷移的應用可以互相發現，從而實現互相調用，保證了業務的連續性。

• 使用方式簡單，只需要添加依賴，並修改一行代碼，就可以實現雙註冊和雙訂閱。

• 支持查看消費者服務調用列表詳情，實時地查看遷移進度。

• 更多詳細信息，請參見產品最佳實踐平滑遷移微服務應用至EDAS

優化上雲方案

場景示例：應用容器化上雲

以Kubernetes爲代表的容器技術正成爲雲計算新界面。容器提供了應用分發和交付標準，將應用與底層運行環境進行解耦。Kubernetes 作爲資源調度和編排的標準，屏蔽底層架構差異性，幫助應用平滑運行在不同基礎設施上。

應用容器化規範化改造

容器化的應用必須要規範化，我們不希望所完成的容器鏡像只能在生產環境中運行，也不希望該容器有着外部依賴，我們希望應用在容器化之前，最少滿足這三項要求：

• 與操作系統解耦，能在各種系統中運行並有極大的可移植性

• 適合部署在現代的雲平臺上，配置與代碼分離

• 開發與生產環境對等，能夠使用現代的包管理工具實施封裝打包

所以，對應用進行容器化前，必須對應用進行檢查並實施類似的改造，也就是進行應用規範化，規範化的過程根據已有應用的實際情況有較大的不同，一般來說，越是現代的、面向互聯網的應用越容易容器化。對容器化應用的規範化改造有以下內容：

• ·準代碼：明確一份代碼，多分部署的原則，一個應用程序只能有且只有一個代碼庫或一個主庫，確保該代碼庫中能夠支持開發、測試、構建操作。

• 依賴管理：大多數編程語言都會提供一個打包系統，用來爲各個類庫提供打包服務，我們期望應用程序能夠顯式的表示自己的依賴，使用pom.xml或者package.json來描述自己的全部依賴，不要有隱式依賴。這樣能夠爲開發者和流水線簡化配置流程，可以完成一句話構建。

• 配置注入：數據庫地址、三方證書、API Key等等這些在不同環境下有區別的配置應該能夠獨立注入，我們要求在不同環境下，容器一致，但配置不同。可以使用環境變量或 Config Service 方式進行管理，使用Config Service時也需要做到無依賴。

• 服務配置化：後端依賴的服務比如數據庫MySQL、PostgreSQL、緩存、隊列等都需要做到可配置化，將配置拿出，系統不應該區別對待這些服務。

• 進程整理：應用程序儘量做到一個進程運行，如果使用多個進程比如Nginx + PHP也可以接受，但一定要目的單一，易於管理。同時也需要保證進程的無狀態特性，使用內存存儲 session 造成粘性是無法接受的，並且狀態應該持久化入數據庫。單一的、無狀態的進程也可以反映到併發上。

• 易處理：表示可以瞬間開啓或停止，這有利於快速、彈性的伸縮應用，迅速部署變化的代碼或配置 ，穩健的部署應用。當然也需要支持優雅的終止，即受到SIGTERM後會處理完任務，或者在服務中心註銷，再進行關閉。

容器化上雲流程

傳統應用容器化大致分爲五個階段：

• 應用現狀分析：梳理應用使用的資源、系統的邏輯架構拓樸、應用服務的所有數據依賴、應用上下游服務依賴關係、服務所依賴的進程、系統中需要保留的重要日誌及數據、數據和文件權限等；

• 方案規劃和設計：根據前期對應用系統現狀的調研和分析結合容器平臺特性，應用系統產出新的系統架構圖和遷移的改造計劃，比如是直接容器化上雲還是改造後再容器化上雲，以及容器化後業務系統功能和性能測試方案、系統的割接方案等。

• 編寫Dockerfile：若要打包應用程序以供在Docker中運行，需要編寫腳本文件Dockerfile，用於自動執行所有應用程序部署時需要執行的步驟。這通常包括一些Shell配置命令，以及用於複製應用程序包、設置所有依賴項的指令，也可以解壓縮已壓縮的存檔或安裝包。Docker鏡像是一個特殊的文件系統，除了提供容器運行時所需的程序、庫、資源、配置等文件外，還包含了一些爲運行時準備的一些配置參數（如匿名卷、環境變量、用戶等）。在Docker鏡像使用中，我們最好把經常變化的內容和基本不會變化的內容要分開，把不怎麼變化的內容放在下層，創建一個基礎鏡像供上層使用。

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

• 應用部署：將docker鏡像部署到對應Kubernetes集羣應用。在Kubernetes集羣上需要用到的部署模板，在具體實施過程中，可以根據不同的模板來部署到對應不同的集羣。

重構上雲方案

傳統單體應用架構問題

• 單體應用複雜度高，應用迭代發佈週期慢，無法支撐業務快速發展的需求。

• 開發者需要關注架構的所有細節（限流、熔斷、降級等服務治理，數據訪問及消息通信）。

• 運維需要負責底層基礎設施（包括數據庫、緩存、虛擬機等）的穩定性。

雲原生應用架構

雲原生應用架構特點

• 應用代碼按業務域拆分解耦，降低複雜度。

• 開發者只需關注業務邏輯，與業務不相關功能下沉到雲基礎設施。

• 技術體系走向開放和標準。

• 運維無需關注基礎設施穩定性，更多精力專注於自動化。

雲原生應用架構建議

雲原生應用架構示例，如下圖所示。

• 微服務解決“應用架構複雜度”問題。

• 服務治理解決“業務開發關注與業務無關的限流、熔斷、降級能力”。

• 容器解決應用“部署問題”問題。

• Kubernetes解決應用“編排和調度”問題。

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

場景示例：應用微服務化重構上雲

對於複雜應用系統來說，單體應用架構代碼複雜度高、可擴展性差、業務開發及部署週期慢，不能滿足現業務發展需要。對於業務複雜的單體應用系統上雲需求，我們建議以微服務化重構改造上雲。

核心問題

• 服務拆分

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

• 跨服務查詢

  單體應用裏實現查詢相對簡單，因爲具有統一的數據庫。但在微服務架構下，一個查詢可能需要檢索分佈在不同的服務中數據，而這些服務都會擁有自己的數據庫。傳統的分佈式數據查詢機制不適用，因爲會打破服務之間的數據隔離性，該隔離性要求以服務的形式提供數據，不能直接暴露數據庫。

改造原則

• 漸進式，不要“推倒重來，一步到位”

  • 快速見效、快速收到回報、可挑選出高價值的模塊先進行服務化改造，更早的拿到結果來獲得業務團隊的支持。

• 減少對單體應用的改動

  • 單體應用的修改是不可避免的，重要的是要減少改動同時保持數據一致性。

• 改造主要從業務維度入手，少量的技術維度。

• 拆分時做“垂直切片”

  • 含業務邏輯、庫表結構等前後端邏輯。

改造策略

（1）新業務構建爲服務

將新的業務或功能以服務的形式進行構建，這不僅會阻止單體擴大和繼續發展，快速開發出新業務功能，更體現出微服務架構的價值。常見的辦法是對新業務進行領域建模，得到領域模型、服務接口等必要元素。但同時會帶來問題，即新舊系統結合，即微服務與單體應用怎麼協作。

• 問題識別

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

• 解決方案

  • 雙向代理層

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

  • • 舊系統側的集成對接：採用外觀（Facade）模式，屏蔽舊系統內部細節，簡化新系統對接的複雜度。

    • 舊系統側的協議適配：採用Adapter模式，向新系統提供所需的服務實體，負責請求和應答的協議適配。

    • 領域模型轉換器：負責請求和應答中新舊系統領域模型的轉換，新舊系統都需要。

  • 領域事件

  單體與微服務之間的數據交互，使用API是較爲直接的方式。但當一方數據變化後，API方式無法主動進行通知。因此，另一個方式是基於領域事件的數據同步。比如：單體應用發佈領域事件，微服務進行訂閱。當單體數據產生變化時，可以通過領域事件的方式通知微服務，微服務獲取事件，更新本地數據，供本地業務查詢使用。

（2）業務功能提取爲微服務

• 挑戰：對單體應用做拆分時，採取的策略是自上而下的“垂直切分”，要涵蓋被拆分的業務的全部邏輯，主要包含業務邏輯及數據庫表。爲此帶來了一些挑戰：

  • 領域模型的拆分：跨服務的對象引用、通用類的拆分等

  • 數據庫表的拆解分，如：從已有的表中拆出新表

• 提取入口：關於提取哪些部分進行服務化，一個重要判斷點是否能給業務快速帶來價值，而價值可以從新業務上線效率，或解決棘手的性能及擴展性等方面來考慮。一般來說，具有下面特點的功能模塊可以入手來做改造，提取功能爲服務後，同時也需要重構數據庫。如：改造數據庫的庫表結構，提取並創建新服務對應的表及數據。

  • 頻繁變化（業務維度）

  • 頻繁調用

  • 相對獨立

  • 共享的基礎數據

  • 計算密集型（利於彈性伸縮，技術維度）

• 最小化改造：對單體應用進行改造，勢必會帶來領域模型、庫表結構等的變化。例如：我們拆分訂單業務，提取出送貨子業務。這些變化會直接影響代碼，即要求對變化的部分做出代碼調整。由於每一處訪問變化部分的代碼都需要，這會直接修改單體應用的代碼，可能帶來較大工作量，這是我們不願意看到的，因爲大量工作花費在要被替代的單體應用上。理想的方式是，在拆分出新服務的同時，不修改或儘量減少修改原有單體應用。

  • 保持單體應用的數據庫結構基本不變；

  • 拆分出的新服務使用獨立的新庫表結構；

  • 新服務獲取數據後寫入新的庫表；

  • 使用觸發器之類機制將新庫表的數據同步到單體應用庫表；

  • 在單體應用裏，只需修改代碼去調用新服務即可；數據讀取可依賴原有單體應用。

專項上雲方案

數據上雲方案

數據上雲架構設計

數據在同一業務庫中採用多租戶隔離機制；爲數據服務層建立一套統一的管理規範，所有業務用戶賬號在完成相關審批流程後對相應的數據字段進行授權安全訪問，對數據只有讀的權限，不能對原始數據進行直接修改或刪除，做到數據不搬家，可用不可見；建立統一的數據資源視圖和數據血緣跟蹤能力，能夠對所有的數據的生命週期進行溯源查詢，用以甄別數據變更過程中的真實性和準確性；根據不同業務場景結合流程節點和風險管控要求，對相關數據進行分析、建模、挖掘，提高數據服務支持。

數據上雲安全防護

在企業數據遷移上雲的過程中,實施數據分層保護功能已成爲一個關鍵優先事項。同時，數據保護控制必須輔之以強大的監控工具和訪問管理控制,以構建數據的整體視圖，對數據的全生命週期進行監控。重點考慮以下關鍵數據保護領域。

• 數據分類：圍繞數據識別、清單、標籤和分類的功能和流程；

• 靜態數據保護：有關加密/令牌化的解決方案和注意事項,包括密鑰管理；

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

• 數據監控：通過操作中心 (SOC) 進行日誌記錄和監視功能；

• 在雲環境中,以數據爲中心的保護需要在整個數據生命週期中進行。

阿里雲數據上雲遷移最佳實踐

數據庫上雲

包含關係數據庫及NoSQL數據庫上雲等場景，以Mysql爲例，主要考慮以下幾點：

• 根據性能場景需求，選擇匹配的產品及實例規格，以最低成本達到業務需求

  比如RDS和PolarDB，RDS主要是主備模式，讀寫IO在單機上執行，走主機總線，RT相對較低，而PolarDB是雲原生的讀寫分離架構，讀寫IO會走網絡，RT相對較高。從產品架構上分析，對於RT要求比較高的場景，建議使用RDS，其他情況，相同規格PolarDB實例一般比RDS QPS性能要高。

• 未來數據增長

  未來三年內數據增長，如果超過單實例最高規格性能，建議PolarDB-X，通過水平切分的方式，將數據分佈在多個底層mysql庫，通過並行的分佈式數據庫操作來實現性能的提升。

• 遷移過程數據膨脹

  全量數據遷移過程併發INSERT導致目標實例的表存在碎片，全量遷移完成後目標實例的表空間會比源實例大（遷移完成後可通過optimize table合併碎片，優化存儲空間），所以建議選擇實例規格時，預留一定的存儲空間以防存儲打滿；

• 識別無主鍵表

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

阿里雲數據庫上雲遷移工具及最佳實踐

數據傳輸（Data Transmission，簡稱DTS）是阿里雲提供的一種支持關係型數據庫、 NoSQL、OLAP等多種數據源之間數據交互的數據服務。DTS的數據遷移功能支持同構或異構數據源之間的數據遷移，同時提供了庫表列三級映射、數據過濾等多種ETL特性，適用於多種數據庫遷移上雲場景。

存儲數據上雲

主要指非結構化數據，常見於內容管理類型的應用系統，涉及大量文件對象的存儲和管理，傳統的解決方案包括：

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

• 採用IP-SAN、NAS等對數據做集中存儲，這種方案成本較高；

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

針對文件對象存儲，阿里雲提供開放存儲服務（OSS），具備高可用、高擴展、高效性、低成本等特點，能有效解決內容管理類型應用的文件對象的存儲問題。 應用系統需要基於OSS進行相關改造，主要包括：

• 根據應用系統文件的存儲結構在OSS中規劃Bucket，以及文件目錄結構；

• 設置Bucket訪問權限（public-read-write/public-read/private），對於安全級別要求高的應用，可設置文件在OSS上以密文形式存儲；

• 對程序代碼進行掃描，查找出涉及文件向存儲讀寫的代碼，將這些代碼改造爲以OSS SDK接口的實現。

阿里雲存儲數據上雲遷移工具

阿里雲在線遷移服務是阿里雲提供的存儲產品數據通道。使用在線遷移服務，可以將第三方數據輕鬆遷移至阿里雲對象存儲OSS，詳情請參見在線遷移服務。

建立上雲遷移組織及保障機制

在上雲遷移實施前，需要建立遷移組織及保障機制，明確各小組職責及成員，確定保障機制把握項目工作進度和工作質量。

遷移組織架構

根據阿里雲以往項目經驗，建議組織分爲以下小組，如下圖所示，各小組職責如下。

• 項目管理辦公室

  • 負責項目進度、風險及問題管理，以及內部宣貫。

• 實施架構組

  • 負責總組上雲方案、割接方案設計，以及項目實施過程中技術風險把控。

• 應用開發組

  • 負責應用開發、部署及應用遷移實施工作；

• 運維組

  • 負責雲上資源管理、數據組、中間件遷移實施及數據校驗工作；

• 測試組

  • 負責功能測試、聯調測試及性能測試工作。

項目實施保障機制

建立項目管控機制，把握工作進度和工作質量，包含以下內容：

• 內部定期溝通計劃

• 項目週報制度

• 問題和風險分析計劃

制定遷移實施計劃

由於上雲遷移實施存在風險，所以，在應用上雲實施執行前，我們建議制定詳細的實施計劃。這個計劃表裏麪包含了上雲遷移及割接過程的全部任務、時間段、各方人員等。項目實施過程按照這個計劃表跟蹤執行即可。下圖給出一個示例模板，在具體的項目中可以根據項目需求來設計定製。

功能測試及聯調測試

在應用上雲割接前，需要進行充分的功能測試與聯調測試，驗證雲上環境應用運行情況。功能測試及聯調測試依賴企業自己的測試團隊及流程工作，不作過多描述，僅在此建議，對應用功能點進行分級，優先測試驗證核心功能點，對不同級別功能點測試問題，制定不同緊急程度的問題跟蹤。

性能測試

性能測試方案

性能測試流程

業務測試模型構建

業務測試模型構建主要是根據蒐集到的性能測試需求和生產系統的相關信息完成性能模型的構建工作，並指導性能測試過程以及測試結果的生成。

監控性能指標

監控指標包含業務監控指標、操作系統監控指標、中間件監控指標、數據庫監控指標，旨在監控從各個維度描述壓測時性能表現。

構建性能測試數據

測試數據主要包含兩類：

• 基礎測試數據

  基礎測試數據一般取自生產環境真實請求日誌。基礎測試數據非常適合真實業務模型，當然，也可以對基礎測試數據進行過濾處理，獲取單一業務場景測試數據。

• 採用參數化測試數據

  參數化測試數據主要根據業務請求參數，按測試模型場景構建。參數化測試涉及的範圍很多，比如需要準備大量用戶名及相應密碼參數數據；模擬納稅人納稅申報，需要準備大量的納稅人識別號、納稅人內碼或納稅人系統內部識別號等參數數據，這類數據準備要求符合實際運行要求並且保證數據表之間的關聯關係。

測試場景

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

• 基準測試

  • 基準測試的目的是檢查業務本身是否存在性能缺陷。同時爲將來的混合場景的性能測試性能分析提供參考依據。

• 穩定性測試

  • 穩定性測試主要側重系統在持續的壓力情況下，長期運行時的業務處理能力及系統可能存在的缺陷。

• 業務突變測試

  • 業務突變測試主要考察當業務進行突變以後，系統是否出現異常情況，資源在突變前後變化情況。

• 可靠性測試

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

測試實施及報告

基於測試工具，構建對應測試場景的腳本，執行後，通過測試結果，並根據觀測的性能指標，撰寫測試報告；

測試工具

阿里雲性能測試PTS（PerformanceTesting Service）產品是面向所有技術背景人員的雲化測試工具。PTS是具備強大的分佈式壓測能力的 SaaS 壓測平臺，可模擬海量用戶的真實業務場景，全方位驗證業務站點的性能、容量和穩定性。

PTS 目標是將性能壓測本身的工作持續簡化，使您可以將更多的精力迴歸到關注業務和性能問題本身。在PTS 平臺上，您可以用較低的人力和資源成本，構造出最接近真實業務場景的複雜交互式流量，快速衡量系統的業務性能狀況，爲性能問題定位、容量最佳配比、全鏈路壓測的流量構造提供最好的幫助。進而提升用戶體驗，促進業務發展，最大程度實現企業的商業價值。詳情參見什麼是性能測試PTS

割接上線前的準備

應用的割接上線是整個應用上雲遷移實施的最關鍵環節，這一環節出問題，可能會造成重大故障。針對割接上線的重要性，我們建議在實施應用割接前，制定詳細的割接前檢查清單,這個清單的嚴謹程度也許很大程度上決定了割接成功率。根據我們以往的經驗，對割接上線前的準備工作，以下給出幾點經驗：

• 割接前需要嚴格確認是否所有需要預先準備的工具、遷移環境（客戶本地數據中心端、網絡、雲端）等已經就緒。

• 檢查和確認雲環境Landing Zone已經就緒，並且確認雲環境中的規模，安全，控制，網絡以及身份驗證與設計保持一致。

• 割接上線時需多方人員參與，軟件廠商、集成商、用戶方、雲廠商等,確認這些相關人員是否已經就緒。支持的方式是現場、遠程還是電話。

• 回滾預案是否就緒。割接過程好像在打一場大的戰役，很多的任務或子任務會分配半小時內計劃執行結束，整個過程可能會非常緊張。爲降低壓力，即使因爲某個主客觀原因導致遷移無法成功進行，如果有補救措施會讓整個遷移團隊降低很多壓力。這個補救措施之一就是回滾預案，也即是失敗後回滾到客戶的原數據中心恢復業務應用，需要在割接時預留回滾執行的時間。回滾執行後，然後擁有充足的時間排查問題，以備下一個割接窗口期內再次割接。

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

制定詳細的割接實施方案

遷移項目是複雜的，大部分遷移割接的時候都會或多或少的遇到一些無法預料的問題。造成割接失敗，可能有主觀原因和客觀因素。主觀原因可能因爲遷移調研問題、遷移方案設計缺陷、遷移驗證過程不夠全面等。客觀因素通常是客戶IDC、運營商網絡、雲數據中心故障等。無論哪種問題導致，都可能會對遷移割接造成失敗。根據以往的項目經驗，我們建議在割接前制定詳細的割接實施方案，以下是關於割接實施方案的一些建議。

• 數據驗證，確認割接時與割接前數據保持一致。通常客戶的大部分服務器鏡像及數據會在割接前預先在雲端複製完成。在割接窗口期開啓後需要確保雲端複製的數據與客戶數據中心下線前保持嚴格一致。

• 並非所有問題都會導致遷移失敗。遇到問題的時候，首先評估問題的嚴重程度，如果不是關鍵業務應用的重要的問題，可以將割接流程繼續進行，同時該問題繼續解決。與客戶協商，該問題是否會對業務有很大影響，如果客戶可以接受的話，可以先上線，然後儘快解決該問題。

• 遷移時間拖延問題處理。如果割接時不夠順利，因爲種種主客觀原因導致遷移割接時間長於計劃時間，可以與客戶協調，一起決定是否可以延遲一些時間上線。通常設計割接計劃時都會留出一些緩衝時間，如果需要延遲的時間過長是客戶無法接受的，那就只能執行回滾預案了。

• 網絡切換問題處理。比如IP,端口，網絡配置,DNS等問題，在之前的調研和檢查中出現遺漏。這種問題在割接時經常會遇到，出現這種問題緊急聯繫相關負責方儘快解決，但並不一定會影響割接整體進行。

• 遷移的不僅是服務器或數據。而是整個企業的IT應用及環境，客戶應用需要的身份管理、安全配置、數據及系統備份、高可用性架構配置，容災方案等都需要完成。

• 嚴格按照遷移設計方案中指定的雲服務型號匹配雲上資源。拿VM舉例，通常雲上會提供十幾個系列，數百種VM型號，使用錯誤的VM即使能夠將服務啓動起來，但會帶來性能、功能以及成本的問題。

• 遷移過程確保安全合規。數據遷移嚴格使用加密數據傳輸，加密數據存儲。證書、密碼、權限按照合規的方式申請和使用，杜絕泄露隱患。避免因安全合規性問題帶給客戶嚴重損失。

• 制定詳細的割接及回滾步驟，明確每個步驟執行時間點，前置條件，相關責任人等。以下是割接及回滾步驟的示例模板，在具體的項目中可以根據項目需求來設計定製。

割接實施步驟模板示例：

回滾實施步驟模板示例：

割接後持續觀察驗證

割接後對遷移的應用雲上運行情況持續觀察驗證，做好業務和數據做好監控，持續觀察業務的運行狀態，直到確認完全沒有問題，割接執行工作纔算基本結束。

關注【TechLeadCloud】，分享互聯網架構、雲服務技術的全維度知識。作者擁有10+年互聯網服務架構、AI產品研發經驗、團隊管理經驗，同濟本復旦碩，復旦機器人智能實驗室成員，阿里雲認證的資深架構師，項目管理專業人士，上億營收AI產品研發負責人。
如有幫助，請多關注
TeahLead KrisChang，10+年的互聯網和人工智能從業經驗，10年+技術和業務團隊管理經驗，同濟軟件工程本科，復旦工程管理碩士，阿里雲認證雲服務資深架構師，上億營收AI產品業務負責人。