喬幫主的直播內容經精煉整理、分以下5篇：
一、分享介紹&架構三原則
二、雲架構、架構的原始階段和基礎階段
三、架構動靜分離和分佈式階段
四、架構數據緩存階段和兩個維度拓展階段
五、架構微服務階段
數據緩存階段：數據庫緩存
當訪問壓力達到500萬PV到1000萬PV，雖然負載均衡結合多臺 Web服務器，解決了動態請求的性能壓力。但是這時候我們發現，數據庫出現壓力瓶頸，常見的現象就是RDS的連接數增加並且堵塞、CPU100%、IOPS飆升。這個時候我們通過數據庫緩存，有效減少數據庫訪問壓力，進一步提升性能。
在這個架構階段採用的雲產品，如左邊架構圖所示，相比上階段，主要增加了雲memcache或者雲Redis。值得注意的是，數據庫緩存，需要業務代碼改造及支持。哪些熱點數據需要緩存，這需要業務方面重點規劃。並且雲端數據庫緩存，已不推薦在ECS中自行搭建Redis、memcache等，我們直接使用對應的雲緩存產品即可。這階段架構有兩個技術特點跟大家分享：
一個是緩存五分鐘法則：即如果一條記錄頻繁被訪問，就應該考慮放到緩存裡。否則的話客戶端就按需要直接去訪問數據源，而這個臨界點就是五分鐘。
第二個特點，緩存其實是在數據庫層面，對數據庫的讀寫分離中，對讀的一定程度解耦。
接著到達架構擴展階段：垂直擴展。
架構擴展階段：垂直擴展
當訪問量達到1000萬PV到5000萬PV，雖然這個時候我們可以看到通過分佈式文件系統OSS已經解決了文件存儲的性能問題，雖然通過CDN已經解決靜態資源訪問的性能問題。但是當訪問壓力再次增加，這個時候 Web服務器和數據庫方面依舊是瓶頸。在此我們通過垂直擴展，進一步切分 Web服務器和數據庫的壓力，解決性能問題。“那何為垂直擴展，按照不同的業務（或者數據庫）切分到不同的服務器（或者數據庫）之上，這種切分稱之為垂直擴展。”如左邊架構圖所示，在這個架構階段採用的雲產品，相比上階段，主要增加了數據庫層面的讀寫分離或者對應的切庫。
這個階段主要有三個技術特點：
第一點，業務拆分
在業務層，可以把不同的功能模塊拆分到不同的服務器上面進行單獨部署。比如，用戶模塊、訂單模塊、商品模塊等，拆分到不同服務器上面部署。
第二點，讀寫分離
在數據庫層，當結合數據庫緩存，數據庫壓力還是很大的時候。我們通過讀寫分離的方式，進一步切分及降低數據庫的壓力。
第三點，分庫
結合業務拆分、讀寫分離，在數據庫層，比如我們同樣可以把用戶模塊、訂單模塊、商品模塊等。所涉及的數據庫表：用戶模塊表、訂單模塊表、商品模塊表等，分別存放到不同數據庫中，如用戶模塊庫、訂單模塊庫、商品模塊庫等。然後把不同數據庫分別部署到不同服務器中。
此階段架構有兩個注意點：
架構的中後期，業務的瓶頸往往都是集中在數據庫層面。因為在業務層，我們通過負載均衡能夠快速添加更多服務器進行水平擴容，很方便快速解決業務服務器處理的壓力。而數據庫怎麼來做性能擴展，不是簡單加幾臺服務器就能解決的，這往往涉及到複雜的數據庫架構變更。垂直拆分，相對在業務上改動較少，並且數據庫性能提升最為高效的一種方式，是我們中大型應用首要採用的架構方案。
接著到達架構分佈式+大數據階段：水平擴展。
架構分佈式+大數據階段：水平擴展
當訪問量達到5000萬PV及以上時，當真正達到千萬級架構以上訪問量的時候，我們可以看到垂直擴展的架構也已經開始“山窮水盡”。比如，讀寫分離僅解決讀的壓力，面對高訪問量，在數據庫“寫”的壓力上面開始“力不從心”，出現性能瓶頸。另外，分庫雖然將壓力拆分到不同數據庫中。但單表的數據量達到TB級別以上，顯然已經達到傳統關係型數據庫處理的極限。如左邊架構圖所示，在這個架構階段採用的雲產品，相比垂直擴展階段，主要增加了DNS輪詢解析、非關係型數據庫MongoDB、以及表格存儲列數據庫OTS。
此階段有四個技術特點：
第一點，增加更多的web應用服務器
當後續壓力進一步增大，在負載均衡後面增加更多的web應用服務器進行水平擴展。
第二點，增加更多的SLB
單臺SLB也存在單點故障的風險，及SLB也存在性能極限，如七層SLB的QPS最大值為50000。我們可以通過DNS輪詢，將請求輪詢轉發至不同可用區的SLB上面，實現SLB水平擴展。
第三點，採用分佈式緩存
雖然阿里雲memcache內存數據庫已經是分佈式結構，保障了存儲在緩存中的數據高可用。但是使用緩存的業務場景是比較多的，我們不可能僅僅只是部署一個緩存服務，那麼業務之間的使用可能存在相互影響。所以我們用多個雲緩存，可以在代碼層通過hash算法將數據分別緩存至不同的雲緩存中，或者不同的業務場景直接連接使用不同的雲緩存，來提高我們業務的健壯性。
第四點，Sharding分片和NoSQL
面對高併發、大數據的需求，傳統的關係型數據庫已不再適合，需要採用非關係型數據庫NoSQL了。MongoDB和OTS作為NoSQL的典型代表，支持數據分片Sharding技術，根本上解決了關係型數據庫面對高併發高存儲量的痛點問題。
此階段架構注意點：
大型應用中，海量業務數據的存儲、分析給我們數據庫提出巨大挑戰。而傳統關係型數據庫明顯已經力不從心，分佈式數據庫NoSQL是適用技術發展的未來趨勢。有了海量業務數據的基礎，我們可以結合雲端MaxCompute大數據分析服務，來輔助業務進行價值創造。
雖然到達架構分佈式+大數據階段，基本上能滿足絕大多數千萬級架構的業務需求。但同時帶來新的挑戰：
第一個挑戰，分佈式架構下，在業務層面的擴展，業務後期迭代、維護管理、敏捷開發等問題。所以藉助前面的“雲對技術架構變革”的這個圖我們再次來看看。其實最後到達了容器體系下，微服務架構階段解決了分佈式架構帶來的業務層面擴展性問題。微服務是業務功能層面的一種切分，切分成一個單個小型的獨立業務功能的微服務。多個微服務通過API Gateway提供統一服務入口，讓微服務對前臺透明，而每個微服務也可以通過分佈式架構進行部署，這給我們研發靈活性、業務後期迭代帶來了極大的擴展性，這是我們未來軟件技術架構的主流。並且微服務，在雲平臺基礎上結合Docker容器技術進行部署。能讓業務、運維、架構在技術和非技術方面的穩定性、成本、效率、擴展等都能達到完美。
第二個挑戰，Big Data所帶來的離線計算問題。Big Data強調數據量，PB級以上，是靜態數據。並且強調離線計算，結算結果並不是實時的，需要等到離線任務執行完畢才能彙總結果。隨著企業數據需求不斷變化，近年來對數據採集的實時性、對數據在線計算的實時性要求日益明顯。現如今，基於Big Data海量數據的基礎上 ，已經在逐步過渡到大數據實時計算分析的Fast Data時代了。Fast Data在數據量的基礎上，意味著速度和變化，意味著客戶可以更加實時化、更加快速地進行數據處理。
最終演變成為當前最熱門的微服務、容器、Fast Data架構。
下一篇：架構微服務階段
