應用架構學習

1. 最簡單架構

剛開始應用沒有太多訪問量，所以只需要一台服務器

場景探討
隨著應用的業務越來越複雜，應用訪問量越來越大，導致性能越來越差，存儲空間嚴重不足

架構概念
這時候我們考慮把服務增加到三台(能通過加機器解決的問題都不是問題);分離出應用服務器、數據庫服務器、文件服務器。

架構問題探討
根據每個服務器對應的場景，配置服務器後應用的性能能夠大大提高，更好的支持業務的發展。但是隨之業務的發展，訪問量的增大，這種架構又將再次面臨挑戰，應用服務器處理能力下降，存儲空間不足。

場景探討
在高併發大流量的情況下，一台服務器是肯定處理不過來的

架構概念
這個時候增加服務器，部署集群提供服務，來分擔每台服務器的壓力，部署集群的另一個好處是可伸縮性，比如當遇到了雙11大流量的場景下，可以增加服務器分攤流量，等雙11過後，減少服務器節約成本。架構如下：

如果應用服務器是tomcat，那麼可以部署一個tomcat的集群，外部再部署一個負載均衡器，可以採用隨機、輪詢、一致性合希演算法將用戶的請求分發到不同應用服務集群;通常選擇免費的負載均衡是nginx。在這種架構下，應用服務器的負載將不會是整個應用的瓶頸點。

架構問題探討
雖然應用程序的處理速度在這種架構下提升了許多，但是又會暴露一個問題，數據庫的壓力大大增加，導致訪問響應延遲，影響整個應用的性能。

這種架構還有個問題，通常應用是有狀態的，需要記錄用戶的登錄信息，如果每次用戶的請求都是隨機路由到後端的應用服務器，那麼用戶的會話(session)將會丟失;

架構問題-解決方案

這邊我覺得可以後續再接上看nginx 跟一口氣說出4種分布式一致性session 實現方式。

場景探討
根據二八原則，80%的業務都是集中訪問20%的數據，這20%的數據通常稱為熱點數據，但是這20%的數據占用的內存也不會小，如果每個應用服務器都存放一份，有些浪費存儲空間

架構概念
所以這時候需要考慮加入分布式緩存服務器(常用的是Redis);當引入了分布式緩存服務器，再來看上面那個方案的問題，就可以解決了，把用戶的會話存放到緩存服務器，不僅可以防止用戶數據丟失，效率也不低;架構圖如下：

由於分布式緩存服務器畢竟存放在遠程，需要經過網路，所以取數據還是要花一點時間;地本緩存訪問速度更快，但是內存空間有限，並且還會出現和應用程序爭搶資源;所以這種架構搭配了分布式緩存和本地緩存，本地緩存存放少量常用熱點數據，當本地緩存中沒有命中時再去集中式緩存取。

在引進緩存之後，數據庫的訪問壓力可以得到一定的緩解。

場景探討
雖然在加入了緩存之後，部分數據可以直接走緩存，不需要訪問數據庫，但是仍然會有一些請求，會訪問數據庫，比如：緩存失效，緩存未命中;當流量大的時候，數據庫的訪問量也不小，這時候我們需要考慮搭建數據庫集群，讀寫分離。

架構概念
當應用服務器有寫操作時，訪問主庫，當應用程序有讀操作時，訪問從庫;大多數的應用都是讀的操作遠遠大於寫的操作，所以可以配置數據庫一主多從來分擔數據庫的壓力;為了讓應用程序對應主庫和從庫無感知，通常需要引入一些讀寫分離的框架做一個統一的數據訪問模塊。

架構問題探討
這種架構通常需要警惕的一個問題是主從延遲，當在高併發的場景下，主庫剛寫成功，數據庫還未成功同步完從庫，這時候另一個請求進入讀取數據發現不存在;

架構問題-解決方案
在應用程序中高併發的場景下設置強制走主庫查詢。

如何確認目前是高併發的場景??

筆記整理：技術架構涵蓋內容和演變過程總結