新手入門：零基礎理解大型分佈式架構的演進歷史、技術原理、最佳實踐
本文引用了阿豪的微信公衆號文章分享，感謝原做者的分享。php
一、前言
隨着社會的發展、互聯網技術的進步，之前的大型機服務端架構很顯然因爲高成本、難維護等緣由漸漸地變得再也不那麼主流了，替代它的就是當下最火的互聯網分佈式架構。html
從若干年前大行其道的傳統大型機到現在的分佈式架構，技術發展已經經歷了好幾個階段，咱們只有弄明白典型互聯網架構在各個階段的演進，才能更好地理解和體會分佈式架構的好處，從而有助於咱們序設計適合於自已公司、產品或項目的架構（也包括設計即時通信網專一的IM和消息推送這類系統，由於技術思路的原理都是一脈相承的）。那麼本文咱們就來聊聊分佈式架構的演進過程，但願能給你們帶來眼前一亮的感受。java
點評：即時通信網做爲IM和推送技術研究、學習和分享的社區，整理了大量的跟IM和推廣技術有關的基礎技術資料（好比網絡基礎、通訊理論、架構基礎等），本文內容雖然看起來跟IM和推送技術沒有直接的關聯性，但由於設計IM和推送系統的技術思路和原理跟典型大型互聯網分佈式架構都是一脈相承的，於是讀懂本文內容對於IM和推送系統的架構設計一樣大有裨益。mysql
學習交流：程序員
- 即時通信開發交流3羣：185926912[推薦]web
- 移動端IM開發入門文章：《新手入門一篇就夠：從零開發移動端IM》redis
（本文同步發佈於：http://www.52im.net/thread-2007-1-1.html）算法
二、相關文章
若是你已徹底掌握本文的相關知識，請移步繼續閱讀即時通信網整理的另外一篇：《騰訊資深架構師乾貨總結：一文讀懂大型分佈式系統設計的方方面面》，該文適合對互聯網架構知識有必定了解的程序員閱讀和學習，都是不可能多得的技術乾貨。sql
三、技術背景說明
咱們都知道一個成熟的大型網站的系統架構並不是一開始就設計的很是完美，也沒有一開始就具有高性能、高併發、高可用、安全性等特性，而是隨着用戶量的增長、業務功能的擴展逐步演變過來的，慢慢的完善的。 在這個過程當中，開發模式、技術架構等都會隨着迭代發生很是大的變化。 而針對不一樣業務特徵的系統，各自都會有本身的側重點，例如像淘寶這類的網站，要解決的重點問題就是海量商品搜索、下單、支付等問題; 像騰訊這類的網站，要解決的是數億級別用戶的實時消息傳輸;而像百度這類的公司所要解決的又是海量數據的搜索。每個種類的業務都有本身不一樣的系統架構。數據庫
爲了方便展開本文要講解的內容，咱們來簡單模擬一個架構演變過程： 咱們以 javaweb 爲例，來搭建一個簡單的電商系統，從這個系統中來看系統的演變過程。要注意的是接下來的演示模型， 關注的是數據量、訪問量提高，網站結構的變化， 而不關注具體業務的功能點。其次，這個過程是爲了讓你們能更好的瞭解網站演進過程當中的一些問題和應對策略。
假如咱們要設計的互聯網系統須要具有如下功能:
1）用戶模塊：用戶註冊和管理；
2）商品模塊:商品展現和管理；
3）交易模塊:建立交易及支付結算。
請帶着上述3個技術點，繼續深刻閱讀本文的正文內容。乾貨立刻開始了。。。
四、架構演進階段一：單應用架構
如上圖所示，這個階段是網站的初期，也能夠認爲是互聯網發展的早期，系統架構如上圖所示。咱們常常會在單臺服務器上運行咱們全部的程序和軟件。 把全部軟件和應用都部署在一臺機器上，這樣就完成一個簡單系統的搭建，這個階段的講究的是效率。效率決定生死。
五、架構演進階段二：應用服務器和數據庫服務器分離
隨着網站的上線，訪問量逐步上升，服務器的負載慢慢提升，咱們應該在服務器尚未超載的時候就作好規劃、提高網站的負載能力。倘若此時已經沒辦法在代碼層面繼續優化提升，那麼在單臺機器的性能遇到瓶頸的時候，增長機器是一個比較簡單好用的方式，投入產出比至關高。這個階段增長機器的主要目的是將 web 服務器和 數據庫服務器拆分開來，這樣作的話不只提升了單機的負載能力，也提升了整個系統的容災能力。
這個階段的系統架構如上圖所示，應用服務器和數據庫服務器徹底隔離開來，相互互不影響，大大減小了網站宕機的風險，此階段咱們已經開始關注到應用服務器的管理了。
六、架構演進階段三：應用服務器集羣
這個階段，隨着訪問量的繼續不斷增長，單臺應用服務器已經沒法知足咱們的需求。 假設個人數據庫服務器尚未遇到性能問題，那咱們能夠經過增長應用服務器的方式來將應用服務器集羣化，這樣就能夠將用戶請求分流到各個服務器中，從而達到繼續提高系統負載能力的目的。此時各個應用服務器之間沒有直接的交互，他們都是依賴數據庫各自對外提供服務。
系統架構發展到這個階段，各類問題也會接踵而至：
1）用戶請求交由誰來轉發到具體的應用服務器上(誰來負責負載均衡)；
2）用戶若是每次訪問到的服務器不同，那麼如何維護session，達到session共享的目的。
那麼此時，系統架構又會變成以下方式：
負載均衡又能夠分爲軟負載和硬負載。軟負載咱們能夠選擇Nginx、Apache等，硬負載咱們能夠選擇F5等。而session共享問題咱們能夠經過配置tomcat的session共享解決。
七、架構演進階段四：數據庫壓力變大，數據庫讀寫分離
架構演變到上面的階段，並非終點。經過上面的設計，應用層的性能被咱們拉上來了， 但數據庫的負載也在逐漸增大，那如何去提升數據庫層面的性能呢？有了前面的設計思路之後，咱們天然也會想到經過增長服務器來提升性能。但假如咱們單純的把數據庫一分爲二，而後對於數據庫的請求，分別負載到兩臺數據庫服務器上，那一定會形成數據庫數據不統一的問題。
因此咱們通常先考慮將數據庫讀寫分離，以下圖所示。
這個架構設計的變化會帶來以下幾個問題：
1）主從數據庫之間的數據須要同步(可使用 mysql 自帶的 master-slave 方式實現主從複製 )；
2）應用中須要根據業務進行對應數據源的選擇( 採用第三方數據庫中間件，例如 mycat )。
八、架構演進階段五：使用搜索引擎緩解讀庫的壓力
咱們都知道數據庫經常對模糊查找效率不是很高，像電商類的網站，搜索是很是核心的功能，即便是作了讀寫分離，這個問題也不能獲得有效解決。那麼這個時候咱們就須要引入搜索引擎了，使用搜索引擎可以大大提高咱們系統的查詢速度，但同時也會帶來一 些附加的問題，好比維護索引的構建、數據同步到搜索引擎等。
九、架構演進階段六：引入緩存機制緩解數據庫的壓力
而後，隨着訪問量的持續不斷增長，逐漸會出現許多用戶訪問同一內容的狀況，那麼對於這些熱點數據，不必每次都從數據庫重讀取，這時咱們可使用到緩存技術，好比 redis、memcache 來做爲咱們應用層的緩存。
另外在某些場景下，如咱們對用戶的某些 IP 的訪問頻率作限制， 那這個放內存中就又不合適，放數據庫又太麻煩了，那這個時候可使用 Nosql 的方式好比 mongDB 來代替傳統的關係型數據庫。
十、架構演進階段七：數據庫的水平/垂直拆分
咱們的網站演進的變化過程，交易、商品、用戶的數據都還在同一 個數據庫中，儘管採起了增長緩存，讀寫分離的方式，可是隨着數 據庫的壓力持續增長，數據庫的瓶頸仍然是個最大的問題。所以我 們能夠考慮對數據的垂直拆分和水平拆分。
垂直拆分：把數據庫中不一樣業務數據拆分到不一樣的數據庫；
水平拆分：把同一個表中的數據拆分到兩個甚至更多的數據庫中，水平拆分的緣由是某些業務數據量已經達到了單個數據庫的瓶頸，這時能夠採起將表拆分到多個數據庫中。
十一、架構演進階段八：應用的拆分
隨着業務的發展，業務量愈來愈大，應用的壓力愈來愈大。工程規模也愈來愈龐大。這個時候就能夠考慮將應用拆分，按照領域模型將咱們的用戶、商品、交易拆分紅多個子系統。
這樣拆分之後，可能會有一些相同的代碼，好比用戶操做，在商品和交易都須要查詢，因此會致使每一個系統都會有用戶查詢訪問相關操做。這些相同的操做必定是要抽象出來，不然就是一個坑。因此經過走服務化路線的方式來解決。
那麼服務拆分之後，各個服務之間如何進行遠程通訊呢? 經過 RPC 技術，比較典型的有:dubbo、webservice、hessian、http、RMI 等等。前期經過這些技術可以很好的解決各個服務之間通訊問題，可是， 互聯網的發展是持續的，因此架構的演變和優化也還在持續。
十二、本文小結
經過本文，咱們經過一個電商的案例，就瞭解到了分佈式架構的演進過程，一環套一環，環環緊密相扣。都是經過業務量和訪問量的提高來考慮重構架構設計，以便可以適應當前的環境。不可一蹴而就，也急不來，初創企業必須穩紮穩打，一步一個腳印的走出一條專屬本身的路。
本文主要針對的是零基礎初學者，若是您想深刻了解相關知識，請繼續閱讀《騰訊資深架構師乾貨總結：一文讀懂大型分佈式系統設計的方方面面》。
附錄：更多架構方面的技術文章
《一套海量在線用戶的移動端IM架構設計實踐分享(含詳細圖文)》
《IM開發基礎知識補課(二)：如何設計大量圖片文件的服務端存儲架構？》
《IM開發基礎知識補課(三)：快速理解服務端數據庫讀寫分離原理及實踐建議》
《IM開發基礎知識補課(四)：正確理解HTTP短鏈接中的Cookie、Session和Token》
《WhatsApp技術實踐分享：32人工程團隊創造的技術神話》
《王者榮耀2億用戶量的背後：產品定位、技術架構、網絡方案等》
《IM系統的MQ消息中間件選型：Kafka仍是RabbitMQ？》
《騰訊資深架構師乾貨總結：一文讀懂大型分佈式系統設計的方方面面》
《子彈短信光鮮的背後：網易雲信首席架構師分享億級IM平臺的技術實踐》
《知乎技術分享：從單機到2000萬QPS併發的Redis高性能緩存實踐之路》
《IM開發基礎知識補課(五)：通俗易懂，正確理解並用好MQ消息隊列》
《微信技術分享：微信的海量IM聊天消息序列號生成實踐（算法原理篇）》
《微信技術分享：微信的海量IM聊天消息序列號生成實踐（容災方案篇）》
《新手入門：零基礎理解大型分佈式架構的演進歷史、技術原理、最佳實踐》
>> 更多同類文章 ……
（本文同步發佈於：http://www.52im.net/thread-2007-1-1.html）
- 1. 新手入門：零基礎理解大型分佈式架構的演進歷史、技術原理、最佳實踐
- 2. 架構演進和分佈式技術
- 3. 分佈式架構演變歷史2
- 4. 分佈式基礎(1)-大型網站架構演進過程
- 5. 分佈式架構的演進歷程
- 6. 大型分佈式電商系統架構演進史？
- 7. 大型分佈式電商系統架構演進史
- 8. 大型分佈式電商系統架構演進史？（三）
- 9. 分庫分表技術演進&最佳實踐-修訂篇
- 10. 分庫分表技術演進&最佳實踐
- 更多相關文章...
- • MyBatis的工作原理 - MyBatis教程
- • BASE原理與最終一致性 - NoSQL教程
- • Java Agent入門實戰（三）-JVM Attach原理與使用
- • ☆技術問答集錦（13）Java Instrument原理
-
每一个你不满意的现在，都有一个你没有努力的曾经。
- 1. 新手入門：零基礎理解大型分佈式架構的演進歷史、技術原理、最佳實踐
- 2. 架構演進和分佈式技術
- 3. 分佈式架構演變歷史2
- 4. 分佈式基礎(1)-大型網站架構演進過程
- 5. 分佈式架構的演進歷程
- 6. 大型分佈式電商系統架構演進史？
- 7. 大型分佈式電商系統架構演進史
- 8. 大型分佈式電商系統架構演進史？（三）
- 9. 分庫分表技術演進&最佳實踐-修訂篇
- 10. 分庫分表技術演進&最佳實踐