架構學習之路——高可用高併發系統設計原則 (轉)

做者 Geekwolf

本文做者爲網易高級運維工程師

本文主要是學習開濤《億級流量網站架構核心技術》一書學習筆記及本身的感悟：

架構設計三大定律

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

康威定律 - 系統架構師公司組織架構的反映 - 按照業務閉環進行系統拆分/組織架構劃分，實現閉環、高內聚、低耦合，減小溝通成本 - 若是溝通出現問題，應該考慮進行系統和組織架構的調整 - 適合時機進行系統拆分，不要一開始就吧系統、服務拆分拆的很是細，雖然閉環，可是每一個人維護的系統多，維護成本高 - 微服務架構的理論基礎 - 康威定律 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、陣列卡自己緩存

併發化

2高可用原則

降級

• 降級開關集中化管理：將開關配置信息推送到各個應用

• 可降級的多級讀服務：如服務調用降級爲只讀本地緩存

• 開關前置化：如Nginx+lua(OpenResty)配置降級策略，引流流量；可基於此作灰度策略

• 業務降級：高併發下，保證核心功能，次要功能可由同步改成異步策略或屏蔽功能

限流

• 目的: 防止惡意請求攻擊或超出系統峯值

• 實踐：

• 惡意請求流量只訪問到Cache

• 穿透後端應用的流量使用Nginx的limit處理

• 惡意IP使用Nginx Deny策略或者iptables拒絕

切流量

• 目的：屏蔽故障機器

• 實踐:

• DNS: 更改域名解析入口，如DNSPOD能夠添加備用IP，正常IP故障時，會自主切換到備用地址;生效實踐較慢

• HttpDNS: 爲了繞過運營商LocalDNS實現的精準流量調度

• LVS/HaProxy/Nginx: 摘除故障節點

可回滾

• 發佈版本失敗時可隨時快速回退到上一個穩定版本

3業務設計原則

• 防重設計

• 冪等設計

• 流程定義

• 狀態與狀態機

• 後臺系統操做可反饋

• 後臺系統審批化

• 文檔註釋

• 備份

4總結

先行規劃和設計時有必要的，要對現有問題有方案，對將來有預案;欠下的技術債，早晚都是要還的。