大型專案架構演程序序及思考

淘寶架構

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

上面是一些安全體系系統，如資料安全體系、應用安全體系、前端安全體系等，
中間是業務運營服務系統，如會員服務、商品服務、店鋪服務、交易服務等，
還有共享業務，如分布式資料層、資料分析服務、配置服務、資料搜索服務等，
最下面呢，是中間件服務，如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架構、服務化、訊息佇列、任務調度、多機房等等… ...

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

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

 公眾號【菜鳥路程】領取視瞥澩

標籤：架構設計

上一篇：分布式主鍵解決方案之--Snowflake雪花演算法

下一篇：spring cloud 之 -- eureka vs consul，該選擇誰？