產品選型策略

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

場景示例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平臺，提供應用開發、部署、監控、運維等全棧式解決方案，支持Spring Cloud、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）業務功能提取為微服務

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

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

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

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

  • 頻繁變化（業務維度）

  • 頻繁調用

  • 相對獨立

  • 共享的基礎數據

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

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

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

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

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

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

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

場景示例：阿里云SAP上云方案

SAP HANA是一個軟硬件結合體，提供高性能的數據查詢功能，結合了大量交易與實時分析能力，顯著提升商業效率，助力企業數字化轉型。阿里云多個ECS企業級云服務器產品規格通過SAP HANA認證，企業用戶可以在阿里云上放心部署和運行基于SAP HANA數據庫的關鍵業務系統。SAP在企業管理軟件領域有著豐富經驗，結合阿里云彈性和可擴展性、快速部署、高度穩定性、全球基礎設施等優勢，可以幫助企業輕松應對業務變化，加速業務系統的部署。

阿里云SAP上云及云上運維最佳實踐

針對企業用戶SAP上云的需求，阿里云提供了場景豐富的SAP云上部署及運維最佳實踐，詳情參見以下。

• SAP S/4HANA 同可用區高可用部署指南

• SAP HANA 同可用區高可用部署指南

• SAP HANA Scale-Out 部署指南

• ECS Metrics Collector for SAP部署指南

• SAP系統云盤擴容指南

• SAP系統高可用環境維護指南

數據上云架構設計

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

數據上云安全防護

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

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

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

• 傳輸中數據保護：功能包括 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特性，適用于多種數據庫遷移上云場景。