阿里P8架構師談：淘寶技術架構從1.0到4.0的架構變遷！附架構資料
淘寶技術架構變遷
自2003年創立以來的，淘寶業務發展非常迅速，幾乎是每年以100%的速度在成長。創立之初，為了快速上線，搶佔市場，選擇了當時流行的LAMP架構，用PHP作為網站開發語言， Linux作為作業系統，Apache作為Web伺服器，SQL/">MySQL為資料庫，用了三個月不到的時間淘寶就上線了。當時整個網站應用伺服器大概10臺左右，MySQL資料庫採用了讀寫分離、一主兩備的部署方式。
2004年在淘寶業務發展的推動下，我們參考電信運營商、銀行等的一些企業解決方案，將LAMP架構改造為Oracle+IBM小型機的資料庫架構和EMC儲存方式（圖2）。雖然方案成本昂貴，但效能非常好。同時，隨著網站流量的增加，系統顯得有些不堪重負。當時最擔心的問題是網站流量如果持續增加，交易量持續增加，網站的系統架構怎麼設計？如何選擇資料庫？如何選擇快取？如何構建業務系統？……後來參考eBay的網際網路設計架構，設計了一個Java的技術方案，並使用了非常多的Java開源產品。例如，選擇當時比較流行的JBoss，作為應用伺服器；選擇一個開源的IOC/">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資料庫，採用分散式方式實現讀寫分離，寫交易主要發生在主庫，讀請求訪問備庫，可以根據需求對讀庫進行擴充套件，以實現整體請求效能的提升。
對於資料規模較大的資料庫表，可以通過水平切分的方式，將資料分佈在多個RDS例項上，通過並行的分散式資料庫操作來實現效能和容量的提升。
總的來說，通過遷移到RDS、引入資料快取、分庫分表、讀寫分離等多種方式可以用Scale-Out方式取代原有的IOE架構，並且獲得更好的效能和擴充套件性。
對於OLAP應用，可採用ODPS+OTS+RDS/ADS的解決方案取代小型機+Oracle DB+OLAP+RAC+EMC儲存解決方案，如圖11所示。總體來看，遷雲的通用架構方案如圖12所示，針對具體業務系統的遷雲方案還需要根據實際情況進行分析和合理選擇。
以上就是淘寶的技術架構變遷詳解，以下是 最新阿里P8架構師談架構設計系列詳解 。
