花時間讀了前阿裡巴巴人稱教授的李智慧老師的《大型網站技術架構和心原理與案例》一書，将筆記記錄在此，有需要原作的可私信
一.發展
1.應用伺服器和資料伺服器分離
2.使用緩存
3.應用伺服器叢集改善并發
4.資料讀寫分離-master資料庫寫》同步到slave》從slave讀
5.反向代理和cdn（内容分發網絡）
6.分布式檔案系統和資料庫系統（nosql資料庫和搜尋引擎）
7.業務拆分
二.架構模式
2.1模式
2.1.1分層，橫向，邏輯和實體的層（應用層，服務層，資料層），禁止跨層調用
2.1.2分割，即縱向分離
2.1.3分布式，
a. 優點：分布式意味着使用更多的計算機完成同樣的功能，計算資源越多，性能就越大
b. 缺點：
ⅰ. 通過網絡調用，網絡可能會成為瓶頸
ⅱ. 伺服器越多，故障的機率越大
ⅲ. 事務，資料一緻性難保證，影響業務正确性和流程
ⅳ. 依賴複雜維護成本大
c. 常用分布式方案：
a.分布式應用和服務
b.分布式靜态資源
c.分布式資料和存儲
d.分布式計算
e.分布式配置，分布式鎖，分布式檔案
2.1.4叢集，多台伺服器部署相同的服務，通過負載均很共同對外提供服務，提高并發
2.1.5緩存，CDN，反向代理，本地緩存，分布式緩存
2.1.6異步
2.1.7備援
2.1.8自動化，釋出過程自動化，自動化代碼管理，自動化測試。自動化部署，自動化監控，自動化運維
2.1.9安全
2.2新浪架構
基本架構圖：
三.核心要素
3.1.性能，架構和代碼優化
3.2.可用性，備援，一台或多台當機，系統依舊可用
3.3.伸縮性，可以不斷添加叢集中的節點來緩解業務上升的壓力
3.4.擴充性，增加新業務不影響現有的業務
1. 消息隊列，隻需産生新的消息topic和可消費新topic的消費者
2. 分布式，服用和服務調用
3.5.安全性
四.網站性能
4.1.網站性能
4.1.1.前端性能優化，html頁面式樣優化，浏覽器并發和異步，調整緩存政策，CDN服務，反向代理，
4.1.2.應用層，響應延遲，吞吐量，并發，穩定性，使用緩存，使用叢集，異步消息
4.1.3.性能名額：
ⅰ. 響應時間
ⅱ. 并發數
ⅲ. 吞吐量
ⅳ. 負載，線程數，記憶體，cpu，I/O
4.2.前端性能優化
4.2.1.浏覽器通路優化
ⅰ. 減少http請求，合并CSS，合并javascript，圖檔減少http請求，合并CSS，合并javascript，圖檔
ⅱ. 使用緩存
ⅲ. 壓縮
ⅳ. css放在最上面，javascript放在最下面
ⅴ. 減少cookie
4.2.2.CDN加速
4.2.3.反向代理
4.3.伺服器優化
4.3.1. 分布式緩存
1.原理：hash表，k-v對
2.合理使用
a.讀寫比2:1
b.熱點資料
c.資料不一緻，髒讀
d.緩存雪崩，緩存過期或緩存不可用，導緻資料庫壓力增大，資料庫伺服器當機
e.緩存預熱，重建緩存時系統和資料庫負載都會增大，此時需要預熱
f.緩存穿透，将不存在的資料儲存value為null
3.分布式緩存架構
a.JBoss cache，所有緩存的叢集保持同步，消耗大，多用于企業網站
b.memcached互不通信
4.3.2.異步操作
消息隊列削峰
4.3.3.使用叢集
分擔負載
4.3.4.代碼優化
ⅰ. 多線程
• 将對象設為無狀态
• 使用局部變量
• 并發時使用鎖的機制
ⅱ. 資源複用，單例（全局隻有一個類的執行個體）和對象池（資料庫連結資源，http連結，線程，複雜對象）
ⅲ. 優化資料結構
ⅳ. 優化垃圾回收
4.4.存儲性能優化
4.4.1機械硬碟，固态硬碟
4.4.2
五.高可用架構
5.1可用性的度量與考核
1.可用性計算：
故障時間=修複時間-發現事件
網站年度可用性名額=（1-不可用時間/年度總時間）×100%
2.可用性考核：
故障分=故障時間（分鐘）×故障權重
權重：
事故級----嚴重故障，整體不可用----100%
A類 ----通路不順暢，核心功能不可用----20%
B類 ----次要功能不可用，核心功能部分使用者不可用----5%
C類 ----其他故障----1%
5.2高可用架構
備援備份和失效轉移
5.3高可用的應用
不儲存業務的上下文，多個叢集之間對等，處理結果一緻
5.3.1通過負載均衡進行無狀态服務和失效轉移
負載均衡伺服器通過心跳檢測叢集狀态，不響應則從伺服器清單删除，失效立即轉移服務
5.3.2應用伺服器叢集的session管理
web應用将多次請求修改使用的上下文對象陳祚seeeion會話，管理方式如下：
1.session複制，session同步，使用叢集少的網站
2.session綁定，同意來源的ip請求發送到同一伺服器，伺服器可能當機，可用性不高
3.利用cookie記錄session，cookie存在用戶端，通路時将session帶在cookie發送給伺服器
4.部署session伺服器統一管理session，将無狀态的應用伺服器和有狀态的session伺服器分離，應用服 務器通過通路session伺服器讀寫session
5.4高可用的服務
5.4.1分級管理，核心業務部署在性能好的伺服器
5.4.2逾時設定
5.4.3異步調用
5.4.4服務降級，高并發時拒絕和關閉低優先級的服務，保證核心服務順暢
5.4.5幂等性設計（如一些業務需要多次調用同一接口傳回資料一緻）
5.5高可用的資料
方法：資料備份和失效轉移，同時緩存服務也要保證同樣的高可用性
5.5.1CAP原理，（即資料的可用性，資料的一緻性，資料的分區耐受性）
1. 資料的持久性----資料不丢失
2. 資料的可通路性----一個存儲節點不可用時可以快速切換到另一個節點
3. 資料的一緻性----多個副本之間資料同步
這三個特性很難同時滿足，一般選擇可用性和擴充性，放棄一緻性
資料一緻性範圍一下幾點：
a. 資料強一緻性----實體存儲中一定時一緻的（如passport問題）
b. 資料使用者一緻----實體存儲中可能不一緻，但通過糾錯和校驗，最終傳回給使用者是一緻的
c. 資料最終一緻----不保證實體存儲和使用者資料的一緻，而是經過一段時間系統的自我回複和修正
5.5.2資料備份（冷備份和熱備份）
冷備----備份到實體存儲
熱備----異步熱備和同步熱備
異步：應用伺服器隻連結主存儲（master）主存儲寫入從存儲（slave）
同步：應用伺服器同時将多份副本寫入多個存儲節點，沒有主從之分（并發寫入保證性能）
關系型資料庫的熱備就是通常所說的master-slave同步機制，不但可以解決資料備份，還能改善性能，采用讀寫分離，寫操作通路master，讀操作通路slave
5.5.3失效轉移（叢集中若出現伺服器當機，針對這個節點的通路重新路由到其他節點，保證資料通路不會失敗）
1.失效确認---心跳檢測
2.通路轉移
3.資料恢複
5.6高可用網站的品質保證
1. 網站釋出
通過腳本釋出，對使用者的影響減小到最少，過程如下
關閉負載均衡伺服器上的部分伺服器路由--》關閉這些服務--》同步代碼--》啟動這些伺服器--》打開負載上的路 由，重複次過程直到所有節點都部署
2. 自動化測試
3. 預釋出驗證
将代碼部署到專門的預釋出伺服器，預釋出伺服器與生産環境的實體環境一緻
4. 代碼控制
主線（trunk），分支（branch）
5. 自動化釋出
腳本執行，減少認為幹預
6. 灰階釋出
先将代碼部署到一部分伺服器，有問題復原快
7. 運作監控
7.1資料采集
a.使用者行為日志收集
i.服務端日志收集
ii.浏覽器日志收集
b.伺服器性能監控
c.運作資料報告
7.2監控管理
a.系統報警
b.失效轉移
c.自動優雅降級
六.伸縮性架構
不需要改變網站的軟硬體設計，通過改變部署伺服器數量改變伺服器的處理能力，
技術上做到向伺服器增加伺服器的數量和叢集的處理能力形成線性關系，就可以不斷提升網站規模
6.1伸縮性架構的設計
1. 不同功能實作實體分離
2. 單一功能通過叢集實作伸縮
3.
6.2應用伺服器叢集的伸縮性設計，一般通過負載均衡實作
1. http重定向
• 優點：實作簡單
• 缺點：需要兩次通路
2. DNS域名解析
• 優點：DNS可以實作就近通路
• 缺點：多級解析，上下線生效時間長；控制權在域名服務商那裡
3 反向代理
配置在伺服器端，提供對外服務的接口，接收到請求後，通過負載均衡算法将請求發送給目标伺服器，獲得響應資料再傳回給前端
• 優點：部署簡單
• 缺點：請求的中轉站，性能會影響整個系統的響應
4. Ip負載均衡
在核心完成資料的分發，負載均衡伺服器修改目标ip，不需要使用者再次發送請求
• 優點：處理性能好
• 缺點：吞吐量會成為系統的瓶頸
5. 資料鍊路層負載均衡
在通信協定是資料鍊路修改Mac，負載均衡伺服器與目标伺服器的ip一緻，響應結果由目标伺服器直接傳回給前端，
• 優點：沒有瓶頸
• 缺點：
6. 負載均衡算法：
*輪詢RR----依次分發
*權重輪詢WRR----輪詢基礎上權重重
*随機random----随機分發
*最少連接配接least connections----優先分發到目前連接配接數最少的伺服器上
*源位址散列source hashing----同一來源分發到同一伺服器
6.3分布式緩存叢集的伸縮性設計
1.清單計算
2.餘數hash
3.一緻性hash--hash環（将叢集的節點放入環中，計算key的hash，順時針找到環中最近的節點），增加節點隻影響環的一段
6.4資料存儲伺服器的叢集伸縮性設計
6.4.1.關系型資料庫的可伸縮設計
• 關系型資料庫，主從複制，主伺服器隻寫入，從伺服器隻讀取，實作讀寫分離，隻需新增從伺服器
優點：資料一緻性強，可以保證讀寫的性能，
• 分庫，分表，分片，不同的業務部署在不同的資料庫叢集
優點：解耦，各業務資料互不影響，缺點：不能跨庫進行join操作
• 主從複制和分片結合，适用于資料量大的業務
cobar的模型：sql請求如select *from user where id in (12,22,23),路由子產品根據排至規則分解sql為：select *from user where id in (12,22)和select *from user where id =23，分别送出給奇偶兩個庫查詢，再将查詢結果合并後傳回
cobar以schema為機關，通過mysql的資料遷移功能實作叢集的新增，遷移完成後更新路由伺服器的配置
6.4.2非關系型資料庫的可伸縮設計
非關系型資料庫放棄了以關系代數為基礎的結構化查詢語言（SQL）和事務一緻性（ACID），
強化了高可用性和伸縮性
當一個Hregion寫入的資料達到一個門檻值後，HRgion分裂，已達到負載均衡和可伸縮性
七.可擴充性網站架構設計
擴充性：在不影響現有架構下可以增加新的功能（增加新功能）
伸縮性：不改變現有架構，伺服器數量和叢集一提高系統的處理能力（提高處理能力）
7.1建構可擴充的網站架構
$低耦合
低耦合是衡量一個系統優劣的尺度，優秀的架構師在于将一個大型的系統分割成橫向的業務子產品，縱向的基礎計數子產品，核心思想是子產品化，解耦，提高複用。分層，分割的思想也可用于可擴充性設計，
$解耦--》聚合
通過消息傳遞和調用的方式将獨立解耦的子產品聚合成一個完整的系統，分布式部署後還可以通過分布式消息隊列和分布式服務聚合
優點：擴充性強，子產品容易複用，開發維護容易，
7.2利用分布式消息隊列降低系統耦合性
1.事件驅動架構EDA
通過在子產品之間傳遞事件消息，保持子產品之間的松散耦合，并借助事件的通信完成子產品間合作，即生産者-消費之模式，常見的是分布式消息隊列，消息隊列利用釋出-訂閱模式工作，生産者将消息發送到隊列，接收這從隊列擷取訂閱的消息并處理，生産者和消費者之間是解耦和的，隻有訂閱和取消訂閱的關系，以此實作擴充
消息隊列優點：具有很好的響應延遲，可以根據自身的負載能力處理讀取隊列，減輕資料庫等後端的壓力
2.分布式消息隊列
分布式消息隊列的特點：
分布式消息隊列的伸縮性：消息隊列伺服器上的資料可以看做是被即時處理的，将新的伺服器加入到消息隊列叢集中。通知生産者更改消息隊列伺服器清單即可
分布式消息隊列的可用性：消息隊列伺服器記憶體寫滿後可以寫到磁盤，消息保留到消息被處理之後再删除，檢測到叢集中一台伺服器當機，将消息發送到其他伺服器
也可以用mysq當做分布式消息隊列，生産者将消息當做資料寫入資料庫，消費者通過select查詢并按時間排序擷取消息，有成熟的mysql運維手段，可以很好的達到要求。
7.3利用分布式服務打造可複用的業務平台
*分布式服務通過接口分解系統的耦合性，不同子系統通過相同的接口描述進行服務的調用
*業務拆分：
1縱向拆分：梳理業務，相關性少的業務進行剝離，将一個大的應用拆分成多個小應用，
2橫向拆分：将複用的業務拆分出來，獨立部署，新增的業務隻需調用這個服務，
7.3.1Web-service與企業級分布式服務
難以滿足大型網站對系統高可用，高性能，易部署，易維護的要求
7.3.2大型網站分布式服務的需求與特點
• 負載均衡
• 失效轉移
• 高效的遠端通信
• 整合異構系統，網站服務需要整合不同開發語言和不同部署平台的異構系統
• 對應用最少的侵入，服務子產品支援分布式部署，也要支援集中式部署
• 版本管理，分布式架構需要支援服務多版本釋出，即提供新接口的版本服務，也支援舊接口的版本服務
• 實時監控
7.3.3分布式服務架構設計
facebook利用thrift管理分布式服務（跨語言的rpc服架構）
阿裡巴巴采用Dubbo管理
Dubbo架構：
DUbbo遠端通信子產品使用NIO通信架構
附：
NIO和IO到底有什麼差別？有什麼關系？
首先說一下核心差別：
ⅰ. NIO是以塊的方式處理資料，但是IO是以最基礎的位元組流的形式去寫入和讀出的。是以在效率上的話，肯定是NIO效率比IO效率會高出很多。
ⅱ. NIO不在是和IO一樣用OutputStream和InputStream 輸入流的形式來進行處理資料的，但是又是基于這種流的形式，而是采用了通道和緩沖區的形式來進行處理資料的。
ⅲ. 還有一點就是NIO的通道是可以雙向的，但是IO中的流隻能是單向的。
ⅳ. 還有就是NIO的緩沖區（其實也就是一個位元組數組）還可以進行分片，可以建立隻讀緩沖區、直接緩沖區和間接緩沖區，隻讀緩沖區很明顯就是字面意思，直接緩沖區是為加快 I/O 速度，而以一種特殊的方式配置設定其記憶體的緩沖區。
ⅴ. 補充一點：NIO比傳統的BIO核心差別就是，NIO采用的是多路複用的IO模型，普通的IO用的是阻塞的IO模型，兩個之間的效率肯定是多路複用效率更高
7.4可擴充的資料結構
• 關系型資料庫：設計之初考慮留出将來需要的字段
• 非關系型資料庫：如google的bigtable，使用Columnfamily設計，設計時隻需指定Columnfamily的名稱，column可以随意擴充
7.5利用開放平台建設網站生态圈
開放平台：大型網站為了更好的服務自己的使用者，開發更多的增值服務，
把網站内部的服務封裝成調用接口開 放，供給外部發第三方開發者使用，
這個提供開放接口的平台稱為開放平台
開放式平台的基礎架構：
×API接口：對外提供服務的一組接口，可以是rest，webservice，rpc等
×協定轉換：資料格式化，封裝
×安全：身份識别，權限控制，（token），分級通路等
×審計：記錄通路情況，監控，計費等
×路由：将通路路由映射到具體的内部服務
×流程：将分散的服務組成包含上下文的服務，隐藏細節，提供接口
八 網站的安全架構
8.1網站應用的攻擊與防禦
8.1.1XSS攻擊，
cross site script跨站點腳本攻擊，通過篡改網頁，注入惡意腳本攻擊
• 反射型：誘使使用者點選達到攻擊目的
• 持久型：送出含有惡意的腳本請求，儲存在目标的web站點資料庫，達到攻擊
防禦XSS攻擊：
1.對危險字元轉義，
如“>”<"轉義為“>”“<”等，即可防禦部分xss攻擊
2.設定httpOnly屬性
禁止javescript通路帶有httponly屬性的cookie，避免竊取cookie敏感資訊
8.1.2注入攻擊
1.SQL注入：在http請求中注入惡意sql指令，一般有一下幾種方式了解目标的資料結構：
• 開源軟體：開源軟體暴露資料結構
• 錯誤回顯：通過傳回錯誤判斷
• 盲注：根據頁面變化判斷sql執行情況進行猜測
防禦SQL注入：
• 正則比對過濾sql語句中可能的惡意指令，如drop，delete等
• 參數綁定，預編譯，将注入的sql語句當做參數而非sql指令執行
2.OS注入：注入OS代碼，利用程式漏洞攻擊
8.1.3CSRF攻擊
跨站點請求僞造：使用者登入網站A，浏覽器儲存網站A傳回occkie資訊，
使用者打開網站B，B盜取浏覽器cookie資訊登入網站A
防禦CSRF：
• 表單token，校驗token辨識使用者身份
• 驗證碼
• 驗證referer，驗證來源是否合法
8.1.4其他攻擊
error code，防禦：業務錯誤碼統一，不透傳
HTML注釋，防禦：代碼review，自動掃描
檔案上傳，防禦：白名單，稽核，修改檔案名，專門存儲
路徑周遊，防禦：資源檔案部署在獨立伺服器，使用獨立域名，不使用靜态url（不帶參數的url）通路，參數不包含檔案路徑資訊
8.1.5web應用防火牆
modsecurity開源web應用防火牆
8.1.6網站安全漏洞掃描
模拟黑客，發現網站安全漏洞
8.2資訊加密技術和秘鑰安全管理
敏感資料加密處理，加密方法：
散列加密，對稱加密，非對稱加密
8.2.1單項散列加密
通過對不同輸入長度的資訊進行散列加鹽計算得到固定長度的的輸出，如MD5，SHA算法
8.2.2對稱加密
加密和解密使用的同一個秘鑰，如DES算法，RC算法
8.2.3非對稱加密
公鑰加密，私鑰解密，如RSA算法
8.2.4秘鑰安全管理
• 将秘鑰和加密算法放在獨立的伺服器，應用通過調用這個服務實作加解密
• 将加解密算法放在應用系統中，秘鑰放在單獨的伺服器中，存儲時秘鑰切分成片，分别儲存
8.3資訊過濾和反垃圾
8.3.1文本比對
敏感詞過濾：正則過濾，Trie樹比對
如上Trie樹包含{inn，int，tea，ten，to}
有時候為了繞過檢查，某些資訊會被加幹擾資訊如“阿_拉_伯”，還需要做降噪處理，然後進行比對
8.3.2分類算法
為了識别垃圾資訊，廣告，對内容進行進行稽核，需要分類算法
貝葉斯分類算法：
如，對郵件進行分析，提取到含有“茶葉”的20%時垃圾郵件，1%不是垃圾郵件，得到分類模型，以“茶葉”作為特征對郵件進行分類
8.3.3黑名單
布隆過濾器
8.4電子商務風險控制
8.4.1電子商務風險
• 賬戶風險：賬戶被盜，惡意注冊帳戶等
• 買家風險：惡意下單占用庫存，
• 賣家風險
• 交易風險
8.4.2風控
自動稽核，人工稽核
1.規則引擎：
如使用者來自欺詐高發區，交易金額過大，和上次登入距離大，登入與收貨地不同等等，
網站一般用規則引擎處理此類問題，規則引擎時一種将業務規則和處理邏輯互相分離的技術，
業務規則有營運人員通過管理界面編輯，而規則處理邏輯則調用規則處理輸入的數
缺點：随着規則增加，可能出現規則沖突，難以維護，性能差
2.統計模型：
統計模型使用分類算法或機器學習算法進行智能統計，根據曆史交易中的欺詐交易訓練分類算法，
---------------------------------------------------The End------------------------------------------------------