上次系列一說到了數據庫讀寫分離，下面接着講解。數據庫
使用反向代理和CDN加速網站響應後端
隨着網站業務不斷髮展，用戶規模愈來愈大，因爲運營商複雜的網絡鏈路，不一樣地區的用戶訪問網站時速度差異極大。有相關研究代表，網站訪問延遲和用戶流失率正相關。爲了提供更好的用戶體驗，留住用戶，網站須要加速訪問速度，主要手段有反向代理和CDN，以下圖所示：緩存
CDN和反向代理的基本原理都是緩存：服務器
CDN部署在運營商的機房，所以用戶在請求網站服務時，能夠從距離本身最近的網絡提供商機房獲取數據。微信
反向代理則部署在網站的中心機房，當用戶請求到達中心機房後，首先訪問的服務器是反向代理服務器，若是反向代理服務器中緩存着用戶請求的資源，就將其直接返回給用戶。網絡
使用CDN和反向代理目的都是爲儘早把請求數據返回給用戶，一方面加快用戶訪問速度，另外一方面減緩後端服務器的負載壓力。架構
使用分佈式文件系統和分佈式數據庫系統分佈式
單一的服務器性能再強大都沒法知足持續增加的業務需求。數據庫通過讀寫分離拆分後，從一臺服務器拆分紅兩臺服務器，可是隨着網站業務的發展依然不能知足業務需求，這時須要使用分佈式數據庫；文件系統也須要使用分佈式文件系統，以下圖所示：微服務
架構相對之前其實更爲精簡。分佈式數據庫是網站數據庫拆分的最後手段，只有在單表數據規模很是龐大的時候纔用到。一般狀況下網站更經常使用業務分庫，將不一樣業務的數據部署在不一樣的物理服務器上。
使用NoSQL和搜索引擎
網站業務又變複雜了，對數據存儲和檢索的需求也愈來愈複雜，網站須要採用一些非關係數據庫技術好比NoSQL和非數據庫查詢技術如搜索引擎，以下圖所示：
NoSQL和搜索引擎都是源自互聯網的技術手段，對可伸縮的分佈式特性具備更好的支持。應用服務器則經過一個統一數據訪問模塊訪問各類數據，減輕應用程序管理諸多數據源的麻煩。
業務拆分
大型網站爲了應對日益複雜的業務場景，經過使用分而治之的手段將整個網站業務分紅不一樣的產品線。如淘寶網站會將首頁、商鋪、訂單、買家、賣家等拆分紅不一樣的產品線，分歸不一樣的業務團隊負責。
具體到技術實現上，也會根據產品線劃分，將一個網站拆分紅許多不一樣的應用，每一個應用獨立部署。應用之間能夠經過一個超連接創建關係，即在首頁上的導航連接每一個都指向不一樣的應用地址，也能夠經過消息隊列進行數據分發。使用最多的仍是經過訪問同一個數據存儲系統來構成一個關聯的完整系統，以下圖所示：
分佈式微服務
隨着業務拆分愈來愈小，存儲系統愈來愈龐大，應用系統的總體複雜度成指數級增長，數據庫的訪問量更加可觀。
既然每一個應用系統都須要執行許多相同的業務操做，好比用戶管理、商品管理等，那麼能夠將共同業務提取出來，獨立部署。由這些可複用的業務連接數據庫提供共同業務服務，而業務系統只須要管理用戶界面，經過分佈式服務調用共同業務完成具體業務操做。以下圖所示：
這幾天你們被拉入新春紅包保障羣（不知道跟淘寶有什麼關係），每天開會開到半夜，公衆號越寫越短了。。下次寫寫中間件：緩存、消息隊列、搜索引擎。
前天機械羣友給我發了兩張照片，是他在廠區旁邊拍的，頗有感觸，咱們生活都不易，只有盡本身最大能力保障家人的生活，共勉。
最後推廣一波個人公衆號：機械猿，歡迎關注。
歷史推文連接：
本文分享自微信公衆號 - 機械猿（on_ourway）。
若有侵權，請聯繫 support@oschina.cn 刪除。
本文參與「OSC源創計劃」，歡迎正在閱讀的你也加入，一塊兒分享。