自創立以來的，淘寶業務發展非常迅速，幾乎是每年以 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 數據庫，採用分佈式方式實現讀寫分離，寫交易主要發生在主庫，讀請求訪問備庫，可以根據需求對讀庫進行擴展，以實現整體請求性能的提升。

對於數據規模較大的數據庫表，可以通過水平切分的方式，將數據分佈在多個 RDS 實例上，通過並行的分佈式數據庫操作來實現性能和容量的提升。

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

對於 OLAP 應用，可採用 ODPS+OTS+RDS/ADS 的解決方案取代小型機 + Oracle DB+OLAP+RAC+EMC 存儲解決方案，如圖 11 所示。

總體來看，遷雲的通用架構方案如圖 12 所示，針對具體業務系統的遷雲方案還需要根據實際情況進行分析和合理選擇。

本文由 Readfog 進行 AMP 轉碼，版權歸原作者所有。
來源：https://mp.weixin.qq.com/s/4KmkVzuQUDWQXFVpiOr91A