本文引用了阿豪的微信公眾號(hào)文章分享，感謝原作者的分享。
1、前言
隨著社會(huì)的發(fā)展、互聯(lián)網(wǎng)技術(shù)的進(jìn)步，以前的大型機(jī)服務(wù)端架構(gòu)很顯然由于高成本、難維護(hù)等原因漸漸地變得不再那么主流了，替代它的就是當(dāng)下最火的互聯(lián)網(wǎng)分布式架構(gòu)。
從若干年前大行其道的傳統(tǒng)大型機(jī)到如今的分布式架構(gòu)，技術(shù)發(fā)展已經(jīng)經(jīng)歷了好幾個(gè)階段，我們只有弄明白典型互聯(lián)網(wǎng)架構(gòu)在各個(gè)階段的演進(jìn)，才能更好地理解和體會(huì)分布式架構(gòu)的好處，從而有助于我們序設(shè)計(jì)適合于自已公司、產(chǎn)品或項(xiàng)目的架構(gòu)（也包括設(shè)計(jì)即時(shí)通訊網(wǎng)專(zhuān)注的IM和消息推送這類(lèi)系統(tǒng)，因?yàn)榧夹g(shù)思路的原理都是一脈相承的）。那么本文我們就來(lái)聊聊分布式架構(gòu)的演進(jìn)過(guò)程，希望能給大家?guī)?lái)眼前一亮的感覺(jué)。
點(diǎn)評(píng)：即時(shí)通訊網(wǎng)作為IM和推送技術(shù)研究、學(xué)習(xí)和分享的社區(qū)，整理了大量的跟IM和推廣技術(shù)有關(guān)的基礎(chǔ)技術(shù)資料（比如網(wǎng)絡(luò)基礎(chǔ)、通信理論、架構(gòu)基礎(chǔ)等），本文內(nèi)容雖然看起來(lái)跟IM和推送技術(shù)沒(méi)有直接的關(guān)聯(lián)性，但因?yàn)樵O(shè)計(jì)IM和推送系統(tǒng)的技術(shù)思路和原理跟典型大型互聯(lián)網(wǎng)分布式架構(gòu)都是一脈相承的，因而讀懂本文內(nèi)容對(duì)于IM和推送系統(tǒng)的架構(gòu)設(shè)計(jì)同樣大有裨益。
學(xué)習(xí)交流：
- 即時(shí)通訊開(kāi)發(fā)交流3群：185926912[推薦]
- 移動(dòng)端IM開(kāi)發(fā)入門(mén)文章：《新手入門(mén)一篇就夠：從零開(kāi)發(fā)移動(dòng)端IM》
（本文同步發(fā)布于：http://www.52im.net/thread-2007-1-1.html）
2、相關(guān)文章
如果你已完全掌握本文的相關(guān)知識(shí)，請(qǐng)移步繼續(xù)閱讀即時(shí)通訊網(wǎng)整理的另一篇：《騰訊資深架構(gòu)師干貨總結(jié)：一文讀懂大型分布式系統(tǒng)設(shè)計(jì)的方方面面》，該文適合對(duì)互聯(lián)網(wǎng)架構(gòu)知識(shí)有一定了解的程序員閱讀和學(xué)習(xí)，都是不可能多得的技術(shù)干貨。
3、技術(shù)背景說(shuō)明
我們都知道一個(gè)成熟的大型網(wǎng)站的系統(tǒng)架構(gòu)并非一開(kāi)始就設(shè)計(jì)的非常完美，也沒(méi)有一開(kāi)始就具備高性能、高并發(fā)、高可用、安全性等特性，而是隨著用戶量的增加、業(yè)務(wù)功能的擴(kuò)展逐步演變過(guò)來(lái)的，慢慢的完善的。 在這個(gè)過(guò)程中，開(kāi)發(fā)模式、技術(shù)架構(gòu)等都會(huì)隨著迭代發(fā)生非常大的變化。 而針對(duì)不同業(yè)務(wù)特征的系統(tǒng)，各自都會(huì)有自己的側(cè)重點(diǎn)，例如像淘寶這類(lèi)的網(wǎng)站，要解決的重點(diǎn)問(wèn)題就是海量商品搜索、下單、支付等問(wèn)題; 像騰訊這類(lèi)的網(wǎng)站，要解決的是數(shù)億級(jí)別用戶的實(shí)時(shí)消息傳輸;而像百度這類(lèi)的公司所要解決的又是海量數(shù)據(jù)的搜索。每一個(gè)種類(lèi)的業(yè)務(wù)都有自己不同的系統(tǒng)架構(gòu)。
為了方便展開(kāi)本文要講解的內(nèi)容，我們來(lái)簡(jiǎn)單模擬一個(gè)架構(gòu)演變過(guò)程： 我們以 javaweb 為例，來(lái)搭建一個(gè)簡(jiǎn)單的電商系統(tǒng)，從這個(gè)系統(tǒng)中來(lái)看系統(tǒng)的演變過(guò)程。要注意的是接下來(lái)的演示模型， 關(guān)注的是數(shù)據(jù)量、訪問(wèn)量提升，網(wǎng)站結(jié)構(gòu)的變化， 而不關(guān)注具體業(yè)務(wù)的功能點(diǎn)。其次，這個(gè)過(guò)程是為了讓大家能更好的了解網(wǎng)站演進(jìn)過(guò)程中的一些問(wèn)題和應(yīng)對(duì)策略。
假如我們要設(shè)計(jì)的互聯(lián)網(wǎng)系統(tǒng)需要具備以下功能:
1）用戶模塊：用戶注冊(cè)和管理；
2）商品模塊:商品展示和管理；
3）交易模塊:創(chuàng)建交易及支付結(jié)算。
請(qǐng)帶著上述3個(gè)技術(shù)點(diǎn)，繼續(xù)深入閱讀本文的正文內(nèi)容。干貨馬上開(kāi)始了。。。
4、架構(gòu)演進(jìn)階段一：?jiǎn)螒?yīng)用架構(gòu)
如上圖所示，這個(gè)階段是網(wǎng)站的初期，也可以認(rèn)為是互聯(lián)網(wǎng)發(fā)展的早期，系統(tǒng)架構(gòu)如上圖所示。我們經(jīng)常會(huì)在單臺(tái)服務(wù)器上運(yùn)行我們所有的程序和軟件。 把所有軟件和應(yīng)用都部署在一臺(tái)機(jī)器上，這樣就完成一個(gè)簡(jiǎn)單系統(tǒng)的搭建，這個(gè)階段的講究的是效率。效率決定生死。
5、架構(gòu)演進(jìn)階段二：應(yīng)用服務(wù)器和數(shù)據(jù)庫(kù)服務(wù)器分離
隨著網(wǎng)站的上線，訪問(wèn)量逐步上升，服務(wù)器的負(fù)載慢慢提高，我們應(yīng)該在服務(wù)器還沒(méi)有超載的時(shí)候就做好規(guī)劃、提升網(wǎng)站的負(fù)載能力。假若此時(shí)已經(jīng)沒(méi)辦法在代碼層面繼續(xù)優(yōu)化提高，那么在單臺(tái)機(jī)器的性能遇到瓶頸的時(shí)候，增加機(jī)器是一個(gè)比較簡(jiǎn)單好用的方式，投入產(chǎn)出比相當(dāng)高。這個(gè)階段增加機(jī)器的主要目的是將 web 服務(wù)器和 數(shù)據(jù)庫(kù)服務(wù)器拆分開(kāi)來(lái)，這樣做的話不僅提高了單機(jī)的負(fù)載能力，也提高了整個(gè)系統(tǒng)的容災(zāi)能力。
這個(gè)階段的系統(tǒng)架構(gòu)如上圖所示，應(yīng)用服務(wù)器和數(shù)據(jù)庫(kù)服務(wù)器完全隔離開(kāi)來(lái)，相互互不影響，大大減少了網(wǎng)站宕機(jī)的風(fēng)險(xiǎn)，此階段我們已經(jīng)開(kāi)始關(guān)注到應(yīng)用服務(wù)器的管理了。
6、架構(gòu)演進(jìn)階段三：應(yīng)用服務(wù)器集群
這個(gè)階段，隨著訪問(wèn)量的繼續(xù)不斷增加，單臺(tái)應(yīng)用服務(wù)器已經(jīng)無(wú)法滿足我們的需求。 假設(shè)我的數(shù)據(jù)庫(kù)服務(wù)器還沒(méi)有遇到性能問(wèn)題，那我們可以通過(guò)增加應(yīng)用服務(wù)器的方式來(lái)將應(yīng)用服務(wù)器集群化，這樣就可以將用戶請(qǐng)求分流到各個(gè)服務(wù)器中，從而達(dá)到繼續(xù)提升系統(tǒng)負(fù)載能力的目的。此時(shí)各個(gè)應(yīng)用服務(wù)器之間沒(méi)有直接的交互，他們都是依賴(lài)數(shù)據(jù)庫(kù)各自對(duì)外提供服務(wù)。
系統(tǒng)架構(gòu)發(fā)展到這個(gè)階段，各種問(wèn)題也會(huì)接踵而至：
1）用戶請(qǐng)求交由誰(shuí)來(lái)轉(zhuǎn)發(fā)到具體的應(yīng)用服務(wù)器上(誰(shuí)來(lái)負(fù)責(zé)負(fù)載均衡)；
2）用戶如果每次訪問(wèn)到的服務(wù)器不一樣，那么如何維護(hù)session，達(dá)到session共享的目的。
那么此時(shí)，系統(tǒng)架構(gòu)又會(huì)變成如下方式：
負(fù)載均衡又可以分為軟負(fù)載和硬負(fù)載。軟負(fù)載我們可以選擇Nginx、Apache等，硬負(fù)載我們可以選擇F5等。而session共享問(wèn)題我們可以通過(guò)配置tomcat的session共享解決。
7、架構(gòu)演進(jìn)階段四：數(shù)據(jù)庫(kù)壓力變大，數(shù)據(jù)庫(kù)讀寫(xiě)分離
架構(gòu)演變到上面的階段，并不是終點(diǎn)。通過(guò)上面的設(shè)計(jì)，應(yīng)用層的性能被我們拉上來(lái)了， 但數(shù)據(jù)庫(kù)的負(fù)載也在逐漸增大，那如何去提高數(shù)據(jù)庫(kù)層面的性能呢？有了前面的設(shè)計(jì)思路以后，我們自然也會(huì)想到通過(guò)增加服務(wù)器來(lái)提高性能。但假如我們單純的把數(shù)據(jù)庫(kù)一分為二，然后對(duì)于數(shù)據(jù)庫(kù)的請(qǐng)求，分別負(fù)載到兩臺(tái)數(shù)據(jù)庫(kù)服務(wù)器上，那必定會(huì)造成數(shù)據(jù)庫(kù)數(shù)據(jù)不統(tǒng)一的問(wèn)題。
所以我們一般先考慮將數(shù)據(jù)庫(kù)讀寫(xiě)分離，如下圖所示。
這個(gè)架構(gòu)設(shè)計(jì)的變化會(huì)帶來(lái)如下幾個(gè)問(wèn)題：
1）主從數(shù)據(jù)庫(kù)之間的數(shù)據(jù)需要同步(可以使用 mysql 自帶的 master-slave 方式實(shí)現(xiàn)主從復(fù)制 )；
2）應(yīng)用中需要根據(jù)業(yè)務(wù)進(jìn)行對(duì)應(yīng)數(shù)據(jù)源的選擇( 采用第三方數(shù)據(jù)庫(kù)中間件，例如 mycat )。
8、架構(gòu)演進(jìn)階段五：使用搜索引擎緩解讀庫(kù)的壓力
我們都知道數(shù)據(jù)庫(kù)常常對(duì)模糊查找效率不是很高，像電商類(lèi)的網(wǎng)站，搜索是非常核心的功能，即使是做了讀寫(xiě)分離，這個(gè)問(wèn)題也不能得到有效解決。那么這個(gè)時(shí)候我們就需要引入搜索引擎了，使用搜索引擎能夠大大提升我們系統(tǒng)的查詢(xún)速度，但同時(shí)也會(huì)帶來(lái)一 些附加的問(wèn)題，比如維護(hù)索引的構(gòu)建、數(shù)據(jù)同步到搜索引擎等。
9、架構(gòu)演進(jìn)階段六：引入緩存機(jī)制緩解數(shù)據(jù)庫(kù)的壓力
然后，隨著訪問(wèn)量的持續(xù)不斷增加，逐漸會(huì)出現(xiàn)許多用戶訪問(wèn)同一內(nèi)容的情況，那么對(duì)于這些熱點(diǎn)數(shù)據(jù)，沒(méi)必要每次都從數(shù)據(jù)庫(kù)重讀取，這時(shí)我們可以使用到緩存技術(shù)，比如 redis、memcache 來(lái)作為我們應(yīng)用層的緩存。
另外在某些場(chǎng)景下，如我們對(duì)用戶的某些 IP 的訪問(wèn)頻率做限制， 那這個(gè)放內(nèi)存中就又不合適，放數(shù)據(jù)庫(kù)又太麻煩了，那這個(gè)時(shí)候可以使用 Nosql 的方式比如 mongDB 來(lái)代替?zhèn)鹘y(tǒng)的關(guān)系型數(shù)據(jù)庫(kù)。
10、架構(gòu)演進(jìn)階段七：數(shù)據(jù)庫(kù)的水平/垂直拆分
我們的網(wǎng)站演進(jìn)的變化過(guò)程，交易、商品、用戶的數(shù)據(jù)都還在同一 個(gè)數(shù)據(jù)庫(kù)中，盡管采取了增加緩存，讀寫(xiě)分離的方式，但是隨著數(shù) 據(jù)庫(kù)的壓力持續(xù)增加，數(shù)據(jù)庫(kù)的瓶頸仍然是個(gè)最大的問(wèn)題。因此我 們可以考慮對(duì)數(shù)據(jù)的垂直拆分和水平拆分。
垂直拆分：把數(shù)據(jù)庫(kù)中不同業(yè)務(wù)數(shù)據(jù)拆分到不同的數(shù)據(jù)庫(kù)；
水平拆分：把同一個(gè)表中的數(shù)據(jù)拆分到兩個(gè)甚至更多的數(shù)據(jù)庫(kù)中，水平拆分的原因是某些業(yè)務(wù)數(shù)據(jù)量已經(jīng)達(dá)到了單個(gè)數(shù)據(jù)庫(kù)的瓶頸，這時(shí)可以采取將表拆分到多個(gè)數(shù)據(jù)庫(kù)中。
11、架構(gòu)演進(jìn)階段八：應(yīng)用的拆分
隨著業(yè)務(wù)的發(fā)展，業(yè)務(wù)量越來(lái)越大，應(yīng)用的壓力越來(lái)越大。工程規(guī)模也越來(lái)越龐大。這個(gè)時(shí)候就可以考慮將應(yīng)用拆分，按照領(lǐng)域模型將我們的用戶、商品、交易拆分成多個(gè)子系統(tǒng)。
這樣拆分以后，可能會(huì)有一些相同的代碼，比如用戶操作，在商品和交易都需要查詢(xún)，所以會(huì)導(dǎo)致每個(gè)系統(tǒng)都會(huì)有用戶查詢(xún)?cè)L問(wèn)相關(guān)操作。這些相同的操作一定是要抽象出來(lái)，否則就是一個(gè)坑。所以通過(guò)走服務(wù)化路線的方式來(lái)解決。
那么服務(wù)拆分以后，各個(gè)服務(wù)之間如何進(jìn)行遠(yuǎn)程通信呢? 通過(guò) RPC 技術(shù)，比較典型的有:dubbo、webservice、hessian、http、RMI 等等。前期通過(guò)這些技術(shù)能夠很好的解決各個(gè)服務(wù)之間通信問(wèn)題，但是， 互聯(lián)網(wǎng)的發(fā)展是持續(xù)的，所以架構(gòu)的演變和優(yōu)化也還在持續(xù)。
12、本文小結(jié)
通過(guò)本文，我們通過(guò)一個(gè)電商的案例，就了解到了分布式架構(gòu)的演進(jìn)過(guò)程，一環(huán)套一環(huán)，環(huán)環(huán)緊密相扣。都是通過(guò)業(yè)務(wù)量和訪問(wèn)量的提升來(lái)考慮重構(gòu)架構(gòu)設(shè)計(jì)，以便能夠適應(yīng)當(dāng)前的環(huán)境。不可一蹴而就，也急不來(lái)，初創(chuàng)企業(yè)必須穩(wěn)扎穩(wěn)打，一步一個(gè)腳印的走出一條專(zhuān)屬自己的路。
本文主要針對(duì)的是零基礎(chǔ)初學(xué)者，如果您想深入了解相關(guān)知識(shí)，請(qǐng)繼續(xù)閱讀《騰訊資深架構(gòu)師干貨總結(jié)：一文讀懂大型分布式系統(tǒng)設(shè)計(jì)的方方面面》。
附錄：更多架構(gòu)方面的技術(shù)文章
《淺談IM系統(tǒng)的架構(gòu)設(shè)計(jì)》
《簡(jiǎn)述移動(dòng)端IM開(kāi)發(fā)的那些坑：架構(gòu)設(shè)計(jì)、通信協(xié)議和客戶端》
《一套海量在線用戶的移動(dòng)端IM架構(gòu)設(shè)計(jì)實(shí)踐分享(含詳細(xì)圖文)》
《一套原創(chuàng)分布式即時(shí)通訊(IM)系統(tǒng)理論架構(gòu)方案》
《從零到卓越：京東客服即時(shí)通訊系統(tǒng)的技術(shù)架構(gòu)演進(jìn)歷程》
《蘑菇街即時(shí)通訊/IM服務(wù)器開(kāi)發(fā)之架構(gòu)選擇》
《騰訊QQ1.4億在線用戶的技術(shù)挑戰(zhàn)和架構(gòu)演進(jìn)之路PPT》
《微信后臺(tái)基于時(shí)間序的海量數(shù)據(jù)冷熱分級(jí)架構(gòu)設(shè)計(jì)實(shí)踐》
《微信技術(shù)總監(jiān)談架構(gòu)：微信之道——大道至簡(jiǎn)(演講全文)》
《如何解讀《微信技術(shù)總監(jiān)談架構(gòu)：微信之道——大道至簡(jiǎn)》》
《快速裂變：見(jiàn)證微信強(qiáng)大后臺(tái)架構(gòu)從0到1的演進(jìn)歷程（一）》
《17年的實(shí)踐：騰訊海量產(chǎn)品的技術(shù)方法論》
《移動(dòng)端IM中大規(guī)模群消息的推送如何保證效率、實(shí)時(shí)性？》
《現(xiàn)代IM系統(tǒng)中聊天消息的同步和存儲(chǔ)方案探討》
《IM開(kāi)發(fā)基礎(chǔ)知識(shí)補(bǔ)課(二)：如何設(shè)計(jì)大量圖片文件的服務(wù)端存儲(chǔ)架構(gòu)？》
《IM開(kāi)發(fā)基礎(chǔ)知識(shí)補(bǔ)課(三)：快速理解服務(wù)端數(shù)據(jù)庫(kù)讀寫(xiě)分離原理及實(shí)踐建議》
《IM開(kāi)發(fā)基礎(chǔ)知識(shí)補(bǔ)課(四)：正確理解HTTP短連接中的Cookie、Session和Token》
《WhatsApp技術(shù)實(shí)踐分享：32人工程團(tuán)隊(duì)創(chuàng)造的技術(shù)神話》
《微信朋友圈千億訪問(wèn)量背后的技術(shù)挑戰(zhàn)和實(shí)踐總結(jié)》
《王者榮耀2億用戶量的背后：產(chǎn)品定位、技術(shù)架構(gòu)、網(wǎng)絡(luò)方案等》
《IM系統(tǒng)的MQ消息中間件選型：Kafka還是RabbitMQ？》
《騰訊資深架構(gòu)師干貨總結(jié)：一文讀懂大型分布式系統(tǒng)設(shè)計(jì)的方方面面》
《以微博類(lèi)應(yīng)用場(chǎng)景為例，總結(jié)海量社交系統(tǒng)的架構(gòu)設(shè)計(jì)步驟》
《快速理解高性能HTTP服務(wù)端的負(fù)載均衡技術(shù)原理》
《子彈短信光鮮的背后：網(wǎng)易云信首席架構(gòu)師分享億級(jí)IM平臺(tái)的技術(shù)實(shí)踐》
《知乎技術(shù)分享：從單機(jī)到2000萬(wàn)QPS并發(fā)的Redis高性能緩存實(shí)踐之路》
《IM開(kāi)發(fā)基礎(chǔ)知識(shí)補(bǔ)課(五)：通俗易懂，正確理解并用好MQ消息隊(duì)列》
《微信技術(shù)分享：微信的海量IM聊天消息序列號(hào)生成實(shí)踐（算法原理篇）》
《微信技術(shù)分享：微信的海量IM聊天消息序列號(hào)生成實(shí)踐（容災(zāi)方案篇）》
《新手入門(mén)：零基礎(chǔ)理解大型分布式架構(gòu)的演進(jìn)歷史、技術(shù)原理、最佳實(shí)踐》
>> 更多同類(lèi)文章 ……
（本文同步發(fā)布于：http://www.52im.net/thread-2007-1-1.html）