eshop1-大型電商架構演進

1. 項目初期

 

2. 服務器分離

以上的服務分離架構，即便文件服務crash 了，可是application server 和 Database Server 繼續能夠訪問運行

 3. 基於併發訪問愈來愈高，數據庫壓力愈來愈大，引入分佈式緩存

80%的數據訪問基於20%的業務數據上，28原則

分佈式緩存思考

（1）.那種業務數據適合遠程分佈式緩存

（2）.那種業務數據適合本地緩存

（3）.分佈式緩存擴容的時候存在的問題，如何解決，算法有哪些

（4）.基於這種架構，咱們須要解決的問題

 4. QPS 訪問愈來愈高，Application Server 將會出現瓶頸，增長負載均衡調度服務器

 

 思考的問題

（1）.負載均衡的調度策略有哪些，各有什麼優缺點，例如輪訓（實現簡單，不考慮服務器的處理能力），權重（考慮服務器處理能力），地址散列（原IP地址散列，目標地址散列， 實現同一個用戶訪問同一個服務器）

（2）.假設一個場景，一個用戶第一次訪問A 服務器，session信息被存儲到A服務器上，可是因爲負載均衡服務器，同一個用戶第二次訪問的時候，訪問了B服務器，可是B服務器上沒有用戶的session信息，所以解決session管理的問題

上圖session 管理缺點

（1）.某一個application server 重啓了，這時候session 所有消失

（2）.第二種session解決方案，session copy

（1）. 解決session共享問題

（2）.缺點Cookie長度是有限制的

（3）.Cookie 保存在瀏覽器上，不安全

所以出現了一下方案

 

缺點

（1）.Session server 是單點，如何保證系統正常的運行

（2）.咱們能夠考慮session server 集羣

（3）.適用於Web服務器session 服務器多的場景

 

5. 當用戶量達到必定數量時，數據庫就會出現瓶頸，如何解決，數據庫的讀寫分離

 

應用接入多數據源

應用程序也應該須要相應的變化

data access module 數據寫入模塊，是開發人員不知道讀寫分離的存在，多數據源對業務代碼無侵入性

當數據的IO很是大的時候，咱們的主庫與附庫在跨機房傳輸的時候，又是一個要解決的問題？

6. 增長CDN 與反向代理服務器，能夠很好的解決不一樣的地區訪問速度的問題

反向代理能夠緩存用戶數據，這個時候咱們的文件服務器可能會出現了瓶頸

7. 文件服務器分佈式集羣

 

分佈式文件系統

（1）.是否須要備份服務器

8. 這個時候，數據庫又出現瓶頸，專庫專用的原則（micro service的設計理念），進行數據的垂直拆分，解決寫數據併發量大的問題

問題：

（1）. 跨數據庫的事務

（2）.可使用分佈式事務

（3）.或者去掉事務，或者不使用強制性事務

隨着數據量，訪問量的變大，咱們每一個業務的數據量已經達到單個數據庫的瓶頸，這個時候進行數據庫水平拆分

 

 解決單數據庫的問題

拆分的時候注意點：

（1）. SQL的路由問題

（2）.既然user表進行了分庫，可是面臨的另一個涉及分頁的問題

9. 當解決這以上問題以後，咱們的搜索又會出現瓶頸，把應用服務器的搜索功能獨立出來，架設一個搜索引擎服務器

 

 

data access module 連接着數據庫，搜索引擎，NoSQL Server

該架構也不是最後的架構，根據實際的業務來決定，例如以上的架構負載均衡服務器是一個單點，所以仍然能夠繼續提高優化空間