>[info] 分布式架構的演變過程 由單機計算機的架構——>分布式計算機架構 **前言：** * 一個成熟的大型網站系統架構并不是一開始就設計的非常完美的，世上沒有完美的架構，也不是一 開始就具備高性能、高可用、安全性等特性，而是隨著用戶量的不斷增加、業務功能的擴展逐步完 善演變過來的。在這個過程中，開發模式、技術架構等都會發生非常大的變化。而針對不同的業務 特征的系統，會有各自的側重點，比如像淘寶這類網站，要解決的是海量商品搜索、下單、支付等 問題；像騰訊，要解決的是數億級別用戶的實時消息傳輸；百度所要解決的是海量數據的搜索。每 一類的業務都有自己不同的系統架構。 * 我們以電商系統的發展演變為例，分析架構演變歷程。 關注的是數據量、訪問量提升，網站結構發生的變化，而不是具體關注業務功能點。其次，這個過 程是為了讓大家更好的了，解網站演進過程中的一些問題和應對策略。 * 假如我們系統具備以下功能： 用戶模塊：用戶注冊和管理 商品模塊：商品展示和管理 交易模塊：創建交易及支付結算 ### **第1版應用：單機負載** * 得回憶公司剛創業那會。那是很多年前，那天，公司成立了，老板興致勃勃的租了一間民宅，買了 一臺服務器。然后大伙幾個就開干了。 * 大伙把所有軟件和應用都部署在一臺機器上，這樣就完成一個簡單系統的搭建，這個時候的講究的 是效率。 * 我們在一臺機子上裝了lnmp，下圖描述了我們這臺服務器： **最初的架構，應用程序、數據庫、文件都部署在一臺服務器上：**  ### **第2版：單機負載越來越高，數據庫服務器和應用服務器分離** * 隨著網站的上線，訪問量逐步上升，服務器的負載慢慢提高，在服務器還沒有超載的時候，我們應 該做好規劃，提升網站的負載能力。假如代碼層面的優化已經沒辦法繼續提高，在不提高單臺機器 的性能，增加機器是一個比較好的方式，投入產出比非常高。這個階段增加機器的主要目的是講 web 服務器和 數據庫服務器拆分，這樣不僅提高了單機的負載能力，也提高了容災能力。并且根 據服務器的用途配置不同的硬件，達到最佳的性能效果。 **應用、數據、文件分離：**  ### **第3版：利用緩存改善網站性能** * 在硬件優化性能的同時，同時也通過軟件進行性能優化，在大部分的網站系統中，都會利用緩存技 術改善系統的性能，使用緩存主要源于熱點數據的存在，大部分網站訪問都遵循28原則（即80% 的訪問請求，最終落在20%的數據上），所以我們可以對熱點數據進行緩存，減少這些數據的訪問 路徑，提高用戶體驗。 **利用緩存改善網站性能：**  ### **第4版：使用集群改善應用服務器性能** * 隨著訪問量的繼續增加，單臺應用服務器已經無法滿足需求。在假設數據庫服務器還沒有遇到性能 問題的時候，我們可以增加應用服務器，通過應用服務器集群將用戶請求分流到各個服務器中，從 而繼續提升負載能力。此時多臺應用服務器之間沒有直接的交互，他們都是依賴數據庫各自對外提 供服務。應用服務器前面部署負載均衡服務器調度用戶請求，根據分發策略將請求分發到多個應用 服務器節點。 * 另外，我們還可以增加緩存服務器集群， 來提高訪問速度并降低mysql等數據庫的壓力 **應用服務器集群和緩存服務器集群：**  ### **第5版：數據庫壓力變大，數據庫讀寫分離** * 架構演變到這里，并不是終點。上面我們把應用層的性能拉上來了，但是數據庫的負載也在慢慢增 大，那么怎么去提高數據庫層面的負載呢？有了前面的思路以后，自然會想到增加服務器。但是假 如我們單純的把數據庫一分為二，然后對于后續數據庫的請求，分別負載到兩臺數據庫服務器上， 那么一定會造成數據庫不統一的問題。 所以我們一般先考慮讀寫分離的方式, 。 * 分庫分表不是這個階段要考慮的，是數據庫優化的終極技能，因為會帶來一些難題，所以能不用就 不用。 **數據庫讀寫分離：**  ### **第6版：使用NoSQL和搜索引擎緩解讀庫的壓力** * 數據庫做讀庫的話，常常對模糊查找效率不是特別好，像電商類的網站，搜索是非常核心的功能， 即便是做了讀寫分離，這個問題也不能有效解決。那么這個時候就需要引入Nosql和搜索引擎了。 對于海量數據的查詢和分析，我們使用NoSQL數據庫加上搜索引擎可以達到更好的性能。并不是 所有的數據都要放在關系型數據中。 * 常用的NoSQL有MongoDB、HBase、Redis，搜索引擎有Lucene、Solr、Elasticsearch。 **NoSQL和搜索引擎：**  ### **第7版：使用CDN和反向代理提高網站性能** * 假如我們的服務器都部署在成都的機房，對于四川的用戶來說訪問是較快的，而對于北京的用戶訪 問是較慢的，這是由于四川和北京分別屬于電信和聯通的不同發達地區，北京用戶訪問需要通過互 聯路由器經過較長的路徑才能訪問到成都的服務器，返回路徑也一樣，所以數據傳輸時間比較長。 對于這種情況，常常使用CDN解決，CDN將數據內容緩存到運營商的機房，用戶訪問時先從最近 的運營商獲取數據，這樣大大減少了網絡訪問的路徑。比較專業的CDN運營商有藍汛、網宿 * 而反向代理，則是部署在網站的機房，當用戶請求達到時首先訪問反向代理服務器，反向代理服務 器將緩存的數據返回給用戶，如果沒有緩存數據才會繼續訪問應用服務器獲取，這樣做減少了獲取 數據的成本。反向代理有Squid、Nginx。 **使用 CDN和反向代理提高網站性能：**  ### **第8版 將應用服務器進行業務拆分** * 隨著業務進一步擴展，應用程序變得非常臃腫，這時我們需要將應用程序進行業務拆分，如百度分 為新聞、網頁、圖片等業務。每個業務應用負責相對獨立的業務運作。業務之間通過消息進行通信 或者共享數據庫來實現。 **業務拆分：**  ### **第9版 數據庫的水平、垂直拆分** * 我們的網站演進的變化過程，交易、商品、用戶的數據都在同一個數據庫中，盡管采取了增加緩 存，讀寫分離的方式，但是隨著數據庫的壓力持續增加，數據庫的瓶頸仍然是個最大的問題。因此 我們可以考慮對數據的垂直拆分和水平拆分。 **垂直拆分：把數據庫中不同業務數據拆分到不同的數據庫。**  **水平拆分：把同一個表中的數據拆分到兩個甚至跟多的數據庫中，水平拆分的原因是某些業務數據量已平拆分的原因是某些業務數據量已 經**  ### **第10版 ：服務拆分** * 這時我們發現各個業務應用都會使用到一些基本的業務服務，例如用戶服務、訂單服務、支付服 務、安全服務，這些服務是支撐各業務應用的基本要素。我們將這些服務抽取出來利用分部式服務 框架搭建分布式服務。 **服務拆分：**