前言
前幾天開始拜讀這本書, 通俗易懂, 筆記如下(未更新完成)
正文
大型業務的系統特點
- 高并發
- 大流量
- 高可用
- 海量資料
- 使用者分布廣泛
- 網絡情況負載
- 安全環境惡劣
- 需求快速變更
- 快速疊代
最初的小型業務的架構
LAMP = Linux+Apache+MySQL+PHP
網站的架構變化
- 一台伺服器放置LAMP
- 三台伺服器存放 應用/檔案服務/資料庫服務
- 增加本地緩存/分布式緩存伺服器
- 應用伺服器增加叢集
- 資料庫讀寫分離
- CDN和反向代理
- 分布式檔案系統和分布式資料庫
- 使用NOSQL和ES
- 将業務進行拆分
根據業務來确定網站架構, 多大的業務量決定使用什麼架構, 合适的才是最好的
技術架構為業務服務, 切勿本末倒置
網站架構的設計誤區
- 一味追尋大公司的解決方案
- 為了技術而技術, 脫離實際情況
- 企圖使用技術解決所有問題(為什麼不試試調整業務呢?)
網站架構模式
分層
- 應用層: 負責具體業務和視圖展示, 網站首頁和搜尋輸入和結果展示(前段)
- 服務層: 為應用層提供服務支援, 使用者管理服務, 購物車服務(接口)
- 資料層: 資料的存儲和通路服務, 資料庫/緩存/檔案/搜尋(資料)
分割
将網站按照子產品進行分割, 邏輯與實體都分割, 提高并發處理能力和功能擴充能力
分布式
将分割後的子產品進行分布式部署
好處
提高并發與資料處理能力
問題
- 網絡通訊造成的性能損耗
- 某一個伺服器當機造成的網站可用性降低
- 資料在分布式環境中的資料一緻性問題
- 事務問題
- 網站依賴關系複雜, 開發/管理/維護困難
分布式方案
- 分布式應用和服務: 将分割後的接口進行分布式部署, 可以改善網站性能和并發性,有利于業務功能擴充, 對于開發這個子產品的人來說, 可以加快開發速度
- 分布式靜态資源: 将靜态資源獨立分布式部署, 動靜分離, 加快加載速度, 優化使用者體驗
- 分布式資料和存儲: 将資料分布式存儲, 提高效率
- 分布式計算: 将對計算要求高的邏輯使用分布式計算架構配置設定到其他機器進行計算, 提高效率
緩存
- CDN: 将一些靜态資源和較少變化的資料和熱點資料存放在緩存中, 使用者通路時優先通路緩存
- 反向代理: 反向代理服務配置緩存
- 本地緩存: 在應用程式設計的本地存放緩存, 一般是存放在記憶體中
- 分布式緩存: 将緩存存放在分布式緩存叢集中
什麼時候适合使用緩存: 需要頻繁通路的資料/在某個時段内有效的資料
異步
将要處理的資料存放進隊列中, 由消費者去消費
- 提高系統可用性: 消費者發生問題時生産者可以繼續入隊
- 加快響應速度: 耗時的操作不需要等待即可傳回, 減少響應延遲
- 消除并發通路高峰: 通路量大的時候也由消費者依次處理, 減輕壓力
異步要和産品的業務相關, 有些時候無法使用異步
備援
某個伺服器當機時一定要保持重要資料的不丢失, 是以需要一定數量的伺服器 備援運作, 目的是在正常情況下, 這些伺服器是不參與正常的業務流程的, 當線上的伺服器發生故障時, 再啟動對應的備援伺服器承接業務, 保證服務的正常運作, 一般的, 像網關之類的(一台伺服器即可, 但是挂掉對整個架構的影響較大)服務必須要設定備援
備援可以實作服務的高可用
備份
- 冷備份:資料庫中的資料也需要定時備份與存檔, 這叫資料冷備份
- 熱備份:資料庫的高可用就是總從分離, 資料庫會進行同步更新資料, 這種随時更改随時同步的方法叫熱備份
- 災備資料中心:特别大的業務, 為了抵禦遇到大停電/地震/海嘯等不可抗力導緻的業務癱瘓, 在各地有災備資料中心, 盡可能的減少損失
自動化
- 釋出過程自動化: 自動化釋出系統, 減少釋出過程因為人為失誤導緻的問題
- 自動化代碼管理: 代碼版本控制/分支控制等自動化
- 自動化測試: 送出測試後由系統進行自動化用例測試
- 自動化安全檢測: 通過安全檢測工具檢測代碼
- 自動化部署: 自動部署到線上環境
- 自動化監控: 對線上的各項名額進行監控, 通過服務中心對叢集機器性能進行監控
- 自動化報警: 檢測到名額達到某一個閥值時自動向相關人員通過短信/手機等方式報警
- 自動化失效轉移: 檢測到叢集的某個伺服器挂掉後自動将其剝離出業務, 等待開發人員修複
- 自動化失效恢複: 監測到服務正常後自動加入到業務中
- 自動化降級: 網站持續告警時, 關閉一些不重要的服務, 将資源釋放出來給重要的服務保障業務的安全可用
核心架構要素
性能
一個打開緩慢的網站會導緻嚴重的使用者流失, 除非是沒的選擇
優化措施:
- 前端利用浏覽器緩存/頁面壓縮/合理布局頁面/減少cookie傳輸來改善性能
- 架構使用CDN/反向代理/緩存熱點檔案來加快響應速度減輕伺服器壓力
- 後端使用本地緩存和分布式緩存加快請求處理過程,減輕資料庫壓力
- 是否可以将業務修改為異步
- 叢集/多線程/SQL優化等
可用性
網站當機/服務不可用屬于重大失誤, 輕則影響網站聲譽, 重則攤上官司. 而且大機率會損失金錢和使用者
- 備援, 應用部署在多個伺服器同時提供服務, 資料在多個伺服器互相備份
- 服務叢集, 負載均衡, 前提是應用伺服器不能儲存請求的會話資訊以免出現問題切換到另一台機器時無法完成業務處理
- 資料庫叢集, 資料采用冷備份和熱備份同時運作的方式
伸縮性
伸縮性指通過不斷向叢集中加入伺服器來緩解不斷上升的業務量和資料存儲需求
衡量伸縮性的主要标準就是是否可以使用堕胎伺服器建構叢集, 是否容易向叢集中添加新的伺服器, 加入新的伺服器後是否可以提高和原來的伺服器無差别的服務, 叢集中可以容納的總伺服器數量是否有限制
- 應用伺服器叢集: 伺服器上不儲存資料, 所有伺服器都是對等的, 通過使用合适的負載均衡裝置就可以向叢集中不斷加入伺服器
- 緩存伺服器叢集: 加入新的伺服器可能導緻緩存路由失敗, 導緻叢集中大部分緩存資料無法通路. 雖然緩存的資料可以通過資料庫重新加載, 但是如果應用嚴重依賴緩存, 可能會導緻整個網站崩潰, 需要改進緩存的路由算法保證緩存資料的可通路性
- 關系型資料庫: 資料庫本身很難做到大規模叢集的可伸縮性,是以必須在資料庫外實作, 例如通過邏輯分區将某一部分邏輯的多個資料庫伺服器組成叢集
- NoSQL: 天生就為海量的資料而生, 是以對伸縮性支援很好
擴充性
網站的擴充性架構直接關注網站的功能需求, 網站的功能快速疊代, 擴充性的提高可以使其快速響應需求的變化
衡量網站架構性的标準是在網站增加新的業務産品時, 是否影響現有産品, 是否不需要改動或很少改動現有産品即可上線新的産品, 不同産品之間是否很少耦合, 一個産品的改動是否對其他産品有影響, 其他産品是否不需要改動
- 事件驅動架構: 事件驅動通常使用消息隊列實作, 消息産生後加入隊列, 由消費者服務進行消費, 通過這種方式将消費者和生産者分開, 透明的增加新的生産者或消費者
- 分布式服務: 将業務和可複用服務分離, 通過分布式架構調用, 新增産品通過調用可複用的服務實作自身的業務邏輯, 對現有的産品沒有任何影響. 可複用服務更新時要注意多版本的相容, 實作透明更新
- 大的網站為了保持市場地位和覆寫率, 會提供開放平台接口供第三方開發者調用
安全性
網際網路是開放的, 任何人在任何地方都可以通路網站, 網站的安全架構就是保護網站不受惡意通路和攻擊, 保護重要資料不被竊取
作者：ChnMig
出處：http://www.cnblogs.com/chnmig/
本文版權歸作者和部落格園所有，歡迎轉載。轉載請在留言闆處留言給我，且在文章标明原文連結，謝謝！如果您覺得本篇博文對您有所收獲，覺得我還算用心，請點選左下角的 [推薦]，謝謝！