大型項目架構演進過程及思考

淘寶架構

咱們以淘寶架構爲例，瞭解下大型的電商項目的服務端的架構是怎樣，如圖所示

上面是一些安全體系系統，如數據安全體系、應用安全體系、前端安全體系等。
中間是業務運營服務系統，如會員服務、商品服務、店鋪服務、交易服務等。
還有共享業務，如分佈式數據層、數據分析服務、配置服務、數據搜索服務等。
最下面呢，是中間件服務，如MQS即隊列服務，OCS即緩存服務等。

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

這是一個含金量很是高的架構，也是一個很是複雜而龐大的架構。固然這個也不是一天兩天演進成這樣的，也不是一上來就設計並開發成這樣高大上的架構的。

這邊就要說一下，小型公司要怎麼作呢？對不少創業公司而言，很難在初期就預估到流量十倍、百倍以及千倍之後網站架構會是什麼樣的一個情況。同時，若是系統初期就設計一個千萬級併發的流量架構，很難有公司能夠支撐這個成本。

所以，一個大型服務系統都是從小一步一步走過來的，在每一個階段，找到對應該階段網站架構所面臨的問題，而後在不斷解決這些問題，在這個過程當中整個架構會一直演進。
那咱們來一塊兒看一下。

單服務器-俗稱all in one

從一個小網站提及。一臺服務器也就足夠了。文件服務器，數據庫，還有應用都部署在一臺機器，俗稱ALL IN ONE

隨着咱們用戶愈來愈多，訪問愈來愈大，硬盤，CPU，內存等都開始吃緊。一臺服務器已經知足不了。這個時候看一下下一步演進

數據服務與應用服務分離

 

 

 

咱們將數據服務和應用服務分離，給應用服務器配置更好的 CPU，內存。而給數據服務器配置更好更大的硬盤。

分離以後提升必定的可用性，例如Files Server掛了，咱們仍是能夠操做應用和數據庫等。
隨着訪問qps愈來愈高，下降接口訪問時間，提升服務性能和併發，成爲了咱們下一個目標，發現有不少業務數據不須要每次都從數據庫獲取。

使用緩存，包括本地緩存，遠程緩存，遠程分佈式緩存

 

 

 

由於 80% 的業務訪問都集中在 20% 的數據上，也就是咱們常常說的28法則。若是咱們能將這部分數據緩存下來，性能一會兒就上來了。而緩存又分爲兩種：本地緩存和遠程緩存緩存，以及遠程分佈式緩存，咱們這裏面的遠程緩存圖上畫的是分佈式的緩存集羣(Cluster)。

思考的點

1. .          具備哪一種業務特色數據使用緩存？
2. .          具備哪一種業務特色的數據使用本地緩存？
3. .          具備哪一種務特色的數據使用遠程緩存？
4. .          分佈式緩存在擴容時候會碰到什麼問題？如何解決？分佈式緩存的算法都有哪幾種？各有什麼優缺點？

這個時候隨着訪問qps的提升，服務器的處理能力會成爲瓶頸。雖然是能夠經過購買更強大的硬件，但總會有上限，並且這個到後期成本就是指數級增加了，這時，咱們就須要服務器的集羣。須要使咱們的服務器能夠橫向擴展，這時，就必須加個新東西：負載均衡調度服務器。

使用負載均衡，進行服務器集羣

 

 

增長了負載均衡，服務器集羣以後，咱們能夠橫向擴展服務器，解決了服務器處理能力的瓶頸。

思考的點

1. .          負載均衡的調度策略都有哪些？
2. .          各有什麼優缺點？
3. .          各適合什麼場景？

打個比方，咱們有輪詢，權重，地址散列，地址散列又分爲原ip地址散列hash，目標ip地址散列hash，最少鏈接，加權最少鏈接，還有繼續升級的不少種策略......咱們一塊兒來分析一下

典型負載均衡策略分析

1. .          輪詢：優勢：實現簡單，缺點：不考慮每臺服務器處理能力
2. .          權重：優勢：考慮了服務器處理能力的不一樣
3. .          地址散列：優勢：能實現同一個用戶訪問同一個服務器
4. .          最少鏈接：優勢：使集羣中各個服務器負載更加均勻
5. .          加權最少鏈接：在最少鏈接的基礎上，爲每臺服務器加上權值。算法爲(活動鏈接數*256+非活動鏈接數)/權重，計算出來的值小的服務器優先被選擇。

繼續引出問題的場景：

咱們的登陸的時候登陸了A服務器，session信息存儲到A服務器上了，假設咱們使用的負載均衡策略是ip hash，那麼登陸信息還能夠從A服務器上訪問，可是這個有可能形成某些服務器壓力過大，某些服務器又沒有什麼壓力，這個時候壓力過大的機器(包括網卡帶寬)有可能成爲瓶頸，而且請求不夠分散。

這時候咱們使用輪詢或者最小鏈接負載均衡策略，就致使了，第一次訪問A服務器，第二次可能訪問到B服務器，這個時候存儲在A服務器上的session信息在B服務器上讀取不到。

Session管理-Session Sticky粘滯會話：

 

 

 

打個比方就是若是咱們每次吃飯都要保證咱們用的是本身的碗筷，而只要咱們在一家飯店裏存着咱們的碗筷，只要咱們每次去這家飯店吃飯就行了。

對於同一個鏈接中的數據包，負載均衡會將其轉發至後端固定的服務器進行處理。

解決了咱們session共享的問題，可是它有什麼缺點呢？

1. .          一臺服務器運行的服務掛掉，或者重啓，上面的 session 都沒了
2. .          負載均衡器成了有狀態的機器，爲之後實現容災形成了羈絆

Session管理-Session 複製

 

就像咱們在全部的飯店裏都存一份本身的碗筷。咱們隨意去哪一家飯店吃飯都OK，不適合作大規模集羣，適合機器很少的狀況。

解決了咱們session共享的問題，可是它有什麼缺點呢？

1. .          應用服務器間帶寬問題，由於須要不斷同步session數據
2. .          大量用戶在線時，服務器佔用內存過多

Session管理-基於Cookie

 

 

 

打個比方，就是咱們每次去飯店吃飯，都本身帶着本身的碗筷。

解決了咱們session共享的問題，可是它有什麼缺點呢？

1. .          cookie 的長度限制
2. .          cookie存於瀏覽器，安全性是一個問題

Session管理-Session 服務器

 

 

 

打個比方，就是咱們的碗筷都存在了一個龐大的櫥櫃裏，咱們去任何一家飯店吃飯，均可以從櫥櫃中拿到屬於咱們本身的碗筷。

解決了咱們session共享的問題，這種方案須要思考哪些問題呢？

1. .          保證 session 服務器的可用性，session服務器單點如何解決？
2. .          咱們在寫應用時須要作調整存儲session的業務邏輯

打個比方，咱們爲了提升session server的可用性，能夠繼續給session server作集羣

中間總結

因此說，網站架構在遇到某些指標瓶頸時，演進的過程當中，都有哪些解決方案，他們都有什麼優缺點？業務功能上如何取捨？如何作出選擇？這個過程纔是最重要的。

在解決了橫向擴展應用服務器以後，那咱們繼續~~

繼續回到目前架構圖

 

 

 

數據庫的讀及寫操做都還須要通過數據庫。當用戶量達到必定量，數據庫將會成爲瓶頸。那咱們如何來解決呢？

數據庫讀寫分離

 

 

 

使用數據庫提供的熱備功能，將全部的讀操做引入slave 服務器，由於數據庫的讀寫分離了，因此，咱們的應用程序也得作相應的變化。咱們實現一個數據訪問模塊(圖中的data access module)使上層寫代碼的人不知道讀寫分離的存在。這樣多數據源讀寫分離就對業務代碼沒有了侵入。這裏就引出了代碼層次的演變

思考的點

1. .          如何支持多數據源？
2. .          如何封裝對業務沒有侵入？
3. .          如何使用目前業務的ORM框架完成主從讀寫分離？是否須要更換ORM模型？ORM模型之間各有什麼優缺點？
4. .          如何取捨？

數據庫讀寫分離會遇到以下問題：

1. .          在master和slave複製的時候，考慮延時問題、數據庫的支持、複製條件的支持。
2. .          當爲了提升可用性，將數據庫分機房後，跨機房傳輸同步數據，這個更是問題。
3. .          應用對於數據源的路由問題

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

 

 

 

使用 CDN 能夠很好的解決不一樣的地區的訪問速度問題，反向代理則在服務器機房中緩存用戶資源。

訪問量愈來愈大，咱們文件服務器也出現了瓶頸。

分佈式文件系統

 

 

 

思考的點

1. .          分佈式文件系統如何不影響已部署在線上的業務訪問？不能讓某個圖片忽然訪問不到呀
2. .          是否須要業務部門清洗數據？
3. .          是否須要從新作域名解析？

這個時候數據庫又出現了瓶頸

數據垂直拆分

 

 

 

數據庫專庫專用，如圖Products、Users、Deal庫。

解決寫數據時，併發，量大的問題。

思考的點

1. .          跨業務的事務？如何解決？使用分佈式事務、去掉事務或不追求強事務
2. .          應用的配置項多了
3. .          如何跨庫進行數據的join操做

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

數據水平拆分

 

 

 

如圖，咱們把User拆成了User1和User2，將同一個表的數據拆分到兩個數據庫中，解決了單數據庫的瓶頸。

思考的點

1. .          水平拆分的策略都有哪些？各有什麼優缺點？
2. .          水平拆分的時候如何清洗數據？
3. .          SQL 的路由問題，須要知道某個 User 在哪一個數據庫上。
4. .          主鍵的策略會有不一樣。
5. .          假設咱們系統中須要查詢2017年4月份已經下單過的用戶名的明細，而這些用戶分佈在user1和user2上，咱們後臺運營系統在展現時如何分頁？

這個時候，公司對外部作了流量導入，咱們應用中的搜索量飆升，繼續演進

拆分搜索引擎

 

 

 

使用搜索引擎，解決數據查詢問題。部分場景可以使用 NoSQL 提升性能，開發數據統一訪問模塊，解決上層應用開發的數據源問題。如圖data access module 能夠訪問數據庫，搜索引擎，NoSQL

最後總結

這個只是一個舉例演示，各個服務的技術架構是須要根據本身業務特色進行優化和演進的，因此你們的過程也不徹底相同。

最後的這個也不是完美的，例如負載均衡仍是一個單點，也須要集羣，咱們的這個架構呢也只是冰山一角，滄海一粟。在架構演進的過程當中，還要考慮系統的安全性、數據分析、監控、反做弊等等......，同時繼續發展呢，SOA架構、服務化、消息隊列、任務調度、多機房等等… ...

從剛纔對架構演進的講解，也能夠看出來，全部大型項目的架構和代碼，都是這麼一步一步的根據實際的業務場景，和發展狀況發展演變而來的，在不一樣的階段，會使用的不一樣的技術，不一樣的架構來解決實際的問題，因此說，高大上的項目技術架構和開發設計實現不是一蹴而就的。

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