如何設計一個牛掰的大型專案架構？
大型電商專案的服務端架構
我們以淘寶架構為例，瞭解下大型電商專案的服務端架構是怎樣的，如圖所示：
- 上面是一些安全體系系統，如資料安全體系、應用安全體系、前端安全體系等。
- 中間是業務運營服務系統，如會員服務、商品服務、店鋪服務、交易服務等。
- 還有共享業務，如分散式資料層、資料分析服務、配置服務、資料搜尋服務等。
- 最下面是中介軟體服務，如MQS即佇列服務，OCS即快取服務等。
圖中也有一些看不到，例如高可用的體現、實現雙機房容災和異地機房單元化部署，為淘寶業務提供穩定、高效和易於維護的基礎架構支撐。
這是一個含金量非常高的架構，也是一個非常複雜而龐大的架構。當然這個架構不是一天兩天演進而成，也不是一上來就設計並開發成這麼高大上的。
這邊我想說的是，小型公司要怎麼做架構呢？對很多創業公司而言，很難在初期就預估到流量十倍、百倍以及千倍以後的網站架構會是一個怎樣的狀況。同時，如果系統初期就設計一個千萬級併發的流量架構，也很難有公司可以支撐這個成本。
因此，一個大型服務系統都是從一步一步走過來的，在每個階段，找到對應該階段網站架構所面臨的問題，然後在不斷解決這些問題，在這個過程中整個架構會一直演進。
一、單伺服器-俗稱all in one
從一個小網站說起。一臺伺服器也就足夠了。檔案伺服器，資料庫，還有應用都部署在一臺機器，俗稱ALL IN ONE。
隨著我們使用者越來越多，訪問越來越大，硬碟、CPU、記憶體等都開始吃緊，一臺伺服器已經滿足不了。這時看到下一步演進。
二、資料服務與應用服務分離
我們將資料服務和應用服務分離，給應用伺服器配置更好的CPU和記憶體，給資料伺服器配置更好更大的硬碟。
分離之後提高一定的可用性，例如Files Server掛了，我們還是可以操作應用和資料庫等。
隨著訪問QPS越來越高，降低介面訪問時間，提高服務效能和併發，成為了我們下一個目標，同時發現有很多業務資料不需要每次都從資料庫獲取。
三、使用快取
包括本地快取、遠端快取、遠端分散式快取。
因為 80% 的業務訪問都集中在 20% 的資料上，也就是我們經常說的28法則。如果能將這部分資料快取下來，效能一下子就上來了。而快取又分為兩種：本地快取和遠端快取快取，以及遠端分散式快取，我們這裡面的遠端快取圖上畫的是分散式的快取叢集(Cluster)。
思考的點
- 具有哪種業務特點資料使用快取？
- 具有哪種業務特點的資料使用本地快取？
- 具有哪種務特點的資料使用遠端快取？
- 分散式快取在擴容時會碰到什麼問題？如何解決？分散式快取的演算法都有哪幾種？各有什麼優缺點？
這個時候隨著訪問QPS的提高，伺服器的處理能力會成為瓶頸。雖然可以通過購買更強大的硬體解決，但總會有上限，而且這個到後期成本就是指數級增長了，這時，我們需要伺服器的叢集來橫向擴充套件，所以就必須加個新東西：負載均衡排程伺服器。
四、使用負載均衡，進行伺服器叢集
增加了負載均衡、伺服器叢集之後，我們可以橫向擴充套件伺服器，解決了伺服器處理能力的瓶頸。
思考的點
- 負載均衡的排程策略都有哪些？
- 各有什麼優缺點？
- 各適合什麼場景？
打個比方，我們有輪詢、權重、地址雜湊，地址雜湊又分為原ip地址雜湊hash、目標ip地址雜湊hash，最少連線，加權最少連線，還有繼續升級的很多種策略……我們都來分析一下。
典型負載均衡策略分析
- 輪詢：優點-實現簡單，缺點-不考慮每臺伺服器處理能力
- 權重：優點-考慮了伺服器處理能力的不同
- 地址雜湊：優點-能實現同一個使用者訪問同一個伺服器
- 最少連線：優點-使叢集中各個伺服器負載更加均勻
- 加權最少連線：在最少連線的基礎上，為每臺伺服器加上權值。演算法為(活動連線數*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共享的問題，這種方案需要思考哪些問題呢？
- 保證 session 伺服器的可用性，session伺服器單點如何解決？
- 我們在寫應用時需要做調整儲存session的業務邏輯。
打個比方，為了提高session server的可用性，我們可以繼續給session server做叢集。
五、中間總結
所以網站架構在遇到某些指標瓶頸、演進的過程中，都有哪些解決方案？它們都有什麼優缺點？業務功能上如何取捨？如何做出選擇？這個過程才是最重要的。
在解決了橫向擴充套件應用伺服器之後，我們繼續回到目前的架構圖：
資料庫的讀及寫操作都還需要經過資料庫。當用戶量達到一定量，資料庫將會成為瓶頸。又該如何解決呢？
六、資料庫讀寫分離
使用資料庫提供的熱備功能，將所有的讀操作引入slave 伺服器，因為資料庫的讀寫分離了，所以我們的應用程式也得做出相應的變化。我們實現了一個數據訪問模組(圖中的data access module)，使上層寫程式碼的人不知道讀寫分離的存在。這樣多資料來源讀寫分離就對業務程式碼沒有了侵入。同時這裡引出了程式碼層次的演變。
思考的點
- 如何支援多資料來源？
- 如何封裝對業務沒有侵入？
- 如何使用目前業務的ORM框架完成主從讀寫分離？是否需要更4. 換ORM模型？ORM模型之間各有什麼優缺點？
- 如何取捨？
資料庫讀寫分離會遇到如下問題：
- 在master和slave複製的時候，考慮延時問題、資料庫的支援、複製條件的支援。
- 當為了提高可用性，將資料庫分機房後，跨機房傳輸同步資料，這個更是問題。
- 應用對於資料來源的路由問題。
七、使用反向代理和CDN加速網站響應
使用 CDN 可以很好地解決不同的地區的訪問速度問題，反向代理則在伺服器機房中快取使用者資源。
訪問量越來越大，我們檔案伺服器也出現了瓶頸。
八、分散式檔案系統
思考的點
- 分散式檔案系統如何不影響已部署在線上的業務訪問？不能讓某個圖片突然訪問不到呀。
- 是否需要業務部門清洗資料？
- 是否需要重新做域名解析？
這時資料庫又出現了瓶頸。
九、資料垂直拆分
資料庫專庫專用，如圖Products、Users、Deal庫。解決寫資料時併發量大的問題。
思考的點
- 跨業務的事務如何解決？使用分散式事務、去掉事務或不追求強事務。
- 應用的配置項多了。
- 如何跨庫進行資料的join操作？
這個時候，某個業務的資料表的資料量或者更新量達到了單個數據庫的瓶頸。
十、資料水平拆分
如圖，我們把User拆成了User1和User2，將同一個表的資料拆分到兩個資料庫中，解決了單資料庫的瓶頸。
思考的點
- 水平拆分的策略都有哪些？各有什麼優缺點？
- 水平拆分的時候如何清洗資料？
- SQL的路由問題，需要知道某個User在哪個資料庫上。
- 主鍵的策略會有不同。
- 假設系統中需要查詢2017年4月份已經下單過的使用者名稱的明細，而這些使用者分佈在user1和user2上，我們後臺運營系統在展示時如何分頁？
這個時候，公司對外部做了流量匯入，我們應用中的搜尋量飆升，繼續演進。
十一、拆分搜尋引擎
使用搜索引擎，解決資料查詢問題。部分場景可使用NoSQL提高效能，開發資料統一訪問模組，解決上層應用開發的資料來源問題。如圖data access module 可以訪問資料庫、搜尋引擎、NoSQL。
總結
本文只是一個舉例演示，各個服務的技術架構需要根據自己業務特點進行優化和演進，所以大家的過程也不完全相同。
最後的這個示例也不是完美的，例如負載均衡還是一個單點，也需要叢集，我們這個架構也只是冰山一角。因為在架構演進的過程中，還要考慮系統的安全性、資料分析、監控、反作弊等，同時往後繼續發展，也要考慮到SOA架構、服務化、訊息佇列、任務排程、多機房等。
從以上對架構演進的講解，也可以看出來，所有大型專案的架構和程式碼，都是一步一步根據實際的業務場景和發展情況發展演變而來，在不同的階段，會使用的不同的技術，不同的架構來解決實際的問題，所以說，高大上的專案技術架構和開發設計實現不是一蹴而就的。
正是所謂的萬丈高樓平地起。在架構演進的過程中，小到核心模組程式碼，大到核心架構，都會不斷演進的，這個過程值得我們去深入學習和思考。
作者介紹： 吳昊
- 2014年加入Qunar，目前在去哪兒網玩樂事業部擔任Java開發工程師。熱愛技術，喜歡分享。
文章來自微信公眾號：DBA plus社群