《大型網站技術架構》讀書筆記

大型網站架構演化

特點

高并發,大流量 高可用 海量數據 用戶廣泛,網絡情況復雜 安全情況惡劣 需求變更快 漸進式發展

演變

  1. 一臺服務器,LNMP,應用程序訪問文件和數據庫
  2. 服務和數據分離 應用服務器:處理業務邏輯(CPU) 文件服務器:存儲文件(硬盤) 數據庫服務器:磁盤檢索和數據緩存(硬盤和內存)
  3. 使用緩存 本地緩存和遠程分布式緩存 減少數據訪問壓力,新的瓶頸是應用服務器
  4. 應用服務器集群 分布式,改善并發處理能力 可伸縮性,單服務器再強大也不行 前置負載均衡調度服務器
  5. 數據庫讀寫分離 數據庫再次成為瓶頸 多臺數據庫主從模式,讀寫分離
  6. 加速響應 緩存,CDN+反向代理 CDN是在網絡提供商機房緩存,反向代理是在負載均衡前的網站機房緩存
  7. 分布式文件系統和分布式數據庫 通常數據庫是拆庫,只有單表數據非常大時才使用分布式數據庫
  8. 使用nosql和搜索引擎 解決復雜的數據存儲和檢索需求
  9. 業務拆分
  10. 分布式服務 其實就是業務邏輯層和后端服務分開,業務邏輯層不訪問數據

大型網站架構模式

  1. 分層 應用層:業務和視圖展示 服務層:為應用層提供服務支持 數據層:提供數據存儲訪問服務
  2. 分隔 業務分隔,不同模塊
  3. 分布式 一個業務分拆多個子業務,部署在不同的服務器上
  4. 集群 同一個業務,部署在多個服務器上
  5. 緩存 CDN 反向代理 本地緩存(如hhvm的apc) 分布式緩存
  6. 異步 單一服務器:多線程共享內存隊列 分布式:消息隊列
  7. 冗余 服務器集群,數據庫備份
  8. 自動化 自動化發布:自動化代碼管理,自動化測試,自動化安全測試,自動化部署 自動化監控 自動化報警 自動化失效轉移/恢復 自動化降級 自動化資源分配
  9. 安全 身份驗證,加密,攻擊防范,過濾,風控

大型網站核心架構要素

  1. 性能
  2. 可用性
  3. 伸縮性
  4. 擴展性
  5. 安全性

高性能

不同視角

用戶視角改善:前端優化,cdn,反向代理等
開發人員主要使用的優化手段:緩存加速數據讀取,集群提高吞吐,異步消息加快請求響應及消峰,代碼優化改善程序性能
運維:建設優化骨干網,虛擬化技術優化資源利用

性能指標

響應時間
并發數:同時請求的數目
吞吐量:單位時間內系統存儲量
性能計數器:系統負載,cpu/內存/磁盤/IO使用

性能測試方法

性能測試,負載測試,壓力測試,穩定性測試

web前端性能優化

瀏覽器優化

減少http請求,合并css/js/圖片
使用瀏覽器緩存:逐量更新緩存
啟用壓縮:帶寬良好服務器資源不足時不合適
CSS放上面,js放下面
減少cookie傳輸

CDN加速

反向代理

正向代理隱藏了真實的請求客戶端,反向代理隱藏了真實的服務端
負載均衡,靜態緩存

應用服務器優化

分布式緩存

緩存:1.訪問數據塊的存儲介質 2.存儲計算后的數據
本質是內存hash表
緩存架構:JBossCache:同步式 memcached:不互相通訊,緩存和應用分類
遠程通信設計:1.通信協議:tcp/udp/http 2.通信序列化協議 xml/json/protobuffer

異步操作

因為后繼操作可能失敗,所以需要業務流程配合

集群

代碼優化

(都是從java角度)多線程,資源復用(單例和資源池),數據結構,垃圾回收

存儲性能優化

機械硬盤VS固態硬盤 B+樹 VS LSM樹 Raid VS HDFS

高可用

可用性度量

2個9,一年小于88個小時;4個9,一年小于53分鐘

高可用架構

傳統企業級應用:昂貴的軟硬件IOE,IBM的小/中/大型機及專有OS,oracle數據庫,emc存儲
集群:心跳監測

高可用應用

應用的無狀態性,不保存業務上下文,服務實例完全對等
負載均衡進行無狀態服務的失效轉移

Session(上下文對象)管理

session復制:所有服務器都保存一份,彼此同步
session綁定:會話粘滯,相同ip請求發到同一臺服務器
cookie記錄session
session服務器:無狀態的應用服務器和有狀態的session服務器

高可用的服務

分級管理:核心應用和服務使用更好硬件,服務部署隔離
超時設置:超時重試,請求其他服務器
異步調用:比如消息通知類
服務降級:拒絕部分低優先級的服務 或者 關閉部分不重要的功能
冪等性設計:就是可重入

高可用數據

CAP原理:數據一致性,數據可用性,數據分區容忍性,三個條件無法同時滿足
數據備份:冷備份(定時備份),熱備份,異步(一主多從),同步(對等,無主從)
失效轉移:失效確認,訪問轉移,數據恢復

軟件質量保證

網站發布:關閉負載均衡上部分路由-》關閉服務-》同步代碼-》啟動服務-》恢復路由
自動化測試
預發布驗證:預覽機外部用戶無法訪問,綁host或通過ip直接訪問
代碼控制:分支開發,主干發布
自動化發布
灰度發布:分級上線

監控

數據采集

用戶行為日志,服務度日志,客戶端瀏覽器端日志收集
服務器性能監控(應用程序開發無關)
運行數據報告(應用程序開發相關)

監控管理

系統報警,失效轉移,自動降級

伸縮性

網站架構伸縮性

分布式集群,不同功能通過物理分離實現伸縮(縱向分層,橫向業務分隔),單一功能通過集群伸縮

應用服務器集群的伸縮性

負載均衡:HTTP重定向,DNS域名解析,反向代理,IP負載,數據鏈路層
算法:輪詢,加權輪詢,隨機,最少鏈接,原地址散列(會話粘滯)
反向代理,IP負載,數據鏈路層即反向代理模式,透明模式,三角模式
反向代理:修改源ip,http層 透明模式:不修改源ip,傳輸層 三角模式:返回時不經過負載均衡,數據鏈路層
https://www.zhihu.com/question/20553431 http://lobert.iteye.com/blog/2159970

分布式緩存集群的伸縮性

memcached訪問模型:應用程序請求memcached客戶端的api,客戶端內先請求路由算法,分配機器,然后通過通信模塊和真正的服務器集群通信
原始hash算法不適合擴容,一致性hash算法通過hash環,等于劃分了很多區間,增加的新節點只會影響相鄰的那個節點
但這樣帶來了負載均衡的問題。解決方法是增加虛擬層。每個物理節點對應約150個虛擬節點,這樣插入時影響小,負載均衡好

數據存儲集群的伸縮性

關系數據庫

主從讀寫分離 分庫(類似業務分隔,但跨庫不能join)
cobar(DB proxy),支持數據分片,一張表存儲在多個數據庫中
cobar系統組件模型:前端通信模塊-》sql解析模塊->sql路由模塊-》sql執行代理模塊-》后端通信模塊-》結果合并模塊-》前端通信模塊
cobar服務器集群伸縮就是普通的應用服務器集群伸縮
mysql服務器集群伸縮時,cobar利用mysql的數據同步功能,以schema為單位遷移(schema下面有表,視圖等)
數據同步完成-》修改cobar路由配置-》刪除原機器中相關schema

NOSQL數據庫

NOSQL數據庫:放棄以關系代數為基礎的結構化查詢語言(SQL)和事務一致性保證(ACID),強化可伸縮性和高可用性
Apache HBase

可擴展

擴展性是系統設計層面的開閉原則(對擴展開發,對修改關閉),增加新功能不用修改現有系統架構和代碼

可擴展的網站架構

低耦合(模塊間關聯性低),模塊化(分層和分隔)

分布式消息隊列

事件驅動架構,消息隊列采用發布-訂閱模式。發送者發到消息隊列,然后消息隊列推給接受者。
應用程序服務器調用遠程訪問接口將消息推給消息隊列服務器,消息隊列服務器將消息寫入本地內存隊列立刻返回成功響應給消息生產者。消息隊列服務器根據消息訂閱列表查找訂閱該消息的消費者應用程序,將消息隊列中的消息按先進先出(FIFO)的原則通過遠程通信接口發送給消息消費者程序。

分布式服務

縱向拆分:大應用拆成小應用 橫向拆分:可服用業務拆分
WebService:服務提供者向注冊中心注冊,服務請求者從注冊中心檢索到服務信息后,通過SOAP(簡單對象訪問協議)和服務提供者通信
分布式服務框架需要支持除了webService提供的服務注冊和發現,服務調用外,還需要支持的特性:負載均衡,失效轉移,高效遠程通信,整合異構系統(不同語言,不同平臺),對應用最小入侵,版本管理,實時監控
SOA Facebook:thrift 阿里:Dubbo

可擴展的數據結構

NoSQL的ColumnFamily(列族)

開發平臺

api接口,協議轉換,安全,審計,路由,流程封裝

安全

網站攻擊和防御

XSS攻擊

反射型:誘使用戶點擊嵌入惡意腳本的鏈接
持久型:惡意腳本請求保持在web站點中
防御手段:消毒(轉義),httpOnly

注入攻擊

獲取表結構方式:開源,錯誤回顯,盲注
防御:消毒,參數綁定(orm框架)

CSRF攻擊

跨站請求攻擊
防御:token驗證,驗證碼,refer check(來源請求,防盜鏈也是這個功能)

其他攻擊

ErrorCode,html注釋,文件上傳,路徑遍歷

Web應用防火墻

統一攔截請求,過濾惡意參數,自動消毒,添加token
ModSecurity:處理引擎和攻擊規則分離的架構

安全漏洞掃描

信息加密

單項散列:md5,sha 通常要加鹽
對稱加密:DES,RC 加解密使用相同秘鑰
非對稱加密:RSA 用于數據安全傳輸,數字簽名等

秘鑰管理

秘鑰和算法放獨立服務器 或 加解密算法在應用系統,秘鑰放獨立服務器

信息過濾和反垃圾

文本匹配:正則表達式,Trie算法,多級hash表
機器學習:貝葉斯分類算法
黑名單:hash,布隆過濾器(節約空間,但可能有誤判)

電商風險控制

風險:賬戶(盜用,惡意注冊),不良買家,不良賣家,交易(盜刷,套現)
風控:規則引擎(業務規則和規則處理邏輯分離),統計模型(有預測性)

案例

淘寶網

初期LAMP, 應用服務器上分層部署apache+php,mysql主從讀寫分離
換用java,自建mvc框架(而不是structs或hibernate),orm框架選擇iBatis,數據庫為oracle
應用服務器上為webLogic+Webx+EJB+iBatis,之后放棄EJB改用spring,用免費jboss代替weblogic

維基百科

資源利用率高,性能優化好 只有百余臺服務器,數十名技術人員
LAMP,全免費

主要組成部分

GeoDNS:BIND增加版,將域名解析到離用戶最近的服務器
LVS:基于linux的開源負載均衡服務器
Squid:基于linux的開源反向代理服務器
Lighttpd:開源應用服務器,比Apache更輕量和快速,適合作為圖片服務器
php:免費的web應用開發語言,最流行的網站建站語言
memcached:無中心高性能的開源分布式緩存系統
Lucene:java開發的開源全文搜索引擎
Mysql:開源的關系數據庫管理系統

性能優化

前端:CDN,Squid緩存
PHP服務器:使用最好的服務器,apc緩存,圖片處理和轉換,php的strtr函數替換
后端:
多級緩存:熱點緩存在內存中;緩存內容直接可用,減少獲取后解析代價;memcached代替數據庫持久化連接
數據庫:增加服務器內存;犧牲持久可靠性保證性能,如使用raid0,數據庫一致性設置在較低水平;主庫宕機時關閉寫服務

Doris

海量分布式kv存儲系統,高可用可伸縮的KV存儲集群

架構

應用服務器集群從管理中心服務器集群獲取存儲服務器集群配置,然后訪問存儲服務器。管理中心對存儲服務器進行健康心跳檢測和故障擴容處理。

高可用解決方案

正常情況:寫的時候寫入全部服務器,讀的時候選擇一臺
瞬時故障:應用服務器首先重試,還是失敗就請求管理中心仲裁
臨時故障:故障服務器不提供服務,寫入時先寫入臨時服務器,恢復后從臨時服務器遷入故障期間寫的數據
永久故障:從正常服務器復制數據,而不是從臨時服務器遷移

秒殺

應對策略

秒殺系統獨立部署:防止高并發拖垮整個網站
秒殺頁面靜態化:請求不需要經過應用服務器和數據庫
租借秒殺活動帶寬:秒殺新增的帶寬,CDN的帶寬
動態生成隨機下單頁面url:防止用戶直接訪問下單頁url

架構設計

控制提交按鈕點亮:每次刷新時,更新js文件
控制訂單數:單臺先做一次校驗,控制數量,提交時候再次驗證

故障案例分析

日志:level設的太低,吃光硬盤
高并發訪問數據庫:首頁這樣高頻訪問頁面最好是靜態的,不應該直接訪問DB,數據從緩存獲取
高并發下鎖:鎖的使用要謹慎
緩存故障:當緩存全部關閉時,DB吃不消立刻掛掉
應用啟動不同步:先啟動php(或java)服務器,然后啟動網絡服務器(nginx或Apache)
大文件讀寫獨占磁盤:大小文件分開部署
濫用生成環境:生產環境不能隨便壓力測試
流程不規范:代碼提交前diff和cr
不好的編程習慣:對空對象的處理

架構師

領導藝術

關注人而不是產品。一群優秀人的做事一定會成功。所以領導真諦就是尋找一個值得共同奮斗的目標,營造大家能最大發揮自身價值的氛圍。
發掘人的優秀比發掘優秀的人有意義。是事情成就了人,而不是人成就了事。
保持對目標藍圖的關注。藍圖應該簡單形象,表述清楚。
共同參與架構,學會妥協,成就他人

架構師職場攻略

發現問題,尋找突破-》提出問題,尋找支持-》解決問題,達成績效
提問題tip:1.我的問題-》我們的問題 2.給上司封閉式問題, 給下屬開放式問題 3.對事不對人 4.用別人能接受的方式

架構師分類

產品架構師:具體產品的技術架構 產品業務規劃確定后,開始產品架構設計;和運營確定pv,用戶數,商品數等產品運營目標,發展規劃;和PM確定功能,模塊等;和項目經理確定排期和開發資源。整體架構設計,參與項目開發。
基礎服務架構師:平臺架構師,負責開發基礎框架,公共組件,通用服務等平臺類產品。
基礎設施架構師:DBA,op等

大型網站架構技術

網站層次:前端-》應用層-》服務層-》存儲層-》后臺,垂直的安全和數據采集及監控,最低端是數據中心機房

前端

瀏覽器優化:優化響應頁面,加快頁面加載和顯示,常用有頁面緩存,合并http減少請求,使用頁面壓縮等
CDN:內容分發網絡,部署在運營商機房,把靜態頁面分發到離用戶最近的CDN服務器
動靜分離,靜態資源獨立部署
圖片服務:獨立部署集群,獨立域名
反向代理:頁面緩存
DNS:DNS負載均衡

應用層

合適的開發框架
頁面渲染
負載均衡
Session管理:Session服務器
動態頁面靜態化
業務拆分
虛擬化服務器

服務層

分布式消息:消息隊列
分布式服務:SOA
分布式緩存
分布式配置:配置動態推送,無重啟生效

存儲層

分布式文件
關系數據庫
NOSQL數據庫
數據同步

后臺

搜索引擎
數據倉庫:根據離線數據,提供數據分析和數據挖掘
推薦系統

數據采集和監控

瀏覽器數據采集:嵌入JS腳本
服務器業務數據采集:一種是服務端日志,一種是業務數據
服務器性能數據采集:系統負載,內存使用率,網卡流量等
系統監控:數據可視化,自動化運維
系統報警:郵件,短信,語音電話

安全

web攻擊:xss,sql注入
數據保護

數據中心機房

機房架構:能耗嚴重
機柜架構
服務器架構:定制服務器

Web開發技術發展歷程

最初是cgi(通用網關技術),腳本模式,
瀏覽器發請求給web服務器,web服務器請求cgi程序,cgi程序解析http請求,處理業務邏輯,構造輸出信息,返回給web服務器。web服務器進行必要的http響應信息構造后,返回給http響應給瀏覽器。
因為cgi擅長處理請求信息,服務器頁面擅長構造響應頁面,兩者結合起來就是MVC模式。
控制器接受所有http請求,根據請求分發給不同模型對象處理,再根據處理結構選擇構造視圖,得到最終響應信息。
使用mvc讓模型和視圖分離,為分層架構奠定了基礎。

最后編輯于
?著作權歸作者所有,轉載或內容合作請聯系作者
平臺聲明:文章內容(如有圖片或視頻亦包括在內)由作者上傳并發布,文章內容僅代表作者本人觀點,簡書系信息發布平臺,僅提供信息存儲服務。
  • 序言:七十年代末,一起剝皮案震驚了整個濱河市,隨后出現的幾起案子,更是在濱河造成了極大的恐慌,老刑警劉巖,帶你破解...
    沈念sama閱讀 228,702評論 6 534
  • 序言:濱河連續發生了三起死亡事件,死亡現場離奇詭異,居然都是意外死亡,警方通過查閱死者的電腦和手機,發現死者居然都...
    沈念sama閱讀 98,615評論 3 419
  • 文/潘曉璐 我一進店門,熙熙樓的掌柜王于貴愁眉苦臉地迎上來,“玉大人,你說我怎么就攤上這事。” “怎么了?”我有些...
    開封第一講書人閱讀 176,606評論 0 376
  • 文/不壞的土叔 我叫張陵,是天一觀的道長。 經常有香客問我,道長,這世上最難降的妖魔是什么? 我笑而不...
    開封第一講書人閱讀 63,044評論 1 314
  • 正文 為了忘掉前任,我火速辦了婚禮,結果婚禮上,老公的妹妹穿的比我還像新娘。我一直安慰自己,他們只是感情好,可當我...
    茶點故事閱讀 71,826評論 6 410
  • 文/花漫 我一把揭開白布。 她就那樣靜靜地躺著,像睡著了一般。 火紅的嫁衣襯著肌膚如雪。 梳的紋絲不亂的頭發上,一...
    開封第一講書人閱讀 55,227評論 1 324
  • 那天,我揣著相機與錄音,去河邊找鬼。 笑死,一個胖子當著我的面吹牛,可吹牛的內容都是我干的。 我是一名探鬼主播,決...
    沈念sama閱讀 43,307評論 3 442
  • 文/蒼蘭香墨 我猛地睜開眼,長吁一口氣:“原來是場噩夢啊……” “哼!你這毒婦竟也來了?” 一聲冷哼從身側響起,我...
    開封第一講書人閱讀 42,447評論 0 289
  • 序言:老撾萬榮一對情侶失蹤,失蹤者是張志新(化名)和其女友劉穎,沒想到半個月后,有當地人在樹林里發現了一具尸體,經...
    沈念sama閱讀 48,992評論 1 335
  • 正文 獨居荒郊野嶺守林人離奇死亡,尸身上長有42處帶血的膿包…… 初始之章·張勛 以下內容為張勛視角 年9月15日...
    茶點故事閱讀 40,807評論 3 355
  • 正文 我和宋清朗相戀三年,在試婚紗的時候發現自己被綠了。 大學時的朋友給我發了我未婚夫和他白月光在一起吃飯的照片。...
    茶點故事閱讀 43,001評論 1 370
  • 序言:一個原本活蹦亂跳的男人離奇死亡,死狀恐怖,靈堂內的尸體忽然破棺而出,到底是詐尸還是另有隱情,我是刑警寧澤,帶...
    沈念sama閱讀 38,550評論 5 361
  • 正文 年R本政府宣布,位于F島的核電站,受9級特大地震影響,放射性物質發生泄漏。R本人自食惡果不足惜,卻給世界環境...
    茶點故事閱讀 44,243評論 3 347
  • 文/蒙蒙 一、第九天 我趴在偏房一處隱蔽的房頂上張望。 院中可真熱鬧,春花似錦、人聲如沸。這莊子的主人今日做“春日...
    開封第一講書人閱讀 34,667評論 0 26
  • 文/蒼蘭香墨 我抬頭看了看天上的太陽。三九已至,卻和暖如春,著一層夾襖步出監牢的瞬間,已是汗流浹背。 一陣腳步聲響...
    開封第一講書人閱讀 35,930評論 1 287
  • 我被黑心中介騙來泰國打工, 沒想到剛下飛機就差點兒被人妖公主榨干…… 1. 我叫王不留,地道東北人。 一個月前我還...
    沈念sama閱讀 51,709評論 3 393
  • 正文 我出身青樓,卻偏偏與公主長得像,于是被迫代替她去往敵國和親。 傳聞我的和親對象是個殘疾皇子,可洞房花燭夜當晚...
    茶點故事閱讀 47,996評論 2 374

推薦閱讀更多精彩內容