云計算作為信息技術領域的一種創新應用模式，自其誕生以來一直備受關注。由于其具備低成本、彈性、易用、高可靠性、按需服務等特點，近年來被看作是新一代信息技術變革和商業模式變革的核心。互聯網、游戲、物聯網等新興行業紛紛積極擁抱云計算，對大部分企業用戶來說，受限于傳統IT技術架構的束縛，往往缺乏遷移到云計算的動力和技術實現參考。

　　傳統IT架構的技術特點和面臨的問題

　　企業中最核心的系統通常是數據庫管理系統，用以滿足實時交易和分析的需求。傳統的單機數據庫采用“向上擴展”（Scale-Up）思路但這種方式一般只能夠支持幾個TB 數據的存儲和處理，遠不能滿足實際需求。

　　為了達到高性能和更大數據存儲容量的要求，采用集群設計的OLTP系統逐步成為主流。如圖1所示，常見的企業數據庫集群如Oracle RAC通常采用Share-Everything（Share-Disk）模式。數據庫服務器之間共享資源，例如磁盤、緩存等。當性能不能滿足需求時，要依靠升級數據庫服務器（一般采用小型機）的CPU、內存和磁盤，來達到提升單節點數據庫服務性能的目的。另外，可以增加數據庫服務器的節點數，依靠多節點并行和負載均衡來達到提升性能和系統整體可用性的效果。但當數據庫服務器節點數量增大時，節點之間的通信將成為瓶頸，而且處理各個節點對數據的訪問控制將受制于事務處理的一致性要求。從實際案例來看，4節點以上的RAC非常少見。

　　另外，根據摩爾定律，處理器的性能約每隔18個月便會增加一倍，而DRAM的性能大約每10年才會增加一倍，使得處理器和內存的性能形成剪刀差。雖然處理器的性能在快速提升，但由于磁盤的機械轉速與磁臂的尋道時間的限制，磁盤存儲性能提升緩慢，硬盤的IOPS性能近10年基本沒有太大提升（HDD磁盤的轉速一直在7200-15000RPM)，基于HDD的磁盤陣列存儲越來越成為集中式存儲架構的性能瓶頸，而全閃存陣列受限于高昂的成本和擦寫壽命還遠達不到大規模商用的要求。

　　因此，IOE的集中存儲（Share-Everything）方式存在性能、容量與擴展性的局限，同時成本居高不下。而互聯網化帶來的高并發，大數據的處理要求，x86和開源數據庫技術的飛速發展， NoSQL、Hadoop等分布式系統技術的逐漸成熟，互聯網化帶來的高并發、大數據的處理要求，使得系統架構開始從集中式的Scale-up架構向分布式的Scale-Out架構發展。

　　IT互聯網化帶來的技術挑戰與應對之道 

　　Gartner的IT專家預測出了2015年的十大信息科技趨勢，這些趨勢被認為會在未來三年對行業產生重大影響，其中之一就是“網絡規模IT”，即越來越多的公司會建造類似亞馬遜、Google和Facebook的應用和架構。這將使網絡規模IT成為商用的硬件平臺，使得新模式、云優化和軟件定義方法成為主流。開發和操作的協同是向網絡規模IT發展的第一步。但傳統的IT系統在向互聯網化方向轉型時，通常需要面對以下幾個技術挑戰。

　　性能。用戶體驗是影響轉化率的重要因素，據統計如果4秒鐘打不開網站，將有60%的顧客會流失，糟糕體驗將導致大量的客戶選擇放棄或從競爭對手處購買服務。如何在高并發訪問的情況下保證系統的低延遲響應，以提升用戶體驗。

　　伸縮性。互聯網/移動互聯網用戶的訪問行為是動態的，在一些特殊的熱點引爆后，流量能夠通常達到平時的10倍甚至幾十倍以上。如何快速響應業務爆發時的資源開銷需求，提供無差別的用戶體驗。

　　容錯與最大可用性。互聯網應用系統基于分布式計算架構部署，基于大量的x86服務器和通用網絡設備。而機器一定會壞，當機器數量到一定規模時，小概率事件就成為常態，當硬件出現故障時應該如何自動化處理，人一定會在開發中寫出Bug，怎么進行系統的損害控制。如何基于單機QPS和并發數對服務端和客戶端進行限流，實現動態流量分配，識別服務之間的依賴鏈路風險和系統重要功能點依賴，評估最大可能的風險點，分布式系統最大可用性故障檢測，對故障模塊進行隔離，對未完成事物進行Rollback，通過犧牲非關鍵功能通過優雅降級保證核心功能可用。

　　容量管理。系統性能一定會到達瓶頸，如何進行更科學的容量評估和擴容，自動計算前端請求與后端機器數量的對應關系，對軟硬件容量需求進行預測。

　　服務化。如何將業務邏輯功能抽象成一個個原子服務，對服務進行封裝和組合，并基于分布式系統環境部署，以實現更靈活的業務邏輯和流程。如何從業務視角厘清這些服務的關系，對大規模分布式系統中的單條服務調用鏈進行跟蹤與展現，并能夠及時發現服務調用異常。

　　低成本。隨著系統的演進性能指標不斷發生變化，如何保證以最低成本滿足特定訪問量的要求。

　　自動化運維管理。不斷發展的大規模系統需要不斷維護、快速迭代和優化。如何應對從一臺到上千臺甚至上萬臺服務器的運維量變，通過自動化工具和流程管理大規模軟硬件集群，對系統進行快速部署、升級、擴容和維護。

　　隨著業務的快速發展，淘寶技術架構經歷從最初的LAMP架構，到IOE架構，再到分布式架構，最后到現在的云計算平臺架構這一變化過程在不斷解決上面的技術問題。

　　淘寶技術架構變遷

　　自2003年創立以來的，淘寶業務發展非常迅速，幾乎是每年以100%的速度在成長。創立之初，為了快速上線，搶占市場，選擇了當時流行的LAMP架構，用PHP作為網站開發語言， Linux作為操作系統，Apache作為Web服務器，MySQL為數據庫，用了三個月不到的時間淘寶就上線了。當時整個網站應用服務器大概10臺左右，MySQL數據庫采用了讀寫分離、一主兩備的部署方式。

　　2004年在淘寶業務發展的推動下，我們參考電信運營商、銀行等的一些企業解決方案，將LAMP架構改造為Oracle+IBM小型機的數據庫架構和EMC存儲方式（圖2）。雖然方案成本昂貴，但性能非常好。同時，隨著網站流量的增加，系統顯得有些不堪重負。當時最擔心的問題是網站流量如果持續增加，交易量持續增加，網站的系統架構怎么設計？如何選擇數據庫？如何選擇緩存？如何構建業務系統？

　　后來參考eBay的互聯網設計架構，設計了一個Java的技術方案，并使用了非常多的Java開源產品。例如，選擇當時比較流行的JBoss，作為應用服務器；選擇一個開源的IOC容器Spring，來管理業務類；封裝了一個數據庫訪問工具IBatis，作為數據庫和Java類的Object-Reletionship映射工具。另外，對于商品搜索功能，采用自己開發的ISearch搜索引擎來取代在Oracle數據庫中進行搜索，降低數據庫服務器的壓力。做法比較簡單，每天晚上全量將Oracle小型機的數據dump出來，Build成ISearch的索引，當時商品量也不大，一臺普通配置的服務器，基本上可以將所有的索引都放進去，沒做切分，直接做了一個對等集群。

　　從2006年開始，淘寶為了改善用戶體驗，開始建立自己的CDN站點，由于淘寶的主要流量來源于各種商品圖片、商品描述等靜態數據，自建CDN可以使這些資源離用戶更近，提升用戶訪問速度，改善用戶瀏覽網站的體驗。

　　2007年，淘寶全年的交易額超過400億元，平均近1億多一天，每天有100多萬筆交易被創建。當時面對的幾個主要問題是：一些系統的流量非常大，如商品詳情等，如果直接訪問數據庫，會導致數據庫壓力非常大；如用戶信息，訪問一個頁面，都需要查詢買家信息、賣家信息、顯示出買家的信用、賣家的服務星級等。此時，淘寶采用分布式緩存TDBM（Tair的前身）將這些熱點靜態數據緩存在內存中，提高訪問性能。另外，將自己研發的分布式文件系統TFS部署在多臺x86服務器上，取代商業的NAS存儲設備來存儲淘寶的各種文件信息，如商品圖片、商品描述信息、交易快照信息，來達到降低成本和提高整體系統的容量和性能的目的，同時可以實現更靈活的擴展性。第一期上線大概200臺TFS服務器。另外，將ISearch搜索引擎改為分布式架構，支持水平擴展，部署了48個節點。圖3展示了這一架構思路。

　　2008年初，為了解決Oracle數據庫集中式架構的瓶頸問題（連接數限制、I/O性能），將系統進行了拆分，按照用戶域、商品域、交易域、店鋪域等業務領域進行拆分，建立了20多個業務中心，如商品中心、用戶中心、交易中心等。所有有用戶訪問需求的系統，必須使用業務中心提供的遠程接口來訪問，不能夠直接訪問底層的MySQL數據庫，通過HSF這種遠程通信方式來調用業務中心的服務接口，業務系統之間則通過Notify消息中間件異步方式完成調用。圖4是淘寶的分布式架構圖。

　　從2010年開始，淘寶網重點著眼于統一架構體系，從整體系統層面考慮開發效率、運維標準化、高性能、高可擴展性、高可用、低成本方面的要求，底層的基礎架構統一采用了阿里云計算平臺（圖5），使用了SLB、ECS、RDS、OSS、ONS、CDN等阿里云計算服務，并通過阿里云服務提供的高可用特性，實現雙機房容災和異地機房單元化部署，為淘寶業務提供穩定、高效和易于維護的基礎架構支撐。

　　在從IOE架構最終向云計算平臺技術架構轉移的過程中，主要面臨以下幾個技術挑戰。

• 可用性：脫離小型機和高端存儲的高冗余機制，采用基于PC服務器的分布式架構的云計算平臺能否做到高可用。
• 一致性：Oracle基于RAC和共享存儲實現的物理級別一致性，基于RDS for MySQL能否達到同樣的效果。
• 高性能：高端存儲的I/O能力很強，基于PC服務器的RDS能否提供同樣甚至更高的I/O處理能力，MySQL和Oracle對SQL的處理性能是否相同。
• 擴展性：業務邏輯如何拆分，如何服務化，數據分多少庫分多少表，什么維度分，后期二次拆分如何更方便等。

　　基于阿里云計算平臺，通過采用合適的技術策略和最佳實踐，包括：應用無狀態，有效使用緩存（瀏覽器緩存、反向代理緩存、頁面緩存、局部頁面緩存、對象緩存和讀寫分離），服務原子化，數據庫分割，異步解決性能問題，最小化事物單元，適當放棄一致性。以及自動化監控/運維手段包括監控預警、配置統一管理，基礎服務器監控，URL監控，網絡監控，模塊間調用監控，智能分析監控，綜合故障管理平臺，容量管理。可以很好地解決以上問題，從而達到整體系統的高可擴展性、更低的成本、更高的性能和可用性的實現效果。

　　遷云架構最佳實踐

　　淘寶的技術架構是一個伴隨業務逐漸發展而逐步演進的過程，中間沉淀了很多寶貴的架構最佳實踐。對于大部分企業級客戶來說，可以結合自己的業務場景選擇合適的技術架構來實現整體IT系統的互聯網化設計。不同應用場景下的遷云架構，包括文件存儲、應用服務、OLTP數據庫、OLAP數據庫。

　　對于文件存儲方式，可以直接用OSS取代EMC存儲實現海量數據文件的存儲，OSS存儲最大容量可以達40PB，同時由于OSS是分布式存儲方式，可以通過多個節點的并行讀寫顯著提高數據訪問性能。對于大文件，還可以通過Multipart Upload的方式，將大文件分塊并行傳輸與存儲，實現高性能。

　　對于應用服務，可通過SLB+多臺ECS實例組合取代IBM小型機（圖6），也可以根據不同應用類型，直接基于ACE、ONS、OpenSearch等阿里云中間件云服務部署。

　　OLTP應用的遷移相對復雜。目前阿里云的RDS實例最高是48GB內存，14000IOPS，1TB的存儲容量（SSD存儲），支持MySQL和SQL Server。這個配置作為單數據庫服務器來使用可以滿足很多場景的數據庫應用需求，可直接取代大部分場景下的IBM小型機+Oracle數據庫+EMC存儲。

　　對于性能要求更高的應用，可考慮引入開放緩存服務OCS，將部分查詢數據加載至分布式緩存中，減少RDS的數據查詢次數，提升系統的數據查詢并發效率和降低響應時間，如圖7所示。

　　對于讀的請求遠大于寫請求的場景，可以考慮用多個RDS數據庫，采用分布式方式實現讀寫分離，寫交易主要發生在主庫，讀請求訪問備庫，可以根據需求對讀庫進行擴展，以實現整體請求性能的提升。圖8是帶只讀實例擴展的遷云架構。

　　對于數據規模較大的數據庫表，可以通過水平切分的方式，將數據分布在多個RDS實例上，通過并行的分布式數據庫操作來實現性能和容量的提升。圖9是帶數據拆分的遷云架構。

　　總的來說，通過遷移到RDS、引入數據緩存、分庫分表、讀寫分離等多種方式可以用Scale-Out方式取代原有的IOE架構，并且獲得更好的性能和擴展性。圖10中是遷云架構演進過程。

　　對于OLAP應用，可采用ODPS+OTS+RDS/ADS的解決方案取代小型機+Oracle DB+OLAP+RAC+EMC存儲解決方案，如圖11所示。總體來看，遷云的通用架構方案如圖12所示，針對具體業務系統的遷云方案還需要根據實際情況進行分析和合理選擇。

　　總結

　　通過采用不同的遷云架構實現方案，用戶可以根據不同的實現場景要求，將傳統的IT系統遷移到云端。通過云產品架構最佳實踐，使阿里云產品組合發揮最大效用，讓用戶充分享受云計算帶來的彈性、低成本、穩定、安全和易用等價值收益。