1. 程式人生 > >1億使用者的訪問量的伺服器架構

1億使用者的訪問量的伺服器架構

我們以淘寶架構為例,瞭解下大型電商專案的服務端架構是怎樣的,如圖1所示:

上面是一些安全體系系統,如資料安全體系、應用安全體系、前端安全體系等。

中間是業務運營服務系統,如會員服務、商品服務、店鋪服務、交易服務等。

還有共享業務,如分散式資料層、資料分析服務、配置服務、資料搜尋服務等。

最下面是中介軟體服務,如MQS即佇列服務,OCS即快取服務等。

圖片來自包圖網

圖中也有一些看不到,例如高可用的體現、實現雙機房容災和異地機房單元化部署,為淘寶業務提供穩定、高效和易於維護的基礎架構支撐。

假如有1億使用者的訪問量,你的伺服器架構是怎樣的?

圖1

這是一個含金量非常高的架構,也是一個非常複雜而龐大的架構。當然這個架構不是一天兩天演進而成,也不是一上來就設計並開發成這麼高大上的。

這邊我想說的是,小型公司要怎麼做架構呢?對很多創業公司而言,很難在初期就預估到流量十倍、百倍以及千倍以後的網站架構會是一個怎樣的狀況。同時,如果系統初期就設計一個千萬級併發的流量架構,也很難有公司可以支撐這個成本。

因此,一個大型服務系統都是從一步一步走過來的,在每個階段,找到對應該階段網站架構所面臨的問題,然後在不斷解決這些問題,在這個過程中整個架構會一直演進。

一、單伺服器-俗稱all in one 

假如有1億使用者的訪問量,你的伺服器架構是怎樣的?

從一個小網站說起。一臺伺服器也就足夠了。檔案伺服器,資料庫,還有應用都部署在一臺機器,俗稱ALL IN ONE。

隨著我們使用者越來越多,訪問越來越大,硬碟、CPU、記憶體等都開始吃緊,一臺伺服器已經滿足不了。這時看到下一步演進。

二、資料服務與應用服務分離 

假如有1億使用者的訪問量,你的伺服器架構是怎樣的? 

假如有1億使用者的訪問量,你的伺服器架構是怎樣的?

三、使用快取

包括本地快取、遠端快取、遠端分散式快取。 

假如有1億使用者的訪問量,你的伺服器架構是怎樣的?

因為 80% 的業務訪問都集中在 20% 的資料上,也就是我們經常說的28法則。如果能將這部分資料快取下來,效能一下子就上來了。而快取又分為兩種:本地快取和遠端快取快取,以及遠端分散式快取,我們這裡面的遠端快取圖上畫的是分散式的快取叢集(Cluster)。

思考的點

  • 具有哪種業務特點資料使用快取?
  • 具有哪種業務特點的資料使用本地快取?
  • 具有哪種務特點的資料使用遠端快取?
  • 分散式快取在擴容時會碰到什麼問題?如何解決?分散式快取的演算法都有哪幾種?各有什麼優缺點? 

假如有1億使用者的訪問量,你的伺服器架構是怎樣的?

四、使用負載均衡,進行伺服器叢集 

假如有1億使用者的訪問量,你的伺服器架構是怎樣的?

增加了負載均衡、伺服器叢集之後,我們可以橫向擴充套件伺服器,解決了伺服器處理能力的瓶頸。

思考的點

  • 負載均衡的排程策略都有哪些?
  • 各有什麼優缺點?
  • 各適合什麼場景?

打個比方,我們有輪詢、權重、地址雜湊,地址雜湊又分為原ip地址雜湊hash、目標ip地址雜湊hash,最少連線,加權最少連線,還有繼續升級的很多種策略......我們都來分析一下。

典型負載均衡策略分析

  • 輪詢:優點-實現簡單,缺點-不考慮每臺伺服器處理能力
  • 權重:優點-考慮了伺服器處理能力的不同
  • 地址雜湊:優點-能實現同一個使用者訪問同一個伺服器
  • 最少連線:優點-使叢集中各個伺服器負載更加均勻
  • 加權最少連線:在最少連線的基礎上,為每臺伺服器加上權值。演算法為(活動連線數*256+非活動連線數)/權重,計算出來的值小的伺服器優先被選擇。

繼續引出問題的場景 

假如有1億使用者的訪問量,你的伺服器架構是怎樣的? 

Session管理-Session Sticky粘滯會話 

假如有1億使用者的訪問量,你的伺服器架構是怎樣的? 

打個比方,如果我們每次吃飯都要保證用的是自己的碗筷,只要我們在一家飯店裡存著自己的碗筷,並且每次去這家飯店吃飯就好了。

對於同一個連線中的資料包,負載均衡會將其轉發至後端固定的伺服器進行處理。

解決了我們session共享的問題,但是它有什麼缺點呢?

一臺伺服器執行的服務掛掉,或者重啟,上面的 session 都沒了。

負載均衡器成了有狀態的機器,為以後實現容災造成了羈絆。

Session管理-Session 複製 

假如有1億使用者的訪問量,你的伺服器架構是怎樣的? 

就像我們在所有的飯店裡都存一份自己的碗筷。這樣隨意去哪一家飯店吃飯都OK,不適合做大規模叢集,適合機器不多的情況。

解決了我們session共享的問題,但是它有什麼缺點呢?

應用伺服器間頻寬問題,因為需要不斷同步session資料。

大量使用者線上時,伺服器佔用記憶體過多。

Session管理-基於Cookie 

假如有1億使用者的訪問量,你的伺服器架構是怎樣的? 

打個比方,就是我們每次去飯店吃飯,都帶著自己的碗筷去。

解決了我們session共享的問題,但是它有什麼缺點呢?

cookie 的長度限制。

cookie存於瀏覽器,安全性是一個問題。

Session管理-Session 伺服器 

假如有1億使用者的訪問量,你的伺服器架構是怎樣的? 

打個比方,就是我們的碗筷都存在了一個龐大的櫥櫃裡,我們去任何一家飯店吃飯,都可以從櫥櫃中拿到屬於我們自己的碗筷。

解決了我們session共享的問題,這種方案需要思考哪些問題呢?

保證 session 伺服器的可用性,session伺服器單點如何解決?

我們在寫應用時需要做調整儲存session的業務邏輯。

打個比方,為了提高session server的可用性,我們可以繼續給session server做叢集。

五、中間總結

所以網站架構在遇到某些指標瓶頸、演進的過程中,都有哪些解決方案?它們都有什麼優缺點?業務功能上如何取捨?如何做出選擇?這個過程才是最重要的。

在解決了橫向擴充套件應用伺服器之後,我們繼續回到目前的架構圖: 

假如有1億使用者的訪問量,你的伺服器架構是怎樣的? 

資料庫的讀及寫操作都還需要經過資料庫。當用戶量達到一定量,資料庫將會成為瓶頸。又該如何解決呢?

六、資料庫讀寫分離 

假如有1億使用者的訪問量,你的伺服器架構是怎樣的?  

 

假如有1億使用者的訪問量,你的伺服器架構是怎樣的? 

思考的點

  • 如何支援多資料來源?
  • 如何封裝對業務沒有侵入?
  • 如何使用目前業務的ORM框架完成主從讀寫分離?是否需要更4. 換ORM模型?ORM模型之間各有什麼優缺點?
  • 如何取捨?

資料庫讀寫分離會遇到如下問題:

  • 在master和slave複製的時候,考慮延時問題、資料庫的支援、複製條件的支援。
  • 當為了提高可用性,將資料庫分機房後,跨機房傳輸同步資料,這個更是問題。
  • 應用對於資料來源的路由問題。

七、使用反向代理和CDN加速網站響應 

假如有1億使用者的訪問量,你的伺服器架構是怎樣的? 

 

假如有1億使用者的訪問量,你的伺服器架構是怎樣的? 

 八、分散式檔案系統

假如有1億使用者的訪問量,你的伺服器架構是怎樣的? 

思考的點

  • 分散式檔案系統如何不影響已部署在線上的業務訪問?不能讓某個圖片突然訪問不到呀。
  • 是否需要業務部門清洗資料?
  • 是否需要重新做域名解析?

這時資料庫又出現了瓶頸。

九、資料垂直拆分

假如有1億使用者的訪問量,你的伺服器架構是怎樣的?

資料庫專庫專用,如圖Products、Users、Deal庫。解決寫資料時併發量大的問題。

思考的點

  • 跨業務的事務如何解決?使用分散式事務、去掉事務或不追求強事務。
  • 應用的配置項多了。
  • 如何跨庫進行資料的join操作?

這個時候,某個業務的資料表的資料量或者更新量達到了單個數據庫的瓶頸。

十、資料水平拆分 

假如有1億使用者的訪問量,你的伺服器架構是怎樣的? 

如圖,我們把User拆成了User1和User2,將同一個表的資料拆分到兩個資料庫中,解決了單資料庫的瓶頸。

思考的點

  • 水平拆分的策略都有哪些?各有什麼優缺點?
  • 水平拆分的時候如何清洗資料?
  • SQL的路由問題,需要知道某個User在哪個資料庫上。
  • 主鍵的策略會有不同。

假設系統中需要查詢2017年4月份已經下單過的使用者名稱的明細,而這些使用者分佈在user1和user2上,我們後臺運營系統在展示時如何分頁?

這個時候,公司對外部做了流量匯入,我們應用中的搜尋量飆升,繼續演進。

十一、拆分搜尋引擎 

假如有1億使用者的訪問量,你的伺服器架構是怎樣的?  

 

假如有1億使用者的訪問量,你的伺服器架構是怎樣的? 

總結

本文只是一個舉例演示,各個服務的技術架構需要根據自己業務特點進行優化和演進,所以大家的過程也不完全相同。

最後的這個示例也不是完美的,例如負載均衡還是一個單點,也需要叢集,我們這個架構也只是冰山一角。因為在架構演進的過程中,還要考慮系統的安全性、資料分析、監控、反作弊等,同時往後繼續發展,也要考慮到SOA架構、服務化、訊息佇列、任務排程、多機房等。

從以上對架構演進的講解,也可以看出來,所有大型專案的架構和程式碼,都是一步一步根據實際的業務場景和發展情況發展演變而來,在不同的階段,會使用的不同的技術,不同的架構來解決實際的問題,所以說,高大上的專案技術架構和開發設計實現不是一蹴而就的。

正是所謂的萬丈高樓平地起。在架構演進的過程中,小到核心模組程式碼,大到核心架構,都會不斷演進的,這個過程值得我們去深入學習和思考。