本文引用了阿豪的微信公眾號文章分享，感謝原作者的分享。

1、前言

隨著社會的發(fā)展、互聯(lián)網(wǎng)技術(shù)的進步，以前的大型機服務端架構(gòu)很顯然由于高成本、難維護等原因漸漸地變得不再那么主流了，替代它的就是當下最火的互聯(lián)網(wǎng)分布式架構(gòu)。

從若干年前大行其道的傳統(tǒng)大型機到如今的分布式架構(gòu)，技術(shù)發(fā)展已經(jīng)經(jīng)歷了好幾個階段，我們只有弄明白典型互聯(lián)網(wǎng)架構(gòu)在各個階段的演進，才能更好地理解和體會分布式架構(gòu)的好處，從而有助于我們序設計適合于自已公司、產(chǎn)品或項目的架構(gòu)（也包括設計即時通訊網(wǎng)專注的IM和消息推送這類系統(tǒng)，因為技術(shù)思路的原理都是一脈相承的）。那么本文我們就來聊聊分布式架構(gòu)的演進過程，希望能給大家?guī)硌矍耙涣恋母杏X。

點評：即時通訊網(wǎng)作為IM和推送技術(shù)研究、學習和分享的社區(qū)，整理了大量的跟IM和推廣技術(shù)有關(guān)的基礎(chǔ)技術(shù)資料（比如網(wǎng)絡基礎(chǔ)、通信理論、架構(gòu)基礎(chǔ)等），本文內(nèi)容雖然看起來跟IM和推送技術(shù)沒有直接的關(guān)聯(lián)性，但因為設計IM和推送系統(tǒng)的技術(shù)思路和原理跟典型大型互聯(lián)網(wǎng)分布式架構(gòu)都是一脈相承的，因而讀懂本文內(nèi)容對于IM和推送系統(tǒng)的架構(gòu)設計同樣大有裨益。

學習交流：

- 即時通訊開發(fā)交流3群：185926912[推薦]

- 移動端IM開發(fā)入門文章：《新手入門一篇就夠：從零開發(fā)移動端IM》

（本文同步發(fā)布于：http://www.52im.net/thread-2007-1-1.html）

2、相關(guān)文章

如果你已完全掌握本文的相關(guān)知識，請移步繼續(xù)閱讀即時通訊網(wǎng)整理的另一篇：《騰訊資深架構(gòu)師干貨總結(jié)：一文讀懂大型分布式系統(tǒng)設計的方方面面》，該文適合對互聯(lián)網(wǎng)架構(gòu)知識有一定了解的程序員閱讀和學習，都是不可能多得的技術(shù)干貨。

3、技術(shù)背景說明

我們都知道一個成熟的大型網(wǎng)站的系統(tǒng)架構(gòu)并非一開始就設計的非常完美，也沒有一開始就具備高性能、高并發(fā)、高可用、安全性等特性，而是隨著用戶量的增加、業(yè)務功能的擴展逐步演變過來的，慢慢的完善的。 在這個過程中，開發(fā)模式、技術(shù)架構(gòu)等都會隨著迭代發(fā)生非常大的變化。 而針對不同業(yè)務特征的系統(tǒng)，各自都會有自己的側(cè)重點，例如像淘寶這類的網(wǎng)站，要解決的重點問題就是海量商品搜索、下單、支付等問題; 像騰訊這類的網(wǎng)站，要解決的是數(shù)億級別用戶的實時消息傳輸;而像百度這類的公司所要解決的又是海量數(shù)據(jù)的搜索。每一個種類的業(yè)務都有自己不同的系統(tǒng)架構(gòu)。

為了方便展開本文要講解的內(nèi)容，我們來簡單模擬一個架構(gòu)演變過程： 我們以 javaweb 為例，來搭建一個簡單的電商系統(tǒng)，從這個系統(tǒng)中來看系統(tǒng)的演變過程。要注意的是接下來的演示模型， 關(guān)注的是數(shù)據(jù)量、訪問量提升，網(wǎng)站結(jié)構(gòu)的變化， 而不關(guān)注具體業(yè)務的功能點。其次，這個過程是為了讓大家能更好的了解網(wǎng)站演進過程中的一些問題和應對策略。

假如我們要設計的互聯(lián)網(wǎng)系統(tǒng)需要具備以下功能:

1）用戶模塊：用戶注冊和管理；

2）商品模塊:商品展示和管理；

3）交易模塊:創(chuàng)建交易及支付結(jié)算。

請帶著上述3個技術(shù)點，繼續(xù)深入閱讀本文的正文內(nèi)容。干貨馬上開始了。。。

4、架構(gòu)演進階段一：單應用架構(gòu)

如上圖所示，這個階段是網(wǎng)站的初期，也可以認為是互聯(lián)網(wǎng)發(fā)展的早期，系統(tǒng)架構(gòu)如上圖所示。我們經(jīng)常會在單臺服務器上運行我們所有的程序和軟件。 把所有軟件和應用都部署在一臺機器上，這樣就完成一個簡單系統(tǒng)的搭建，這個階段的講究的是效率。效率決定生死。

5、架構(gòu)演進階段二：應用服務器和數(shù)據(jù)庫服務器分離

隨著網(wǎng)站的上線，訪問量逐步上升，服務器的負載慢慢提高，我們應該在服務器還沒有超載的時候就做好規(guī)劃、提升網(wǎng)站的負載能力。假若此時已經(jīng)沒辦法在代碼層面繼續(xù)優(yōu)化提高，那么在單臺機器的性能遇到瓶頸的時候，增加機器是一個比較簡單好用的方式，投入產(chǎn)出比相當高。這個階段增加機器的主要目的是將 web 服務器和 數(shù)據(jù)庫服務器拆分開來，這樣做的話不僅提高了單機的負載能力，也提高了整個系統(tǒng)的容災能力。

這個階段的系統(tǒng)架構(gòu)如上圖所示，應用服務器和數(shù)據(jù)庫服務器完全隔離開來，相互互不影響，大大減少了網(wǎng)站宕機的風險，此階段我們已經(jīng)開始關(guān)注到應用服務器的管理了。 

6、架構(gòu)演進階段三：應用服務器集群

這個階段，隨著訪問量的繼續(xù)不斷增加，單臺應用服務器已經(jīng)無法滿足我們的需求。 假設我的數(shù)據(jù)庫服務器還沒有遇到性能問題，那我們可以通過增加應用服務器的方式來將應用服務器集群化，這樣就可以將用戶請求分流到各個服務器中，從而達到繼續(xù)提升系統(tǒng)負載能力的目的。此時各個應用服務器之間沒有直接的交互，他們都是依賴數(shù)據(jù)庫各自對外提供服務。

系統(tǒng)架構(gòu)發(fā)展到這個階段，各種問題也會接踵而至：

1）用戶請求交由誰來轉(zhuǎn)發(fā)到具體的應用服務器上(誰來負責負載均衡)；

2）用戶如果每次訪問到的服務器不一樣，那么如何維護session，達到session共享的目的。

那么此時，系統(tǒng)架構(gòu)又會變成如下方式：

負載均衡又可以分為軟負載和硬負載。軟負載我們可以選擇Nginx、Apache等，硬負載我們可以選擇F5等。而session共享問題我們可以通過配置tomcat的session共享解決。

7、架構(gòu)演進階段四：數(shù)據(jù)庫壓力變大，數(shù)據(jù)庫讀寫分離

架構(gòu)演變到上面的階段，并不是終點。通過上面的設計，應用層的性能被我們拉上來了， 但數(shù)據(jù)庫的負載也在逐漸增大，那如何去提高數(shù)據(jù)庫層面的性能呢？有了前面的設計思路以后，我們自然也會想到通過增加服務器來提高性能。但假如我們單純的把數(shù)據(jù)庫一分為二，然后對于數(shù)據(jù)庫的請求，分別負載到兩臺數(shù)據(jù)庫服務器上，那必定會造成數(shù)據(jù)庫數(shù)據(jù)不統(tǒng)一的問題。 

所以我們一般先考慮將數(shù)據(jù)庫讀寫分離，如下圖所示。

這個架構(gòu)設計的變化會帶來如下幾個問題：

1）主從數(shù)據(jù)庫之間的數(shù)據(jù)需要同步(可以使用 mysql 自帶的 master-slave 方式實現(xiàn)主從復制 )；

2）應用中需要根據(jù)業(yè)務進行對應數(shù)據(jù)源的選擇( 采用第三方數(shù)據(jù)庫中間件，例如 mycat )。

8、架構(gòu)演進階段五：使用搜索引擎緩解讀庫的壓力

我們都知道數(shù)據(jù)庫常常對模糊查找效率不是很高，像電商類的網(wǎng)站，搜索是非常核心的功能，即使是做了讀寫分離，這個問題也不能得到有效解決。那么這個時候我們就需要引入搜索引擎了，使用搜索引擎能夠大大提升我們系統(tǒng)的查詢速度，但同時也會帶來一 些附加的問題，比如維護索引的構(gòu)建、數(shù)據(jù)同步到搜索引擎等。

9、架構(gòu)演進階段六：引入緩存機制緩解數(shù)據(jù)庫的壓力

然后，隨著訪問量的持續(xù)不斷增加，逐漸會出現(xiàn)許多用戶訪問同一內(nèi)容的情況，那么對于這些熱點數(shù)據(jù)，沒必要每次都從數(shù)據(jù)庫重讀取，這時我們可以使用到緩存技術(shù)，比如 redis、memcache 來作為我們應用層的緩存。

另外在某些場景下，如我們對用戶的某些 IP 的訪問頻率做限制， 那這個放內(nèi)存中就又不合適，放數(shù)據(jù)庫又太麻煩了，那這個時候可以使用 Nosql 的方式比如 mongDB 來代替?zhèn)鹘y(tǒng)的關(guān)系型數(shù)據(jù)庫。

10、架構(gòu)演進階段七：數(shù)據(jù)庫的水平/垂直拆分

我們的網(wǎng)站演進的變化過程，交易、商品、用戶的數(shù)據(jù)都還在同一 個數(shù)據(jù)庫中，盡管采取了增加緩存，讀寫分離的方式，但是隨著數(shù) 據(jù)庫的壓力持續(xù)增加，數(shù)據(jù)庫的瓶頸仍然是個最大的問題。因此我 們可以考慮對數(shù)據(jù)的垂直拆分和水平拆分。

垂直拆分：把數(shù)據(jù)庫中不同業(yè)務數(shù)據(jù)拆分到不同的數(shù)據(jù)庫；

水平拆分：把同一個表中的數(shù)據(jù)拆分到兩個甚至更多的數(shù)據(jù)庫中，水平拆分的原因是某些業(yè)務數(shù)據(jù)量已經(jīng)達到了單個數(shù)據(jù)庫的瓶頸，這時可以采取將表拆分到多個數(shù)據(jù)庫中。

11、架構(gòu)演進階段八：應用的拆分

隨著業(yè)務的發(fā)展，業(yè)務量越來越大，應用的壓力越來越大。工程規(guī)模也越來越龐大。這個時候就可以考慮將應用拆分，按照領(lǐng)域模型將我們的用戶、商品、交易拆分成多個子系統(tǒng)。

這樣拆分以后，可能會有一些相同的代碼，比如用戶操作，在商品和交易都需要查詢，所以會導致每個系統(tǒng)都會有用戶查詢訪問相關(guān)操作。這些相同的操作一定是要抽象出來，否則就是一個坑。所以通過走服務化路線的方式來解決。

那么服務拆分以后，各個服務之間如何進行遠程通信呢? 通過 RPC 技術(shù)，比較典型的有:dubbo、webservice、hessian、http、RMI 等等。前期通過這些技術(shù)能夠很好的解決各個服務之間通信問題，但是， 互聯(lián)網(wǎng)的發(fā)展是持續(xù)的，所以架構(gòu)的演變和優(yōu)化也還在持續(xù)。

12、本文小結(jié)

通過本文，我們通過一個電商的案例，就了解到了分布式架構(gòu)的演進過程，一環(huán)套一環(huán)，環(huán)環(huán)緊密相扣。都是通過業(yè)務量和訪問量的提升來考慮重構(gòu)架構(gòu)設計，以便能夠適應當前的環(huán)境。不可一蹴而就，也急不來，初創(chuàng)企業(yè)必須穩(wěn)扎穩(wěn)打，一步一個腳印的走出一條專屬自己的路。

本文主要針對的是零基礎(chǔ)初學者，如果您想深入了解相關(guān)知識，請繼續(xù)閱讀《騰訊資深架構(gòu)師干貨總結(jié)：一文讀懂大型分布式系統(tǒng)設計的方方面面》。

附錄：更多架構(gòu)方面的技術(shù)文章

《淺談IM系統(tǒng)的架構(gòu)設計》

《簡述移動端IM開發(fā)的那些坑：架構(gòu)設計、通信協(xié)議和客戶端》

《一套海量在線用戶的移動端IM架構(gòu)設計實踐分享(含詳細圖文)》

《一套原創(chuàng)分布式即時通訊(IM)系統(tǒng)理論架構(gòu)方案》

《從零到卓越：京東客服即時通訊系統(tǒng)的技術(shù)架構(gòu)演進歷程》

《蘑菇街即時通訊/IM服務器開發(fā)之架構(gòu)選擇》

《騰訊QQ1.4億在線用戶的技術(shù)挑戰(zhàn)和架構(gòu)演進之路PPT》

《微信后臺基于時間序的海量數(shù)據(jù)冷熱分級架構(gòu)設計實踐》

《微信技術(shù)總監(jiān)談架構(gòu)：微信之道——大道至簡(演講全文)》

《如何解讀《微信技術(shù)總監(jiān)談架構(gòu)：微信之道——大道至簡》》

《快速裂變：見證微信強大后臺架構(gòu)從0到1的演進歷程（一）》

《17年的實踐：騰訊海量產(chǎn)品的技術(shù)方法論》

《移動端IM中大規(guī)模群消息的推送如何保證效率、實時性？》

《現(xiàn)代IM系統(tǒng)中聊天消息的同步和存儲方案探討》

《IM開發(fā)基礎(chǔ)知識補課(二)：如何設計大量圖片文件的服務端存儲架構(gòu)？》

《IM開發(fā)基礎(chǔ)知識補課(三)：快速理解服務端數(shù)據(jù)庫讀寫分離原理及實踐建議》

《IM開發(fā)基礎(chǔ)知識補課(四)：正確理解HTTP短連接中的Cookie、Session和Token》

《WhatsApp技術(shù)實踐分享：32人工程團隊創(chuàng)造的技術(shù)神話》

《微信朋友圈千億訪問量背后的技術(shù)挑戰(zhàn)和實踐總結(jié)》

《王者榮耀2億用戶量的背后：產(chǎn)品定位、技術(shù)架構(gòu)、網(wǎng)絡方案等》

《IM系統(tǒng)的MQ消息中間件選型：Kafka還是RabbitMQ？》

《騰訊資深架構(gòu)師干貨總結(jié)：一文讀懂大型分布式系統(tǒng)設計的方方面面》

《以微博類應用場景為例，總結(jié)海量社交系統(tǒng)的架構(gòu)設計步驟》

《快速理解高性能HTTP服務端的負載均衡技術(shù)原理》

《子彈短信光鮮的背后：網(wǎng)易云信首席架構(gòu)師分享億級IM平臺的技術(shù)實踐》

《知乎技術(shù)分享：從單機到2000萬QPS并發(fā)的Redis高性能緩存實踐之路》

《IM開發(fā)基礎(chǔ)知識補課(五)：通俗易懂，正確理解并用好MQ消息隊列》

《微信技術(shù)分享：微信的海量IM聊天消息序列號生成實踐（算法原理篇）》

《微信技術(shù)分享：微信的海量IM聊天消息序列號生成實踐（容災方案篇）》

《新手入門：零基礎(chǔ)理解大型分布式架構(gòu)的演進歷史、技術(shù)原理、最佳實踐》

>> 更多同類文章 ……

（本文同步發(fā)布于：http://www.52im.net/thread-2007-1-1.html）