淺談架構-從傳統走向分散式

隨筆：最近再做這些年的知識整理，今天整理到了架構這方便，就索性拿出來和大家分享一下，有什麼寫錯的，歡迎大家指正

架構拆分的演變：
　　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.叢集也不是越多越好的，越多的話就會發現，其實併發的提升是有限的。

 　　　　總結：說道這裡就基本已經講解了架構的發展歷史，當然現在目前還有一種比分散式更火的架構模式，叫做微架構，它是通過服務的原子化拆分，以及微服務的獨立打包、部署和升級，可以讓小團隊的交付週期將縮短，運維成本也將大幅度下降，可以預見，這

　　　　　　　 種架構模式將會越來越受到廣大企業的應用與喜愛，但由於筆者功力有限，目前也還是在學習瞭解階段，就不在這裡獻醜了。(本文寫的比較淺顯，如有寫錯寫漏處，歡迎指正！謝謝觀看！)