在完成阿裡雲上應用系統架構設計後，開始進入實施階段，對應用系統進行架構和代碼級的編碼改造實施工作。
3.4.1 應用架構改造
在應用架構改造中，主要涉及負載均衡改造、Web和應用層改造、服務化改造幾方面問題。
1 . 負載均衡改造
原有系統Web、應用伺服器采用硬體負載均衡裝置F5或開源LVS實作Web、應用伺服器負載均衡。遷雲時需要改造為雲上SLB負載均衡服務。雲上SLB服務可以支援TCP、HTTP、HTTPS等三種協定實作流量負載均衡，同時支援自動對Web、應用伺服器進行健康檢查，自動屏蔽異常狀态的伺服器，在伺服器恢複正常後自動解除屏蔽重新提供服務。如圖3-10所示，整個業務架構中将硬體負載均衡裝置F5或自建LVS叢集改造為SLB負載均衡服務。
2 . Web和應用層改造
如果原系統Web、應用部署在小型機、PC Server、商業或開源虛拟化伺服器上，則可直接部署在雲上彈性計算服務ECS上。目前ECS可支援多種Linux和Windows類型的作業系統。為保證Web、應用服務的高可用性，建議同一類服務至少部署在兩台ECS伺服器上，使用SLB實作負載均衡和服務容錯。圖3-11給出了Web和應用層架構改造的示意圖。
3 . 服務化改造
對應用系統進行服務化改造，可使用消息中間件來實作業務系統的解耦，通過對資料庫按不同業務進行拆分提升資料庫的性能。例如，淘寶的系統架構充分使用了服務化設計思想和消息中間件産品實作業務系統的服務化設計和解耦。圖3-12給出了業務服務化改造的過程。
在圖3-12的架構圖中，消息中間件主要的應用場景包括：
分布式事務：為面向服務架構實作最終一緻性的分布式事務提供支援，保證全局資料的最終一緻性。
延時隊列：把消息中間件當做可靠的延遲隊列。
廣播通知：把消息中間件作為可靠的叢集内廣播通知，用于通知cache失效等事件。
3.4.2 資料庫改造
資料庫改造分為OLTP類關系資料庫架構改造和OLAP類關系資料庫架構改造，下面分别介紹這兩類情況下的改造方案。
OLTP類關系資料庫架構改造
對于通路量比較小的基于關系資料庫的系統，系統架構如圖3-13所示。
随着業務壓力不斷增大，單個RDS的讀寫已經無法滿足業務通路請求的時候，尤其是讀壓力非常大的系統，可以考慮使用阿裡雲Memcahe或Redis緩存系統來分攤讀壓力，通過緩存熱點資料來提供快速通路，詳細架構如圖3-14所示。
對于讀壓力較大的場景也可以考慮通過增加RDS隻讀執行個體，将系統改造成讀寫分離的應用架構。特别是對于有些資料分析類的場景，讀寫分離也是非常有效的解決方案之一。采用讀寫分離架構對業務讀能力進行擴充改造時，業務人員需要對業務系統進行評估，将系統中對延時不敏感的業務切換到到隻讀執行個體通路。資料庫讀寫分離架構如圖3-15所示。
考慮到RDS存儲容量不超過2T的限制，以及RDS單執行個體的性能瓶頸，當資料庫的單執行個體存儲空間無法滿足或寫入的TPS接近資料庫能力上線時，資料庫通常需要做垂直與水準拆分，垂直拆分是指根據不同業務類型或功能将資料庫拆分到不同的RDS執行個體存儲，水準拆分是指将同一類業務或資料通過一定的路由規則存儲到不同的RDS執行個體中。資料庫拆分的難度通常比較大，需要考慮如何做業務切分。當業務切分後，資料會分布到多個節點，導緻一系列分布式問題，如分布式事務、跨庫查詢、全局唯一ID等，是以在進行資料庫架構設計或改造的過程中，我們應盡量減少拆分，降低應用實作的難度。如必須拆分，可遵從先做服務化改造以進行資料庫垂直拆分，再考慮進行資料庫水準拆分。
阿裡雲平台上的分布式資料庫服務DRDS提供資料庫水準拆分和讀寫分離功能。它盡量屏蔽了分布式對應用開發的影響，同時也幫助使用者在一定程度上解決了資料庫水準拆分導緻的全局唯一ID、跨庫查詢、分布式事務等問題。DRDS資料庫水準拆分和讀寫分離原理如圖3-16所示，同一張表的資料通過一定路由政策和算法均衡的分布到多個RDS讀寫執行個體，并通過DRDS的讀寫分離功能自動幫使用者将讀流量路由到隻讀RDS執行個體。
2 . OLAP類關系資料庫的架構改造
OLAP聯機分析處理類型系統是資料倉庫系統最主要的應用類型，用于支援複雜的分析操作，側重對決策人員和高層管理人員的決策支援，可以根據分析人員的要求快速、靈活地進行大資料量的複雜查詢處理，并且以一種直覺而易懂的形式将查詢結果提供給決策人員，以便他們準确掌握企業的經營狀況，了解客戶的需求，制定正确營運方案。
阿裡雲針對OLAP聯機分析處理類應用的規模大小有不同的解決方案：
小規模分析系統：這類OLAP系統僅針對具體某一類業務的曆史資料進行離線和實時資料分析，一般資料量在1TB以内，分析所使用的資料在十個次元以内，對資料分析的時效性要求較低。對于這類應用系統，一般可直接采用RDS關系資料庫作為底層的資料存儲系統，并在其上建構OLAP分析工具。
大規模實時資料分析：這類OLAP系統面向資料存儲規模在TB級别以上，單表記錄數達到千億級别，業務對資料分析時效性要求較高，一般需要秒級内傳回結果的系統可通過阿裡雲實作大規模資料分析存儲系統AnalyticDB構架實時分析系統。
大規模離線資料分析：這類OLAP系統面向資料存儲規模在TB、PB級别以上，單表記錄數億級以上，需要做非常複雜的計算操作，業務對資料分析時效性要求較低，一般在分鐘級傳回結果的系統。此類業務可基于阿裡雲MaxCompute大計算産品建構離線分析系統。
3.4.3 檔案存儲改造
傳統行業通常采用SAN、NAS、關系型資料庫存儲檔案或圖檔等資料。但SAN方案成本過高且擴充性受限，NAS無法保證高性能，關系型資料庫存儲檔案成本高且嚴重影響應用系統性能，是以給存儲帶來一定困難。阿裡雲OSS開發存儲服務（Open Storage Service）能提供海量、安全、低成本、高可靠的雲存儲服務，适合存放檔案、圖檔等非結構化資料。同時，OSS提供Java、Python、PHP、C#語言的SDK。使用者可以通過調用對應開發語言的API，在任何應用、任何時間、任何地點上傳和下載下傳資料，也可以通過Web控制台對資料進行管理。
在OSS中，使用者的每個檔案都是一個Object（對象），Object包含key（關鍵字）、data（資料）和user meta（使用者元組）。key是Object名，user meta是對資料的描述。存儲在OSS上的每個Object必須都包含在Bucket中，Bucket名在整個OSS中具有全局唯一性且不能修改。
從其他檔案存儲産品遷移至OSS上時，隻需要使用阿裡官方提供SDK和API接口替換原有接口即可。
OSS使用的場景包括存儲檔案、圖檔、視訊等非結構化資料；存儲應用系統日志、資料備份；替換使用者自建檔案存儲系統。
圖3-17給出了OSS的業務架構，基于OSS建構面向檔案對象的存儲系統架構的特點如下：
OSS負責存儲檔案、照片、視訊等海量非結構化資料。
RDS負責存儲業務系統所有的結構化資料，包含檔案、照片、視訊等非結構化資料OSS通路位址或索引。
基于OSS建構獨立的檔案存儲管理系統，應用程式可使用SDK或API方式與OSS存儲服務對接，實作對檔案、照片、視訊等非結構化資料的管理。在整個檔案系統的存儲架構中，應用系統設計者無須考慮系統的高可用、性能和擴充能力，這些都會由底層OSS對象存儲服務來保證。
（1）OSS主要通路接口
OSS為使用者提供資料存儲服務，使用者可以通過以下API接口和SDK來管理和維護OSS上的資料：
OSS Bucket相關接口：可支援Bucket建立、檢視、羅列、删除以及修改、擷取Bucket的通路權限等操作。
OSS Object相關接口：可支援Object對象上傳、檢視、羅列、删除，并支援大檔案分片上傳等操作。
OSS通路相關：支援If-Modified-Since和If-Match等HTTP參數。
OSS支援Object生命周期管理，使用者可自定義OSS上存儲資料的過期時間，在到期後，OSS會自動幫助使用者完成過期資料清理和空間回收。
OSS支援防盜鍊，采用基于HTTP header中表頭字段referer的防盜鍊方法。
OSS支援使用STS服務臨時授權和URL簽名授權通路。
OSS提供相應接口，友善開發者控制跨域通路的權限。
（2）OSS檔案存儲接口改造
OSS提供兩種通路方式：SDK和API接口。目前已支援SDK的開發語言有：Java、Python、Android、iOS、PHP、.NET、NodeJS、C SDK開發包。如使用其他語言，需要使用者自己封裝API接口。
對于原來采用檔案存儲伺服器方式存儲檔案、圖檔資訊的程式，需要将原通路接口改造為OSS官方提供的标準SDK或API接口。
對于原來采用關系資料庫方式存儲檔案、圖檔資訊的程式，需要修改關系資料庫表結構和程式的資料讀寫代碼。改造關系資料庫表結構時，需要将原BLOB類型修改為varchar類型，存儲檔案對象所在OSS的位址。
3.4.4 大資料實時計算應用改造
很多情況下，傳統行業一個業務系統對應背景一個Oracle資料庫，Oracle資料庫基本支援全部業務，既包含線上事務型的業務，也包含實時分析類業務，同時還有離線處理類型的業務。當實時分析、離線處理的業務和線上事務型業務疊加的時候，往往會導緻Oracle資料庫系統不堪重負，使線上業務系統性能出現嚴重問題，甚至無法使用。
對于導緻性能壓力過大的實時分析處理類的功能，建議從原有線上業務系統中剝離開。AnalyticDB作為傳統關系型資料庫的補充，将部分分析處理類的業務遷移至AnalyticDB上執行。對于離線處理類的業務改造将在下一節闡述。
目前适合使用AnalyticDB的業務需符合如下特征：
不要求強一緻性，可接受最終一緻性的業務場景。
對資料更新頻率要求不高，可以接受分鐘級及以上資料寫入延時。
需要計算的資料量單表至少在百萬量級，最高可到千億量級。
對計算速度相對要求苛刻，可滿足響應時間在1s至10s間業務場景的要求。
支援SQL語句通路，暫不對外支援複雜的計算，如MPI、MapReduce、BSP等計算模型接口。
單個資料表通路，不需要進行多表之間的關聯查詢，主要是單個大表的上卷、下鑽、過濾等多元分析場景。
資料分析類業務，以一個大的事實表為中心，多個較小的次元表和事實表進行關聯查詢，然後進行上卷、下鑽、過濾等多元分析場景。
1 . AnalyticDB庫表設計
1）表類型：AnalyticDB庫表包括次元表和事實表兩類。其中，次元表一般是指存儲配置和元資訊的表，資料量較小。事實表一般是指系統中資料量為千萬級以上的表。
2）表組：在AnalyticDB中，每一個表都必須屬于一個表組。設計時需要充分考慮業務使用情況，将需要關聯查詢的表劃分到同一個表組，同一個表組内，一級分區數量必須一緻。
3）表分區：AnalyticDB分區支援HASH分區和LIST分區，并支援兩級分區。事實表必須要指定分區和表組，次元表不需要指定分區但要指定表組。選擇一級分區字段時，要盡可能保證資料分布均勻，單個分區的資料量在1GB以内或1000w級以下。Hash分區是根據導入資料時已有的一列的内容進行散列後進行分區的，是以目前多張表進行Join時，Join列必須包含分區列，并且表的Hash分區數必須一緻。另外，采用Hash分區的資料表，在資料裝載時會全量覆寫曆史資料的。List分區則是根據進行導入操作時指定的分區列值來進行分區的。
事實表的分區設計有兩種類型：隻采用一級分區，采用Hash分區方式；采用二級分區，一級分區為Hash分區，二級分區采用List分區。第一種方式是AnalyticDB最常用的分區設計方式，适用于大部分情況。第二種方式中，一級分區使用Hash分區，二級分區采用List分區。二級List分區可支援資料增量導入，如每天新增一個二級List分區存儲業務新增資料。
4）資料類型：AnalyticDB資料類型是MySQL資料類型的子集。如表3-1所示。
注：分析型資料庫所有的資料類型都不支援unsigned，下表不包含該差異
2 . AnalyticDB資料同步和內建
阿裡雲提供了多種資料同步和內建工具，如CDP、DTS，可支援從RDS、Oracle、OSS、文本檔案等資料源實時或定期同步到AnalyticDB資料庫。DTS資料傳輸産品可支援從RDS（MySQL）實時同步資料到AnalyticDB資料庫，資料延時在分鐘級别。CDP雲上資料同步管道可支援關系資料庫到阿裡雲資料存儲産品、阿裡雲資料存儲産品之間的定期批量資料同步。同時AnalyticDB提供Web化的管理控制台，可将MaxCompute資料批量導入到AnalyticDB，以及提供SQL接口支援應用程式向AnalyticDB寫入資料。
3 . 使用AnalyticDB的注意事項
表限制
AnalyticDB資料以二維表方式存儲，一般可分為次元表和事實表。
次元表主要用于存儲資料量較小，且修改不頻繁的業務資料，如meta類資料。一般建議次元表資料行數小于1000萬且占用存儲空間小于1GB。AnalyticDB次元表不支援分區。次元表和事實表關聯查詢時，關聯列需要在資料導入前添加哈希索引，否則無法進行表關聯。
事實表一般建議存儲資料量較大，且更新頻繁的業務資料，如消費記錄資料。事實表一般比較大、資料行在千萬級以上。事實表可支援分區，分區列可支援日期或數值類型。使用事實表時需要注意，建立事實表必須指定所屬資料庫和表組。
事實表的限制如下：
一張事實表至少有一級Hash分區并且分區數不能小于8個。
一個事實表組最多可以建立256個事實表。
一個事實表最多不能超過1024個列。
資料導入限制
AnalyticDB提供多種資料批量導入的功能，執行資料導入操作前需要進行相應的授權操作。例如，資料來源在MaxCompute上，則需要在MaxCompute上對特定賬号授予源表的describe和select權限。
AnalyticDB目前僅允許操作者導入自身為Project Owner的MaxCompute Project中的資料。如果不滿足這些條件，發起導入指令時會報can not load table meta錯誤。
使用限制
為了更高效地進行表關聯，AnalyticDB中兩個事實表進行關聯查詢必須滿足以下充要條件：
兩張表在一個表組。
兩張表的Join Key是Hash分區列。
兩張表的Hash分區數必須一緻，否則Join結果不準确。
兩張表的Join Key至少有一列建立了HashMap索引，推薦建立在資料量較小的一側。
次元表參與關聯查詢，隻需要符合上述第4點即可。
上述内容為AnalyticDB對多表關聯查詢的限制。另外，AnalyticDB還會對通過SELECT語句進行查詢的結果傳回行數設定限制，預設隻傳回10000行。
3.4.5 大資料離線分析應用改造
對于使用者大資料離線分析類應用，建議對其進行改造，以已比對阿裡雲MaxCompute大資料計算服務。
大資料計算服務是一種快速、完全托管的海量資料倉庫解決方案。MaxCompute向使用者提供了完善的資料導入方案以及多種經典的分布式計算模型，能夠更快速地解決使用者海量資料計算問題。MaxCompute主要服務于批量結構化資料的存儲和計算，可以提供海量資料倉庫的解決方案以及針對大資料的分析模組化服務。
1 . 使用場景
MaxCompute主要用于離散資料存儲和批量計算場景，不适用于實時存儲和分析場景。一般運作在MaxCompute之上的業務系統對資料時效性要求低，通常是T+1的系統，同時MaxCompute可支援TB/PB級資料的離線分析和處理。使用MaxCompute的一般做法是，資料從業務系統抽取到MaxCompute後，經過MaxCompute離線分析處理後，将分析處理後的結果回寫到業務系統，業務系統直接查詢和通路MaxCompute分析處理後的結果。
目前有大量使用者的資料倉庫類應用都是基于Oracle關系資料庫建設的，當使用者資料量達到TB級特别是10TB以上後，大規模離線資料計算場景Oracle資料庫計算性能已無法滿足使用者的業務需求。下面将以基于Oracle資料庫建構的大資料分析應用為例，介紹如何從Oracle遷移到阿裡雲MaxCompute服務。
2 . MaxCompute結構設計與改造
（1）MaxCompute表設計
MaxCompute的存儲結構與關系型資料庫有本質差異，需要根據Oracle原始表結構，對其在MaxCompute中的存儲方式與結構進行設計。由于其不是一一對應的關系，故需要對每個資料表進行逐一的核對後，方可最終确定MaxCompute的資料結構。
資料類型轉換規則如表3-2所示。
（2）MaxCompute表屬性設計
MaxCompute表屬性設計主要包含表命名規範、表注釋、表資料生命周期、是否開啟極限存儲等方案。
在表命名規則方面，建議和業務系統資料庫名、表名保持一緻，如采用業務系統庫名_業務系統表名方式。表注釋主要用于描述表的功能和作用，注釋内容要求不超過1024位元組。
MaxCompute提供資料生命周期管理功能，友善使用者釋放存儲空間，簡化回收資料空間的流程。使用者可在建立表時通過lifecycle屬性指定資料生命周期，生命周期時間必須設定為正整數，機關是天。資料表是否開啟極限存儲功能主要适用于按天分區的全量快照表，且不同分區的資料重複度高的場景。
（3）MaxCompute分區設計
MaxCompute主要用于離線存儲、批量計算和分析，資料源于線上業務系統資料庫。一般采用批量同步技術，按指定周期将線上業務資料庫資料同步到MaxCompute進行存儲和分析。為友善存儲和分析，會使用MaxCompute分區表存儲資料，表分區規則建議按時間劃分分區，表分區鍵及定義為：dt string。MaxCompute分區分為靜态分區和動态分區，可以做多個分區層級。一個表允許的分區個數支援按照具體的project配置，預設值為60 000個。
靜态分區在插入資料前已認證添加分區方式建立。動态分區在使用insert overwrite插入到一張分區表時，可以在分區中指定一個分區列名，但不給出值。相應的，在select子句中的對應列來提供分區的值。動态分區的限制如下：
目前，在使用動态分區功能的SQL中，在分布式環境下，單個程序最多隻能輸出512個動态分區，否則引發運作時異常。
在現階段，任意動态分區SQL不可以生成超過2000個動态分區，否則會引發運作時異常。
動态生成的分區值不能為NULL，否則會引發異常。
如果目标表有多級分區，在運作insert語句時允許指定部分分區為靜态，但是靜态分區必須是進階分區。
注意，在表中出現的分區層次不能超過6級。
3 . SQL改造
MaxCompute隻能以表的形式存儲資料，并對外提供了SQL查詢功能。使用者可以将MaxCompute作為傳統的資料庫軟體操作，但其卻能處理TB、PB級别的海量資料。MaxCompute SQL與Hive SQL高度相容，但MaxCompute不支援事務、索引及Update/Delete等操作，同時MaxCompute的SQL文法與Oracle、MySQL有一定差别，使用者無法将其他資料庫中的SQL語句無縫遷移到MaxCompute上來。是以，需要結合MaxCompute文法進行SQL語句改寫，MaxCompute SQL文法請見官方文檔：
4 . 資料同步和更新
使用MaxCompute服務後，需要配置同步任務從線上業務系統定時或實時同步更新MaxCompute資料。可以使用阿裡雲BASE平台配置資料同步任務完成MaxCompute資料同步，再通過MaxCompute SQL實作MaxCompute曆史資料的更新操作。
5 . MaxCompute的注意事項
使用MaxCompute時，有一些注意事項，如表3-3所示。