架構拆分的演變：
1.傳統項目的架構：
特點：
1) all in one(所有子產品在一起，技術也不分層)，
注：像05年06年那會兒，就是這樣，把代碼寫在jsp裡面，那時候還沒有分層的概念，把所有的東西都寫在一起，這就叫做all in one
2) servlet(jsp)
缺點：
- 并發量差
- 容錯性差(不具有高可用性)
注：不具有高可用性的意思是，比如當使用者通路時，伺服器背景因為一些原因導緻伺服器崩潰，使用者就能直接看到錯誤頁面，伺服器也因為錯誤進而停止運作(當機)，這就叫做不具有高可用性。
解決方案：
1.分層開發(可以提高并發量)
2.mvc架構
3.伺服器的分離部署
用圖說話：
叢集的配置：
叢集架構：
特點：
1.項目采用多台伺服器叢集部署
2.mysql資料庫采用多台伺服器叢集部署
優勢：
1.并發量提高(1000+)
2.容錯性提高(具有高可用性)
注：一般的it公司，基本都是采用叢集架構，因為這種架構方式已經基本能滿足需求了，但是一些大型項目，這種方式就顯然是力不從心了，隻能采用分布式的架構方式
問題
但是，通過上圖我們發現這種叢集部署存在兩個問題，什麼問題呢？
1.session如何共享？
2.這麼伺服器，請求該往哪發送？
下面咱們就針對這兩個問題一一解答：
session共享問題
首先第一個問題，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)：
遠端架構：
webservice
如圖所示，第一種方式還是有着明顯的缺點的，如服務層的網路抖動或是服務層程序繁忙，可能有人對這兩個名詞不太了解，這裡就解釋一下：
網絡抖動：當有大量使用者通路時，可能會出現service層的延遲現象，而web層因為長期得不到響應，則會抛出時間超出異常
程序繁忙：這個的意思和前邊的差不多，都是指service層業務太多，顧不上web層的請求，web層的請求就隻能一直在那等着，時間長了也就抛出逾時異常了
服務治理中間件：
dubbo
原理講解：看了第一種webservice的方法之後，我們采用了第二種方法，即dubbo這種中間件的方式，采用這種方式有什麼好處呢？
好處：
當伺服器啟動時service會把所有的對象通過dubbo注冊給zookeeper，而以後每次需要請求擷取對象時，就可以直接從dubbo中異步擷取，不需要再去通路service層，這樣就解決了
服務層網絡抖動和服務層程序繁忙的弊端。zeekeeper可以看成是一個資料庫，用來存儲資料的，具體的原理以後會專門開篇文章描述它。
這種方式是目前最常用的，起碼是我最常用的，順嘴一提，dubbo是阿裡巴巴開發的一款中間件，性能強大，而且這是由中國人自主開發的軟體，有木有很自豪
springcloud
這個軟體是由外國開發，原理和dubbo差不太，就暫且不提了，有興趣的可以自己百度一下
下面我們來總結一下分布式架構的優點：
優點：
1.大幅提高并發通路量(10000+)
2.可以節省成本(因為這種優化僅是從架構方面進行優化，而不需要去配置大量的伺服器)
3.實作了服務層與表現層的解耦合
注：1.其實還有一種方式，即是提升帶寬，把帶寬搞多一點，但前提是伺服器能承受這麼大的量。
2.叢集也不是越多越好的，越多的話就會發現，其實并發的提升是有限的。
總結：說道這裡就基本已經講解了架構的發展曆史，當然現在目前還有一種比分布式更火的架構模式，叫做微架構，它是通過服務的原子化拆分，以及微服務的獨立打包、部署和更新，可以讓小團隊的傳遞周期将縮短，運維成本也将大幅度下降。