原文轉自: https://www.cnblogs.com/Survivalist/p/8012266.html 隨筆：最近再做這些年的知識整理，今天整理到了架構這方便，就索性拿出來和大家分享一下，有什麼寫錯的，歡迎大家指正 架構拆分的演變： 1.傳統項目的架構：特點： 1.all in one(所 ...
原文轉自: https://www.cnblogs.com/Survivalist/p/8012266.html
隨筆：最近再做這些年的知識整理，今天整理到了架構這方便，就索性拿出來和大家分享一下，有什麼寫錯的，歡迎大家指正
架構拆分的演變：
1.傳統項目的架構：
特點：
1.all in one(所有模塊在一起，技術也不分層)，
註：像05年06年那會兒，就是這樣，把代碼寫在jsp裡面，那時候還沒有分層的概念，把所有的東西都寫在一起，這就叫做all in one
2.servlet(jsp)
缺點：
1.併發量差
2.容錯性差(不具有高可用性)
註：不具有高可用性的意思是，比如當用戶訪問時，伺服器後臺因為一些原因導致伺服器崩潰，用戶就能直接看到錯誤頁面，伺服器也因為錯誤從而停止運行(宕機)，這就叫做不具有高可用性。
解決方案：
1.分層開發(可以提高併發量)
2.mvc架構
3.伺服器的分離部署
用圖說話：
集群的配置：
集群架構：
特點：
1.項目採用多台伺服器集群部署
2.mysql資料庫採用多台伺服器集群部署
優勢：
1.併發量提高(1000+)
2.容錯性提高(具有高可用性)
註：一般的it公司，基本都是採用集群架構，因為這種架構方式已經基本能滿足需求了，但是一些大型項目，這種方式就顯然是力不從心了，只能採用分散式的架構方式
但是，通過上圖我們發現這種集群部署存在兩個問題，什麼問題呢？
1.session如何共用？
2.這麼伺服器，請求該往哪發送？
下麵咱們就針對這兩個問題一一解答：
首先第一個問題，session的問題：
我們都知道，session是會話，即一個用戶訪問伺服器的時候，就會產生一個session，這個session會一致伴隨著這個用戶的訪問全程，直到用戶關閉瀏覽器結束這次會話，那麼問題來了，問，挖掘技術哪家強？咳咳，錯了，是如果用戶訪問伺服器時，這台服
務器掛掉了(宕機)，那麼原先保存在這台伺服器上的session也肯定掛掉了，那麼就會產生一個後果，就是這個用戶原本訪問好好的，現在突然session沒有了，而session沒有了就意味著需要用戶重新登陸才能進行一些相應操作，這顯然是不行的，這樣的服務用戶
體驗實在太差了，根本不能滿足互聯網行業的用戶需求，那麼這就涉及到一個session共用的問題，即怎麼把原有的session從一臺伺服器轉移到另一臺伺服器上，但是怎麼解決呢？有多種方案，但咱們今天先說兩種：
第一種解決方案：
用Tomcat集群複製(廣播模式)來共用session：
這種解決方案是利用Tomcat來進行集群複製，把每個伺服器上的session都共用式的都複製一遍，保證每個伺服器上都有著一個用戶的session數據
應用場景：在傳統項目中一般這麼應用，因為傳統項目的用戶量少，可以承擔壓力，但當到互聯網項目時，這種方式就絕對不可取了，打個比方，比如用戶量有100萬，那麼就需要在每個伺服器上都複製這100萬個用戶的session，這樣做顯然會極大的消耗系統資源，使系統變得極為臃腫和不穩的，所以在互聯網項目里是絕對不會採用這種方式的
缺點：當有大量用戶時，伺服器的壓力會亞歷山大，所以只適合用戶訪問量小的傳統項目
第二種解決方案：
用第三方redis伺服器來存儲session
用這種方式來存儲session的話，只需當前正在使用的項目把所有session都放在redis裡面，當有其他項目需要使用時，就可以直接從redis中直接獲取session，從而解決了這個問題
示例如圖：
現在第一個問題解決了，我們來考慮第二個問題，怎麼解決選擇哪個作為解釋請求的伺服器呢？
答案是：用nginx伺服器來分發請求，實現負載均衡。
這種架構的併發量是多少呢？大概是1000+左右，如果伺服器更多的話，能達到1000以上，一萬以下，但是這能滿足互聯網的極致要求呢？答案當然是不能了，雖說也可以不斷的擴展伺服器，但是對於公司的成本和維護成本來說，無疑會達到一個非常高昂的
消耗，比如說一臺最便宜的伺服器的價格大概是3到5萬，假如要抵禦一萬的併發，每台伺服器能支持200的併發率，那麼需要多少台伺服器？50台！這還僅是單擊版的，還構建集群呢？比如說構建3台伺服器，3*50=150台，伺服器構建完了，資料庫呢？資料庫也需
要構建集群呀！，這就又是好幾百台，這麼一算下來大概的費用就是好幾百萬了，這僅僅是配置的費用，還沒有計算維護的成本呢？比如說我們都知道伺服器對於機房的要求是非常苛刻的，比如恆溫，無塵等等(題外話：阿裡之所以把雲計算基地定在杭州就是看中了
那裡氣溫穩定，適合佈置伺服器集群)。這樣一來又需要佈置大型的機房，綜合以上所述，雖說集群能後解決部分問題，但並不能解決所有問題，無論是從公司成本還是運營成本來說，顯然這種傳統的集群架構是不適應現在的互聯網行業的，而且對於一般的公司來說也不可能去花大價錢做這種佈置。
所以，這種情況下我們就必須對我們的架構來進行優化了，那麼如何在伺服器只有一定數量的情況下，讓我們的項目的成本能達到一定控制，並且讓我們的項目達到一個最優化的併發的訪問量呢？那麼就需要對現有的這種架構進行再次拆分，讓我們的項目成為面向服務的分散式架構。
面向服務的分散式架構(SOA)：
遠程框架：
1.webservice
如圖所示，第一種方式還是有著明顯的缺點的，如服務層的網路抖動或是服務層進程繁忙，可能有人對這兩個名詞不太理解，這裡就解釋一下：
網路抖動：當有大量用戶訪問時，可能會出現service層的延遲現象，而web層因為長期得不到響應，則會拋出時間超出異常
進程繁忙：這個的意思和前邊的差不多，都是指service層業務太多，顧不上web層的請求，web層的請求就只能一直在那等著，時間長了也就拋出超時異常了
服務治理中間件：
2.dubbo
原理講解：看了第一種webservice的方法之後，我們採用了第二種方法，即dubbo這種中間件的方式，採用這種方式有什麼好處呢？
好處：
當伺服器啟動時service會把所有的對象通過dubbo註冊給zookeeper，而以後每次需要請求獲取對象時，就可以直接從dubbo中非同步獲取，不需要再去訪問service層，這樣就解決了
服務層網路抖動和服務層進程繁忙的弊端。zeekeeper可以看成是一個資料庫，用來存儲數據的，具體的原理以後會專門開篇文章描述它。
這種方式是目前最常用的，起碼是我最常用的，順嘴一提，dubbo是阿裡巴巴開發的一款中間件，性能強大，而且這是由中國人自主開發的軟體，有木有很自豪
3.springcloud
這個軟體是由外國開發，原理和dubbo差不太，就暫且不提了，有興趣的可以自己百度一下
下麵我們來總結一下分散式框架的優點：
優點：
1.大幅提高併發訪問量(10000+)
2.可以節省成本(因為這種優化僅是從架構方面進行優化，而不需要去配置大量的伺服器)
3.實現了服務層與表現層的解耦合
註：1.其實還有一種方式，即是提升帶寬，把帶寬搞多一點，但前提是伺服器能承受這麼大的量。
2.集群也不是越多越好的，越多的話就會發現，其實併發的提升是有限的。
總結：說道這裡就基本已經講解了架構的發展歷史，當然現在目前還有一種比分散式更火的架構模式，叫做微架構，它是通過服務的原子化拆分，以及微服務的獨立打包、部署和升級，可以讓小團隊的交付周期將縮短，運維成本也將大幅度下降，可以預見，這種架構模式將會越來越受到廣大企業的應用與喜愛，但由於筆者功力有限，目前也還是在學習瞭解階段，就不在這裡獻醜了。(本文寫的比較淺顯，如有寫錯寫漏處，歡迎指正！謝謝觀看！)
