我們以淘寶架構為例，瞭解下大型電商項目的服務端架構是怎樣的，如圖所示：
- 上面是一些安全體系系統，如數據安全體系、應用安全體系、前端安全體系等。
- 中間是業務運營服務系統，如會員服務、商品服務、店鋪服務、交易服務等。
- 還有共享業務，如分佈式數據層、數據分析服務、配置服務、數據搜索服務等。
- 最下面是中間件服務，如MQS即隊列服務，OCS即緩存服務等。
圖中也有一些看不到，例如高可用的體現、實現雙機房容災和異地機房單元化部署，為淘寶業務提供穩定、高效和易於維護的基礎架構支撐。
這是一個含金量非常高的架構，也是一個非常複雜而龐大的架構。當然這個架構不是一天兩天演進而成，也不是一上來就設計並開發成這麼高大上的。
這邊我想說的是，小型公司要怎麼做架構呢？對很多創業公司而言，很難在初期就預估到流量十倍、百倍以及千倍以後的網站架構會是一個怎樣的狀況。同時，如果系統初期就設計一個千萬級併發的流量架構，也很難有公司可以支撐這個成本。
因此，一個大型服務系統都是從一步一步走過來的，在每個階段，找到對應該階段網站架構所面臨的問題，然後在不斷解決這些問題，在這個過程中整個架構會一直演進。
一、單服務器-俗稱all in one
從一個小網站說起。一臺服務器也就足夠了。文件服務器，數據庫，還有應用都部署在一臺機器，俗稱ALL IN ONE。
隨著我們用戶越來越多，訪問越來越大，硬盤、CPU、內存等都開始吃緊，一臺服務器已經滿足不了。這時看到下一步演進。
二、數據服務與應用服務分離
三、使用緩存
包括本地緩存、遠程緩存、遠程分佈式緩存。
因為 80% 的業務訪問都集中在 20% 的數據上，也就是我們經常說的28法則。如果能將這部分數據緩存下來，性能一下子就上來了。而緩存又分為兩種：本地緩存和遠程緩存緩存，以及遠程分佈式緩存，我們這裡面的遠程緩存圖上畫的是分佈式的緩存集群(Cluster)。
思考的點
- 具有哪種業務特點數據使用緩存？
- 具有哪種業務特點的數據使用本地緩存？
- 具有哪種務特點的數據使用遠程緩存？
- 分佈式緩存在擴容時會碰到什麼問題？如何解決？分佈式緩存的算法都有哪幾種？各有什麼優缺點？
四、使用負載均衡，進行服務器集群
增加了負載均衡、服務器集群之後，我們可以橫向擴展服務器，解決了服務器處理能力的瓶頸。
思考的點
- 負載均衡的調度策略都有哪些？
- 各有什麼優缺點？
- 各適合什麼場景？
打個比方，我們有輪詢、權重、地址散列，地址散列又分為原ip地址散列hash、目標ip地址散列hash，最少連接，加權最少連接，還有繼續升級的很多種策略......我們都來分析一下。
典型負載均衡策略分析
- 輪詢：優點-實現簡單，缺點-不考慮每臺服務器處理能力
- 權重：優點-考慮了服務器處理能力的不同
- 地址散列：優點-能實現同一個用戶訪問同一個服務器
- 最少連接：優點-使集群中各個服務器負載更加均勻
- 加權最少連接：在最少連接的基礎上，為每臺服務器加上權值。算法為(活動連接數*256+非活動連接數)/權重，計算出來的值小的服務器優先被選擇。
繼續引出問題的場景
Session管理-Session Sticky粘滯會話
打個比方，如果我們每次吃飯都要保證用的是自己的碗筷，只要我們在一家飯店裡存著自己的碗筷，並且每次去這家飯店吃飯就好了。
對於同一個連接中的數據包，負載均衡會將其轉發至後端固定的服務器進行處理。
解決了我們session共享的問題，但是它有什麼缺點呢？
一臺服務器運行的服務掛掉，或者重啟，上面的 session 都沒了。
負載均衡器成了有狀態的機器，為以後實現容災造成了羈絆。
Session管理-Session 複製
就像我們在所有的飯店裡都存一份自己的碗筷。這樣隨意去哪一家飯店吃飯都OK，不適合做大規模集群，適合機器不多的情況。
解決了我們session共享的問題，但是它有什麼缺點呢？
應用服務器間帶寬問題，因為需要不斷同步session數據。
大量用戶在線時，服務器佔用內存過多。
Session管理-基於Cookie
打個比方，就是我們每次去飯店吃飯，都帶著自己的碗筷去。
解決了我們session共享的問題，但是它有什麼缺點呢？
cookie 的長度限制。
cookie存於瀏覽器，安全性是一個問題。
Session管理-Session 服務器
打個比方，就是我們的碗筷都存在了一個龐大的櫥櫃裡，我們去任何一家飯店吃飯，都可以從櫥櫃中拿到屬於我們自己的碗筷。
解決了我們session共享的問題，這種方案需要思考哪些問題呢？
保證 session 服務器的可用性，session服務器單點如何解決？
我們在寫應用時需要做調整存儲session的業務邏輯。
打個比方，為了提高session server的可用性，我們可以繼續給session server做集群。
五、中間總結
所以網站架構在遇到某些指標瓶頸、演進的過程中，都有哪些解決方案？它們都有什麼優缺點？業務功能上如何取捨？如何做出選擇？這個過程才是最重要的。
在解決了橫向擴展應用服務器之後，我們繼續回到目前的架構圖：
數據庫的讀及寫操作都還需要經過數據庫。當用戶量達到一定量，數據庫將會成為瓶頸。又該如何解決呢？
六、數據庫讀寫分離
思考的點
- 如何支持多數據源？
- 如何封裝對業務沒有侵入？
- 如何使用目前業務的ORM框架完成主從讀寫分離？是否需要更4. 換ORM模型？ORM模型之間各有什麼優缺點？
- 如何取捨？
數據庫讀寫分離會遇到如下問題：
- 在master和slave複製的時候，考慮延時問題、數據庫的支持、複製條件的支持。
- 當為了提高可用性，將數據庫分機房後，跨機房傳輸同步數據，這個更是問題。
- 應用對於數據源的路由問題。
七、使用反向代理和CDN加速網站響應
八、分佈式文件系統
思考的點
- 分佈式文件系統如何不影響已部署在線上的業務訪問？不能讓某個圖片突然訪問不到呀。
- 是否需要業務部門清洗數據？
- 是否需要重新做域名解析？
這時數據庫又出現了瓶頸。
九、數據垂直拆分
數據庫專庫專用，如圖Products、Users、Deal庫。解決寫數據時併發量大的問題。
思考的點
- 跨業務的事務如何解決？使用分佈式事務、去掉事務或不追求強事務。
- 應用的配置項多了。
- 如何跨庫進行數據的join操作？
這個時候，某個業務的數據表的數據量或者更新量達到了單個數據庫的瓶頸。
十、數據水平拆分
如圖，我們把User拆成了User1和User2，將同一個表的數據拆分到兩個數據庫中，解決了單數據庫的瓶頸。
思考的點
- 水平拆分的策略都有哪些？各有什麼優缺點？
- 水平拆分的時候如何清洗數據？
- SQL的路由問題，需要知道某個User在哪個數據庫上。
- 主鍵的策略會有不同。
假設系統中需要查詢2017年4月份已經下單過的用戶名的明細，而這些用戶分佈在user1和user2上，我們後臺運營系統在展示時如何分頁？
這個時候，公司對外部做了流量導入，我們應用中的搜索量飆升，繼續演進。
十一、拆分搜索引擎
總結
本文只是一個舉例演示，各個服務的技術架構需要根據自己業務特點進行優化和演進，所以大家的過程也不完全相同。
最後的這個示例也不是完美的，例如負載均衡還是一個單點，也需要集群，我們這個架構也只是冰山一角。因為在架構演進的過程中，還要考慮系統的安全性、數據分析、監控、反作弊等，同時往後繼續發展，也要考慮到SOA架構、服務化、消息隊列、任務調度、多機房等。
從以上對架構演進的講解，也可以看出來，所有大型項目的架構和代碼，都是一步一步根據實際的業務場景和發展情況發展演變而來，在不同的階段，會使用的不同的技術，不同的架構來解決實際的問題，所以說，高大上的項目技術架構和開發設計實現不是一蹴而就的。
正是所謂的萬丈高樓平地起。在架構演進的過程中，小到核心模塊代碼，大到核心架構，都會不斷演進的，這個過程值得我們去深入學習和思考。
鏈接：https://www.sohu.com/a/138187117_487514
閱讀更多 生活社會大雜燴 的文章
