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

編程語言 DNS Redis Memcached 雲技術 2017-04-18

作者 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總結

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

相關推薦

推薦中...