喬幫主的直播内容經精煉整理、分以下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架構。
下一篇：架構微服務階段