架構高可用高併發系統的設計原則

時間 2019-11-16

原文原文鏈接

架構設計三大定律css

墨菲定律 – 任何事沒有表面看起來那麼簡單 – 全部的事都會比預計的時間長 – 可能出錯的事情總會出錯 – 擔憂某種事情發生，那麼它就更有可能發生html

康威定律 – 系統架構師公司組織架構的反映 – 按照業務閉環進行系統拆分/組織架構劃分，實現閉環、高內聚、低耦合，減小溝通成本 – 若是溝通出現問題，應該考慮進行系統和組織架構的調整 – 適合時機進行系統拆分，不要一開始就吧系統、服務拆分拆的很是細，雖然閉環，可是每一個人維護的系統多，維護成本高 – 微服務架構的理論基礎 – 康威定律 https://yq.aliyun.com/articles/8611 – 每一個架構師都應該研究下康威定律 http://36kr.com/p/5042735.html後端

二八定律 – 80%的結果取決於20%的緣由瀏覽器

系統設計遵循的原則緩存

1.高併發原則服務器

無狀態架構

無狀態應用，便於水平擴展
有狀態配置可經過配置中心實現無狀態
實踐: Disconf、Yaconf、Zookpeer、Consul、Confd、Diamond、Xdiamond等

拆分併發

系統維度：按照系統功能、業務拆分，如購物車，結算，訂單等
功能維度：對系統功能在作細粒度拆分
讀寫維度：根據讀寫比例特徵拆分；讀多，可考慮多級緩存；寫多，可考慮分庫分表
AOP維度：根據訪問特徵，按照AOP進行拆分，好比商品詳情頁可分爲CDN、頁面渲染系統，CDN就是一個AOP系統
模塊維度：對總體代碼結構劃分Web、Service、DAO

服務化負載均衡

服務化演進: 進程內服務-單機遠程服務-集羣手動註冊服務-自動註冊和發現服務-服務的分組、隔離、路由-服務治理
考慮服務分組、隔離、限流、黑白名單、超時、重試機制、路由、故障補償等
實踐：利用Nginx、HaProxy、LVS等實現負載均衡，ZooKeeper、Consul等實現自動註冊和發現服

消息隊列異步

目的: 服務解耦(一對多消費)、異步處理、流量削峯緩衝等
大流量緩衝：犧牲強一致性，保證最終一致性(案例：庫存扣減，如今Redis中作扣減，記錄扣減日誌，經過後臺進程將扣減日誌應用到DB)
數據校對: 解決異步消息機制下消息丟失問題

數據異構

數據異構: 經過消息隊列機制接收數據變動，原子化存儲
數據閉環: 屏蔽多從數據來源，將數據異構存儲，造成閉環

緩存銀彈

用戶層:
- DNS緩存
- 瀏覽器DNS緩存
- 操做系統DNS緩存
- 本地DNS服務商緩存
- DNS服務器緩存
- 客戶端緩存
- 瀏覽器緩存(Expires、Cache-Control、Last-Modified、Etag)
- App客戶緩存(js/css/image…)
代理層：
- CDN緩存(通常基於ATS、Varnish、Nginx、Squid等構建,邊緣節點-二級節點-中心節點-源站)
接入層：
- Opcache：緩存PHP的Opcodes
- Proxy_cache：代理緩存,能夠存儲到/dev/shm或者SSD
- FastCGI Cache
- Nginx+Lua+Redis: 業務數據緩存
- Nginx爲例：
- PHP爲例：
應用層：
- 頁面靜態化
- 業務數據緩存(Redis/Memcached/本地文件等)
- 消息隊列
數據層：
- NoSQL： Redis、Memcache、SSDB等
- MySQL： Innodb/MyISAM等Query Cache、Key Cache、Innodb Buffer Size等
系統層：
- CPU : L1/L2/L3 Cache/NUMA
- 內存
- 磁盤：磁盤自己緩存、dirtyratio/dirtybackground_ratio、陣列卡自己緩存