在淘寶最初時，應用數量與用戶數都較少，可以把Tomcat和數據庫 部署在同一台服務器上。瀏覽器往www.taobao.com發起請求時，首先經過 DNS 服務器（域名系統）把域名轉換為實際 IP 地址 xx.xx.xx.xx，瀏覽器轉而訪問該 IP 對應的 Tomcat。
它的缺點很明顯,隨着用戶數的增長,Tomcat和數據庫之間競爭資源，單機性能不足以支撐業務，現在要求你對早 起淘寶進行架構優化，實現其千萬級並發架構.
第一階段本地緩存和分布式緩存
第二階段反向代理實現負載均衡 第一階段的緩存抗住了大部分的訪問請求，但是隨着用戶數的增長，並發壓力主要落在單機的Tomcat上，響應 逐漸變慢，需要使用反向代理實現負載均衡。
第三階段數據庫讀寫分離 第二階段反向代理使應用服務器可支持的並發量大大增加，但並發量的增長也意味着更多請求穿透到數據庫，單機 的數據庫最終成為瓶頸，需要對數據庫進行讀寫分離。
第四階段按業務分庫 隨着業務逐漸變多，不同業務之間的訪問量差距較大，不同業務直接競爭數據庫，相互影響性能。需要按業務分數 據庫。
第五階段表格橫向/垂直拆分 隨着用戶數的增長，表格數據越來越多，操作速度越來越慢，需要對表格進行拆分。
第六階段LVS/F5使多個Nginx負載 數據庫和Tomcat都能夠水平擴展，可支撐的並發大幅提高，隨着用戶數的增長，最終單機的Nginx會成為瓶 頸。需要引入LVS/F5使多個Nginx負載
第七階段DNS輪詢實現機房負載均衡 由於LVS也是單機的，隨着並發數增長到幾十萬時，LVS服務器最終會達到瓶頸，此時用戶數達到千萬甚至上億 級別，用戶分布在不同的地區，與服務器機房距離不同，導致了訪問的延遲會明顯不同。所以需要引入DNS輪訓，實現機 房的負載均衡
第八階段搜索引擎+NoSQL數據庫實現豐富的檢索需求 隨着數據的豐富程度和業務的發展，檢索、分析等需求越來越豐富，單單依靠數據庫無法解決如此豐富的需求，需 要引入搜索引擎+NoSQL數據庫實現豐富的檢索需求。
第九階段應用拆分+復用功能抽離微服務 引入更多組件解決了豐富的需求，業務維度能夠極大擴充，隨之而來的是一個應用中包含了太多的業務代碼，業務 的升級迭代變得困難，需要將大應用進行拆分，拆分為小應用。而不同應用之間存在共用的模塊，由應用單獨管理會導致相 同代碼存在多份，導致公共功能升級時全部應用代碼都要跟着升級。所以抽離微服務。
第十階段企業服務總線ESB屏蔽服務接口的訪問差異 應用訪問服務，服務之間也可能相互訪問，調用鏈將會變得非常復雜，邏輯變得混亂。所以引入企業服務總線 ESB屏蔽服務接口的訪問差異。
第十一階段容器化技術實現運行環境隔離與動態服務管理
x
應用和服務的部署變得復雜，同一台服務器上部署多個服務還要解決運行環境沖突的問題，此外，對於如大促這類 需要動態擴縮容的場景，需要水平擴展服務的性能。所以引入容器化技術實現運行環境隔離與動態服務管理
第十二階段雲平台的復雜應用 使用容器化技術后服務動態擴縮容問題得以解決，但是機器還是需要公司自身來管理，在非大促的時候，還是需要 閑置着大量的機器資源來應對大促，機器自身成本和運維成本都極高，資源利用率低。所以將系統部署到公有雲上，利用公 有雲的海量機器資源，解決動態硬件資源的問題，在大促的時間段里，在雲平台中臨時申請更多的資源，結合Docker和 K8S來快速部署服務，在大促結束后釋放資源，真正做到按需付費，資源利用率大大提高，同時大大降低了運維成本
