隨筆：最近再做這些年的知識整理，今天整理到了架構這方便，就索性拿出來和大家分享一下，有什么寫錯的，歡迎大家指正
架構拆分的演變：
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.集群也不是越多越好的，越多的話就會發現，其實並發的提升是有限的。
總結：說道這里就基本已經講解了架構的發展歷史，當然現在目前還有一種比分布式更火的架構模式，叫做微架構，它是通過服務的原子化拆分，以及微服務的獨立打包、部署和升級，可以讓小團隊的交付周期將縮短，運維成本也將大幅度下降，可以預見，這
種架構模式將會越來越受到廣大企業的應用與喜愛，但由於筆者功力有限，目前也還是在學習了解階段，就不在這里獻丑了。(本文寫的比較淺顯，如有寫錯寫漏處，歡迎指正！謝謝觀看！)