在淘寶初期，應用數量與使用者數都較少，可以把tomcat和資料庫部署到一臺伺服器上。瀏覽器往淘寶發起請求時，首先經過DNS伺服器將域名轉換為對應的IP，再通過IP訪問tomcat。
缺點很明顯，隨著使用者數的增長，tomcat和資料庫之間競爭資源，單機效能不足以支撐業務。下面進行架構優化：

第一階段 本地快取和分散式快取

第二階段 反向代理實現負載均衡

第一階段的快取抗住了大量的請求，但是隨著使用者的繼續增長，併發的壓力主要落在單機的tomcat上，響應逐漸變慢，需要反向代理實現負載均衡。

第三階段 資料庫讀寫分離

第二階段的方向代理使應用伺服器可支援的併發量大大增加，但併發量的增加也意味著更多的請求穿透到資料庫，單機的資料庫最終成為瓶頸，需要對資料庫進行讀寫分離。

第四階段 按業務分庫

隨著業務逐漸變多，不同業務的訪問量差距變大，不同業務直接競爭資料庫，相互影響效能，需要按業務分資料庫。

第五階段 表格橫向/垂直拆分

隨著使用者的逐漸增長，表格的資料逐漸增多，操作速度越來越慢，需要對錶格進行拆分。

第六階段 LVS/F5 使多個Nginx負載

資料庫和tomcat都能水平擴充套件，可支撐的併發大幅提高，隨著使用者的增加，單機的Nginx也會成為瓶頸，引入LVS/F5 使多個Nginx負載。

第七階段 DNS輪詢實現機房負載均衡

因為LVS也是單機的，隨著併發數增長到幾十萬時，LVS伺服器最終也會達到瓶頸，此時使用者數達到千萬甚至上億級別，使用者分佈在不同的地區，與伺服器機房的距離不同導致了訪問延遲會明顯不同。所以需要引入DNS輪詢，實現機房的負載均衡。

第八階段 搜尋引擎+NoSQL資料庫實現豐富的檢索需求

隨著資料的豐富程度和業務的發展，檢索、分析等需求越來越豐富，單單依靠資料庫無法解決如此豐富的需求。需要引入搜尋引擎+NoSQL資料庫實現豐富的檢索需求。

第九階段 應用拆分+服用功能抽離微服務

引入更多的元件解決了豐富的需求，業務維度能夠極大擴充，隨之而來的是一個應用中包含了太多的業務程式碼，業務的升級迭代變得更加困難，需要將大應用拆分成小應用。而不同應用之間存在著共用的模組，由應用單獨管理會存在相同程式碼存在多份，導致公共功能升級時全部應用程式碼都要跟著升級。所以抽離微服務（還不是嚴格意義上的微服務）。

第十階段 企業服務匯流排ESB遮蔽服務介面的訪問差異

應用訪問服務，服務之間也可能相互訪問，呼叫鏈將會變得非常複雜，邏輯變得混亂。所以引入企業服務匯流排ESB遮蔽服務介面的訪問差異。

第十一階段 容器化技術實現執行環境隔離與動態服務管理

應用和服務的部署變得複雜，同一臺伺服器上部署多個服務還要解決執行環境衝突的問題，此外對於如大促這類需要動態擴縮容的場景，需要水平擴充套件服務的效能，所以引入容器化技術實現執行環境隔離與動態服務管理。

第十二階段 雲平臺的複雜應用

使用容器化技術，服務動態擴縮容問題得以解決，但是機器還是需要公司自身來管理。在非大促的時候，還是需要閒置著大量的及其資源來應對大促，機器自身的成本和運維成本都極高，資源利用率低。所以將系統部署到公有云上，利用公有云的海量機器資源，解決動態硬體資源的問題。在大促的時間段裡，在雲平臺中臨時申請更多的資源，結合docker和k8s來快速部署服務。在大促結束後釋放資源，真正做到按需付費，資源利用率大大提高，同時降低了運維成本。