文章很長，建議收藏起來，慢慢讀! 備注：持續更新中.....
- 瘋狂創客圈 經典圖書 ： 《Netty Zookeeper Redis 高並發實戰》 面試必備 + 大廠必備 + 漲薪必備
- 瘋狂創客圈 經典圖書 ： 《SpringCloud、Nginx高並發核心編程》 面試必備 + 大廠必備 + 漲薪必備
- 瘋狂創客圈 價值1000元 百度網盤資源大禮包，免費拿 【博客園總入口 】
價值連城：2021春招月薪過5萬 面試題 總系列
| 搞定下面這些面試題，2021春招月薪過5萬(猛！) | 阿里、京東、美團、頭條.... 隨意挑、橫着走！！！ |
|---|---|
| Java基礎 | |
| 1： JVM面試題（史上最強、持續更新、吐血推薦） | https://www.cnblogs.com/crazymakercircle/p/14365820.html |
| 2：Java基礎面試題（史上最全、持續更新、吐血推薦） | https://www.cnblogs.com/crazymakercircle/p/14366081.html |
| 3：死鎖面試題（史上最強、持續更新） | [https://www.cnblogs.com/crazymakercircle/p/14323919.html] |
| 4：設計模式面試題 （史上最全、持續更新、吐血推薦） | https://www.cnblogs.com/crazymakercircle/p/14367101.html |
| 5：架構設計面試題 （史上最全、持續更新、吐血推薦） | https://www.cnblogs.com/crazymakercircle/p/14367907.html |
| 還有 10 幾篇 篇價值連城 的面試題 | 具體..... 請參見【 瘋狂創客圈 高並發 總目錄 】 |
萬字長文： 瘋狂創客圈 springCloud 高並發系列
| springCloud 高質量 博文 | |
|---|---|
| nacos 實戰（史上最全） | sentinel （史上最全+入門教程） |
| springcloud + webflux 高並發實戰 | Webflux（史上最全） |
| SpringCloud gateway （史上最全） | |
| 還有 10 幾篇 萬字長文 的高質量 博文 | 具體..... 請參見【 瘋狂創客圈 高並發 總目錄 】 |
SpringCloud + Nginx高並發基本概念
在介紹架構之前，為了避免部分讀者對架構設計中的一些概念不了解，下面對幾個最基礎的概念進行介紹。
1）什么是分布式？
系統中的多個模塊在不同服務器上部署，即可稱為分布式系統，如Tomcat和數據庫分別部署在不同的服務器上，或兩個相同功能的Tomcat分別部署在不同服務器上。
2）什么是高可用？
系統中部分節點失效時，其他節點能夠接替它繼續提供服務，則可認為系統具有高可用性。
3）什么是集群？
一個特定領域的軟件部署在多台服務器上並作為一個整體提供一類服務，這個整體稱為集群。
如Zookeeper中的Master和Slave分別部署在多台服務器上，共同組成一個整體提供集中配置服務。
在常見的集群中，客戶端往往能夠連接任意一個節點獲得服務，並且當集群中一個節點掉線時，其他節點往往能夠自動的接替它繼續提供服務，這時候說明集群具有高可用性。
4）什么是負載均衡？
請求發送到系統時，通過某些方式把請求均勻分發到多個節點上，使系統中每個節點能夠均勻的處理請求負載，則可認為系統是負載均衡的。
5）什么是正向代理和反向代理？
系統內部要訪問外部網絡時，統一通過一個代理服務器把請求轉發出去，在外部網絡看來就是代理服務器發起的訪問，此時代理服務器實現的是正向代理；
當外部請求進入系統時，代理服務器把該請求轉發到系統中的某台服務器上，對外部請求來說，與之交互的只有代理服務器，此時代理服務器實現的是反向代理。
簡單來說，正向代理是代理服務器代替系統內部來訪問外部網絡的過程，反向代理是外部請求訪問系統時通過代理服務器轉發到內部服務器的過程。
架構演進：單機架構
在網站最初時，應用數量與用戶數都較少，可以把Tomcat和數據庫部署在同一台服務器上。
瀏覽器往發起請求時，首先經過DNS服務器（域名系統）把域名轉換為實際IP地址10.102.4.1，瀏覽器轉而訪問該IP對應的Tomcat。
架構瓶頸：隨着用戶數的增長，Tomcat和數據庫之間競爭資源，單機性能不足以支撐業務。
架構演進：Tomcat與數據庫分開部署
Tomcat和數據庫分別獨占服務器資源，顯著提高兩者各自性能。
架構瓶頸：隨着用戶數的增長，並發讀寫數據庫成為瓶頸。
架構演進：引入本地緩存和分布式緩存
在Tomcat同服務器上或同JVM中增加本地緩存，並在外部增加分布式緩存，緩存熱門商品信息或熱門商品的html頁面等。通過緩存能把絕大多數請求在讀寫數據庫前攔截掉，大大降低數據庫壓力。
其中涉及的技術包括：使用memcached作為本地緩存，使用Redis作為分布式緩存，還會涉及緩存一致性、緩存穿透/擊穿、緩存雪崩、熱點數據集中失效等問題。
架構瓶頸：緩存抗住了大部分的訪問請求，隨着用戶數的增長，並發壓力主要落在單機的Tomcat上，響應逐漸變慢。
架構演進：引入反向代理實現接入層負載均衡
在多台服務器上分別部署Tomcat，使用反向代理軟件（Nginx）把請求均勻分發到每個Tomcat中。
此處假設Tomcat最多支持100個並發，Nginx最多支持50000個並發，那么理論上Nginx把請求分發到500個Tomcat上，就能抗住50000個並發。
其中涉及的技術包括：Nginx、HAProxy，兩者都是工作在網絡第七層的反向代理軟件，主要支持http協議，還會涉及session共享、文件上傳下載的問題。
架構瓶頸：反向代理使應用服務器可支持的並發量大大增加，但並發量的增長也意味着更多請求穿透到數據庫，單機的數據庫最終成為瓶頸。
架構演進：數據庫讀寫分離
把數據庫划分為讀庫和寫庫，讀庫可以有多個，通過同步機制把寫庫的數據同步到讀庫，對於需要查詢最新寫入數據場景，可通過在緩存中多寫一份，通過緩存獲得最新數據。
其中涉及的技術包括：Mycat，它是數據庫中間件，可通過它來組織數據庫的分離讀寫和分庫分表，客戶端通過它來訪問下層數據庫，還會涉及數據同步，數據一致性的問題。
架構瓶頸：業務逐漸變多，不同業務之間的訪問量差距較大，不同業務直接競爭數據庫，相互影響性能。
架構演進：數據庫按業務分庫
把不同業務的數據保存到不同的數據庫中，使業務之間的資源競爭降低，對於訪問量大的業務，可以部署更多的服務器來支撐。
這樣同時導致跨業務的表無法直接做關聯分析，需要通過其他途徑來解決，但這不是本文討論的重點，有興趣的可以自行搜索解決方案。
架構瓶頸：隨着用戶數的增長，單機的寫庫會逐漸會達到性能瓶頸。
架構演進：把大表拆分為小表
比如針對評論數據，可按照商品ID進行hash，路由到對應的表中存儲；
針對支付記錄，可按照小時創建表，每個小時表繼續拆分為小表，使用用戶ID或記錄編號來路由數據。
只要實時操作的表數據量足夠小，請求能夠足夠均勻的分發到多台服務器上的小表，那數據庫就能通過水平擴展的方式來提高性能。其中前面提到的Mycat也支持在大表拆分為小表情況下的訪問控制。
這種做法顯著的增加了數據庫運維的難度，對DBA的要求較高。數據庫設計到這種結構時，已經可以稱為分布式數據庫
但這只是一個邏輯的數據庫整體，數據庫里不同的組成部分是由不同的組件單獨來實現的
如分庫分表的管理和請求分發，由Mycat實現，SQL的解析由單機的數據庫實現，讀寫分離可能由網關和消息隊列來實現，查詢結果的匯總可能由數據庫接口層來實現等等
這種架構其實是MPP（大規模並行處理）架構的一類實現。
目前開源和商用都已經有不少MPP數據庫，開源中比較流行的有Greenplum、TiDB、Postgresql XC、HAWQ等，商用的如南大通用的GBase、睿帆科技的雪球DB、華為的LibrA等等
不同的MPP數據庫的側重點也不一樣，如TiDB更側重於分布式OLTP場景，Greenplum更側重於分布式OLAP場景
這些MPP數據庫基本都提供了類似Postgresql、Oracle、MySQL那樣的SQL標准支持能力，能把一個查詢解析為分布式的執行計划分發到每台機器上並行執行，最終由數據庫本身匯總數據進行返回
也提供了諸如權限管理、分庫分表、事務、數據副本等能力，並且大多能夠支持100個節點以上的集群，大大降低了數據庫運維的成本，並且使數據庫也能夠實現水平擴展。
架構瓶頸：數據庫和Tomcat都能夠水平擴展，可支撐的並發大幅提高，隨着用戶數的增長，最終單機的Nginx會成為瓶頸。
架構演進：使用LVS或F5接入層負載均衡
由於瓶頸在Nginx，因此無法通過兩層的Nginx來實現多個Nginx的負載均衡。
圖中的LVS和F5是工作在網絡第四層的負載均衡解決方案，其中LVS是軟件，運行在操作系統內核態，可對TCP請求或更高層級的網絡協議進行轉發，因此支持的協議更豐富，並且性能也遠高於Nginx，可假設單機的LVS可支持幾十萬個並發的請求轉發；
F5是一種負載均衡硬件，與LVS提供的能力類似，性能比LVS更高，但價格昂貴。
由於LVS是單機版的軟件，若LVS所在服務器宕機則會導致整個后端系統都無法訪問，因此需要有備用節點。
可使用keepalived軟件模擬出虛擬IP，然后把虛擬IP綁定到多台LVS服務器上，瀏覽器訪問虛擬IP時，會被路由器重定向到真實的LVS服務器
當主LVS服務器宕機時，keepalived軟件會自動更新路由器中的路由表，把虛擬IP重定向到另外一台正常的LVS服務器，從而達到LVS服務器高可用的效果。
此處需要注意的是，上圖中從Nginx層到Tomcat層這樣畫並不代表全部Nginx都轉發請求到全部的Tomcat
在實際使用時，可能會是幾個Nginx下面接一部分的Tomcat，這些Nginx之間通過keepalived實現高可用，其他的Nginx接另外的Tomcat，這樣可接入的Tomcat數量就能成倍的增加。
架構瓶頸：由於LVS也是單機的，隨着並發數增長到幾十萬時，LVS服務器最終會達到瓶頸，此時用戶數達到千萬甚至上億級別，用戶分布在不同的地區，與服務器機房距離不同，導致了訪問的延遲會明顯不同。
架構演進：通過DNS輪詢實現機房間的負載均衡
在DNS服務器中可配置一個域名對應多個IP地址，每個IP地址對應到不同的機房里的虛擬IP。
當用戶訪問taobao時，DNS服務器會使用輪詢策略或其他策略，來選擇某個IP供用戶訪問。此方式能實現機房間的負載均衡
至此，系統可做到機房級別的水平擴展，千萬級到億級的並發量都可通過增加機房來解決，系統入口處的請求並發量不再是問題。
架構瓶頸：隨着數據的豐富程度和業務的發展，檢索、分析等需求越來越豐富，單單依靠數據庫無法解決如此豐富的需求。
架構演進：引入NoSQL數據庫和搜索引擎等技術
當數據庫中的數據多到一定規模時，數據庫就不適用於復雜的查詢了，往往只能滿足普通查詢的場景。
對於統計報表場景，在數據量大時不一定能跑出結果，而且在跑復雜查詢時會導致其他查詢變慢
對於全文檢索、可變數據結構等場景，數據庫天生不適用。因此需要針對特定的場景，引入合適的解決方案。
如對於海量文件存儲，可通過分布式文件系統HDFS解決，對於key value類型的數據，可通過HBase和Redis等方案解決
對於全文檢索場景，可通過搜索引擎如ElasticSearch解決，對於多維分析場景，可通過Kylin或Druid等方案解決。
當然，引入更多組件同時會提高系統的復雜度，不同的組件保存的數據需要同步，需要考慮一致性的問題，需要有更多的運維手段來管理這些組件等。
架構瓶頸：引入更多組件解決了豐富的需求，業務維度能夠極大擴充，隨之而來的是一個應用中包含了太多的業務代碼，業務的升級迭代變得困難。
架構演進：大應用拆分為小應用
按照業務板塊來划分應用代碼，使單個應用的職責更清晰，相互之間可以做到獨立升級迭代。這時候應用之間可能會涉及到一些公共配置，可以通過分布式配置中心Zookeeper來解決。
架構瓶頸：不同應用之間存在共用的模塊，由應用單獨管理會導致相同代碼存在多份，導致公共功能升級時全部應用代碼都要跟着升級。
架構演進：復用的功能抽離成微服務
如用戶管理、訂單、支付、鑒權等功能在多個應用中都存在，那么可以把這些功能的代碼單獨抽取出來形成一個單獨的服務來管理
這樣的服務就是所謂的微服務，應用和服務之間通過HTTP、TCP或RPC請求等多種方式來訪問公共服務，每個單獨的服務都可以由單獨的團隊來管理。
此外，可以通過Dubbo、SpringCloud等框架實現服務治理、限流、熔斷、降級等功能，提高服務的穩定性和可用性。
架構瓶頸：不同服務的接口訪問方式不同，應用代碼需要適配多種訪問方式才能使用服務，此外，應用訪問服務，服務之間也可能相互訪問，調用鏈將會變得非常復雜，邏輯變得混亂。
架構演進：引入企業服務總線ESB屏蔽服務接口的訪問差異
通過ESB統一進行訪問協議轉換，應用統一通過ESB來訪問后端服務，服務與服務之間也通過ESB來相互調用，以此降低系統的耦合程度。
這種單個應用拆分為多個應用，公共服務單獨抽取出來來管理，並使用企業消息總線來解除服務之間耦合問題的架構，就是所謂的SOA（面向服務）架構，這種架構與微服務架構容易混淆，因為表現形式十分相似。
個人理解，微服務架構更多是指把系統里的公共服務抽取出來單獨運維管理的思想，而SOA架構則是指一種拆分服務並使服務接口訪問變得統一的架構思想，SOA架構中包含了微服務的思想。
架構瓶頸：業務不斷發展，應用和服務都會不斷變多，應用和服務的部署變得復雜，同一台服務器上部署多個服務還要解決運行環境沖突的問題
此外，對於如大促這類需要動態擴縮容的場景，需要水平擴展服務的性能，就需要在新增的服務上准備運行環境，部署服務等，運維將變得十分困難。
架構演進：引入容器化技術實現運行環境隔離與動態服務管理
目前最流行的容器化技術是Docker，最流行的容器管理服務是Kubernetes(K8S)，應用/服務可以打包為Docker鏡像，通過K8S來動態分發和部署鏡像。
Docker鏡像可理解為一個能運行你的應用/服務的最小的操作系統，里面放着應用/服務的運行代碼，運行環境根據實際的需要設置好。
把整個“操作系統”打包為一個鏡像后，就可以分發到需要部署相關服務的機器上，直接啟動Docker鏡像就可以把服務起起來，使服務的部署和運維變得簡單。
在大促的之前，可以在現有的機器集群上划分出服務器來啟動Docker鏡像，增強服務的性能
大促過后就可以關閉鏡像，對機器上的其他服務不造成影響（在第18節之前，服務運行在新增機器上需要修改系統配置來適配服務，這會導致機器上其他服務需要的運行環境被破壞）。
架構瓶頸：使用容器化技術后服務動態擴縮容問題得以解決，但是機器還是需要公司自身來管理，在非大促的時候，還是需要閑置着大量的機器資源來應對大促，機器自身成本和運維成本都極高，資源利用率低。
架構演進：以雲平台承載系統
系統可部署到公有雲上，利用公有雲的海量機器資源，解決動態硬件資源的問題
在大促的時間段里，在雲平台中臨時申請更多的資源，結合Docker和K8S來快速部署服務，在大促結束后釋放資源，真正做到按需付費，資源利用率大大提高，同時大大降低了運維成本。
所謂的雲平台，就是把海量機器資源，通過統一的資源管理，抽象為一個資源整體
在雲平台上可按需動態申請硬件資源（如CPU、內存、網絡等），並且之上提供通用的操作系統，提供常用的技術組件（如Hadoop技術棧，MPP數據庫等）供用戶使用，甚至提供開發好的應用
用戶不需要關心應用內部使用了什么技術，就能夠解決需求（如音視頻轉碼服務、郵件服務、個人博客等）。
在雲平台中會涉及如下幾個概念：
IaaS：基礎設施即服務。對應於上面所說的機器資源統一為資源整體，可動態申請硬件資源的層面；
PaaS：平台即服務。對應於上面所說的提供常用的技術組件方便系統的開發和維護；
SaaS：軟件即服務。對應於上面所說的提供開發好的應用或服務，按功能或性能要求付費。
至此：以上所提到的從高並發訪問問題，到服務的架構和系統實施的層面都有了各自的解決方案。
總結
不敢抄襲他人成果，本文作為架構演進的筆記，內容主要來自於文章，淘寶雙11，億級流量高並發是怎么抗住的？看完這篇你就明白了!
此文主要目的，是進行架構交流。 如果侵權，請留言告知，這里立即刪除。
通過以上架構的演進，可以看出：
（1）開發側使用 SpringCloud+Nginx 的基礎架構；
（2）運維側通過引入DNS層負載均衡、接入層負載均衡、容器化和雲平台等運維技術
應對億級流量，基本沒有問題。
回到◀瘋狂創客圈▶
瘋狂創客圈 - Java高並發研習社群，為大家開啟大廠之門