概述

1 架構演化
大型網站的關注指標
高可用

高性能

易擴展

可伸縮

安全

大型網站的特點
高并發，大流量

高可用

海量數據

用戶分布廣泛，網絡情況復雜

安全環境惡劣

需求快速變更，發布頻繁

漸進式發展

大型網站架構演化發展過程
初始階段，多使用LAMP來搭建，All In One即所有資源存放在一臺服務器上

應用服務和數據服務分離，有獨立的數據庫服務器

使用緩存改善網站性能（依據是二八定律：80%的業務訪問集中在20%的數據上）

這里需要考慮哪些數據適合緩存

緩存可以是本地緩存，也可以是遠程分布式緩存

需要考慮使用合理的緩存策略，防止透傳

使用應用服務器集群改善網站的并發處理能力

如果能通過增加一臺服務器的方式來改善負載壓力，就可以以同樣的方式持續增加服務器來不斷改善系統性能，從而實現系統的可伸縮性

這里需要考慮使用哪些負載均衡的策略

數據庫讀寫分離

可以利用主流數據庫提供的主從熱備功能，通過配置兩臺數據庫的主從關系，同時業內也有很多優秀的開源中間件如Atlas

緩存中的數據，如果更新過快，那么會持續刷新緩存，從而降低性能

使用反向代理和CDN加速網絡響應

CDN和反向代理的基本原理都是緩存

CDN部署在網絡提供商的機房，用戶在請求網絡服務時，可以從距離自己最近的網絡提供商機房獲取數據

反向代理部署在網站的中心機房，當用戶的請求到達中心機房后，首先訪問的服務器是反向代理服務器，如果反向代理服務器中緩存著用戶請求的資源，那么就將其直接返回給用戶

CDN的重點：——《大型網站系統與Java中間件實踐》

全局調度

緩存技術

內容分發

帶寬優化

使用分布式文件系統和分布式數據庫系統

網站常用的數據庫拆分手段是業務分庫，即將不同業務的數據庫部署到不同的物理服務器上

使用NoSQL和搜索引擎

ES

MongoDB

業務拆分，使用分而治之的手段將整個網站業務分成不同的產品線

SOA、服務化

中心化的 gataway方式

消息隊列

不同服務訪問同一個DB等

這部分十分重要，道理很簡單，但是執行起來的效果千差萬別。

當下火熱的微服務，也是基于這種思想。

技術實現方式也有很多

分布式服務

大型網站架構演化的價值觀
網站的價值在于它能為用戶提供什么價值，在于網站能做什么，而不在于它是怎么做的。因此對于小型網站來說，最需要做的是位用戶提供好的服務來創造價值，得到用戶的認可，從而活下去，野蠻生長。
大型網站架構技術的核心價值是隨網站所需靈活應對， 它是一個演化的過程

驅動大型網站技術發展的主要力量是網站的業務發展，是業務成就了技術，而不是相反。因此要摒棄為了技術而技術的套路

網站架構設計誤區
一味追求大公司的解決方案

為了技術而技術

企圖用技術解決所有問題

2 架構模式
分層，這是在橫向方向對系統進行切分

分層的挑戰在于必須合理規劃層次邊界和接口

分層包括物理分層和邏輯分層兩種

分割，這是在縱向方向對系統進行切分

將不同的功能和服務分割開來，包裝秤高內聚低耦合的模塊單元

分布式

1） 分布式應用和服務；

2） 分布式靜態資源；

3） 分布式數據和存儲；

4） 分布式計算；

5） 分布式配置、分布式鎖、分布式文件系統。。。

1） 分布式意味著服務調用必須通過網絡，需要考慮帶寬的影響；

2） 服務器越多，宕機的概率越大

分層和分割的目的在于小模塊便于分布式部署

帶來的問題：

常用的分布式方案：

集群，即多臺服務器部署相同的應用，從而構成一個集群，通過負載均衡設備共同對外提供服務

即使訪問量很小的分布式應用和服務，也至少要部署到兩臺服務器來構成一個小集群，這樣可以提高系統的可用性

緩存，即將數據放在距離計算最近的位置以加快處理速度

CDN

反向代理

本地緩存

分布式緩存

異步，業務之間的消息傳遞不是同步調用，而是將一個業務操作分成多個階段，每個階段之間通過共享數據的方法異步進行協作

1） 提高系統可用性；

2） 加快網站響應速度；

3） 消除并發訪問高峰

通常需要使用消息隊列

帶來的好處：

冗余

集群帶來的必然結果

安全需求的必然結果

自動化，DevOps思維，盡量減少人工干預

自動化發布

自動化代碼管理

自動化測試

自動化安全監測

自動化部署

自動化監控

自動化報警

自動化失效轉移、恢復

自動化分配資源

......

安全

3 大型網站核心架構要素
性能

一個性能問題可能會導致網站用戶嚴重流失

衡量性能的指標：響應時間、TPS、系統性能計數器等

可用性

沒有網站可以完美的7*24運行

網站高可用結構的前提是必然會出現服務器宕機，兒高可用設計的目標是當服務器宕機時，服務或者應用依然可用

必要的手段是集群，即冗余

伸縮性，即通過不斷向集群中加入服務器的手段來環節不斷上升的用戶并發訪問壓力和不斷增長的數據存儲需求

衡量標準：是否可以構建集群；是否可以方便的向集群中添加新的服務器

擴展性，直接關注網站的功能，保證可以快速響應需求變更

衡量標準： 網站增加新的業務產品時，是否對現有業務透明無影響

安全性

衡量標準： 針對現存和潛在的各種攻擊和竊密手段，是否可以有效的應對

4 瞬時響應 - 網站的高性能架構
不同視角下的網站性能
用戶視角

主要是端到端的感覺

主要通過前段優化的手段來提升用戶體驗

開發人員視角

主要關注應用程序本身以及相關子系統的性能，包括響應延遲、系統吞吐量、并發處理能力、系統穩定性等

主要優化手段： 使用緩存加速數據讀取、使用集群提高吞吐能力、使用異步消息加快請求響應、使用代碼優化提升程序性能

運維人員視角

主要關注基礎設施性能和資源利用率

主要優化手段： 建設優化骨干網、使用高性價比定制服務器、利用虛擬化技術優化資源利用率

性能測試指標
響應時間，即應用執行一個操作需要的時間，包括從發出請求開始到收到最后響應數據所需要的時間

并發數，即系統能夠同時處理的請求的數目，也反映了系統的負載特性

吞吐量，即單位時間內系統處理的請求數量，體現系統的整理處理能力

性能計數器， 描述服務器或者操作系統性能的一些數據指標

性能測試方法
性能測試，以系統設計初期規劃的性能指標為預期目標，對系統不斷增壓，驗證系統在資源可接受范圍內，是否能達到性能預期

負載測試，對系統不斷的增加并發請求，知道系統的某項或者多項性能指標達到安全臨界值

壓力測試，超過安全負載的情況下，繼續對系統增壓，直到系統崩潰或者不能再處理任何請求

穩定性測試，在特定硬件、軟件、網絡情況下，給系統加載一定壓力，是系統運行較長一段時間，來觀察系統是否穩定

Web前端優化
瀏覽器訪問優化

減少http請求

使用瀏覽器緩存

啟用壓縮

CSS放在頁面最上面，JavaScript放在頁面最下面

減少Cookie傳輸

CDN加速

反向代理

應用服務器性能優化
分布式緩存

一般會使用消息隊列，帶來的額外好處是會削平峰值

1）不同的緩存服務器之間進行通信，例如JBoss Cache；

2）不同緩存服務器之間不進行通信，例如Memcached

緩存從本質上來說，就是一個內存hash表

緩存需要緩存那些讀寫比很高、很少變化的數據，一般來說讀寫比在2:1以上時，緩存才有意義

應用程序讀取數據時，首先到緩存中讀取，如果緩存不存在或者已失效，再訪問數據庫，同時將新的數據放入緩存

緩存也需要注意緩存熱點數據

緩存預熱，在新啟動的緩存系統中，在啟動時就加載熱點數據，這樣啟動后就可以直接使用

緩存穿透， 應用持續大量訪問不存在的數據，因為這類數據不存在于緩存中，因此會大量訪問數據庫，從而降低性能

對于分布式緩存來說，目前有兩類：

異步操作

使用集群

代碼優化
多線程

1） 將對象設計成無狀態對象；

2） 使用局部對象；

3） 并發訪問資源時使用鎖

需要注意線程安全問題，方法：

資源復用

主要是單例和資源池（對象池）

數據結構，選擇合適的算法

垃圾回收

合理設置垃圾回收策略

存儲性能優化

機械硬盤 vs 固態硬盤

B+樹 vs LSM樹

RAID vs HDFS

5 萬無一失 - 網站的高可用架構
網站可用性度量
網站不可用時間 = 故障修復時間點 - 故障發現時間點

網站年度可用性指標 = （1 - 網站不可用時間/年度總時間）* 100%

一般以幾個9來表示，2個9是基本可用，網站年度不可用時間小于88小時；3個9是較高可用，網站年度不可用時間小于9小時；4個9是具有自動恢復能力的高可用，網站年度不可用時間小于53分鐘；5個9是極高可用性，網站年度不可用時間小于5分鐘

網站高可用架構的設計目標是保證服務器硬件故障時服務依然可用、數據依然保存并能夠被訪問

網站高可用架構的主要手段：數據和服務的冗余備份以及失效轉移，一旦服務器宕機，就將服務切換至其他可用的服務器上。

高可用的應用
無狀態應用： 應用服務器不保存業務的上下文信息，而僅根據每次請求提交的數據進行相應的業務邏輯處理，多個服務實例之間完全對等，請求提交到任何一個服務器上，處理的結構都是相同的。
通過負載均衡進行無狀態服務的失效轉移

負載均衡： 主要使用在業務量和數據量較高的情況下，當單臺服務器不足以承擔所有的負載壓力時，通過負載均衡手段，將流量和數據分攤到一個集群組成的多臺服務器上， 以提升整體的負載處理能力

應用服務器集群的Session管理

Session復制

Session綁定

利用Cookie記錄Session

Session服務器

高可用的服務
分級管理

核心服務與非核心服務隔離

核心服務優先使用高性能服務器

超時設置

異步調用

必須滿足可以使用異步調用方式

服務降級

冪等性設計

服務高可用（高可靠）一直是美團外賣的第一要求，為了提高可用性，做了很多策略，包括并不限于上文提出的各種架構設計方案。

其實造成線上問題的很大一部分原因是由于發版造成的，也體現出了SOP的重要性。

關于降級與依賴隔離，可以考慮采用Hystrix實現自動降級與依賴隔離 。

高可用的數據
數據一旦出現問題，對于網站往往是毀滅性的打擊，因此保護網站的數據就是保護企業的命脈。
主要手段：數據備份和失效轉移

緩存服務高可用

觀點一：緩存服務已經承擔了業務中絕大多數的數據讀取訪問，因此需要同樣保證高可用

觀點二：緩存服務并不是數據存儲服務，出現服務不可用導致數據丟失應從別的手段解決，而不是提高緩存服務本身高可用

緩存服務器集群中單機故障，集群規模較大時，數據丟失比例和數據負載壓力影響很小。

CAP原理： 一個提供數據服務的存儲系統無法同時滿足數據一致性（Consistency）、數據可用性（Availibility）、分區耐受性（Parition Tolerance）這三個條件

數據高可用含義：

副本間數據一致

多個副本可讀

同時寫入數據副本

1）數據持久性

2）數據可訪問性

3）數據一致性

數據一致性分類：

1） 數據強一致；

2） 數據用戶一致；

3） 數據最終一致

數據備份

1） 異步熱備；

2） 同步熱備

冷備的優點是簡單和廉價，成本和技術難度較低，缺點是不能保證數據最終一致

熱備分為兩種：

失效轉移

1） 心跳檢測（Keepalived、Heartbeat）；

2） 應用程序訪問失敗報告

失效確認：

訪問轉移

數據恢復

高可用網站的軟件質量保證
網站發布，它的過程和服務器宕機效果箱單，其對系統可用性的影響也 類似

一般采取批量更新的方式進行，不會一次關掉集群中的全部服務器

自動化測試

一般使用Selenium來進行測試

預發布驗證

預發布服務器是一種特殊用途的服務器，它和線上的正式服務器唯一的區別是沒有配置在負載均衡服務器上，外部用戶無法訪問

代碼控制

主干開發，分支發布

分支開發，主干發布，這是目前使用的主流方式

自動化發布

火車模型：將每個應用的發布過程看做一次火車旅程，火車定點運行，期間有若干站點，每一站都進行例行檢查，不通過的項目下車，通過的項目繼續坐著火車旅行，直到火車到達終點。

實際中，可能所有項目在途中都下車了，這樣火車不得不回到原點，等待問題解決后再來一次

一種可能是火車上的重點項目如果失敗，那么整趟火車需要返回

人的干預越少，自動化程度越高，引入故障的可能性就越小

灰度發布

大型網站都會使用灰度發布模式，將集群服務器分成若干部分，每天只發布一部分服務器，觀察運行穩定沒有故障，第二天繼續發布一部分服務器，持續幾天你才把整個集群全部發布完畢，期間如果發現問題，只需要回滾已發布的一部分服務器即可

網站運行監控
監控數據采集

用戶行為日志收集

服務器性能監控

運行數據報告

監控管理

系統報警

失效轉移

自動優雅降級

6 永無止境 - 可伸縮性架構
網站伸縮性： 在不需要改變網站的軟硬件設計，僅僅通過改變部署的服務器數量就可以擴大或者縮小網站的服務處理能力

網站架構的伸縮性設計
不同功能進行物理分離實現伸縮

單一功能通過集群規模實現伸縮

應用服務器集群的伸縮性設計
HTTP重定向負載均衡

DNS域名解析負載均衡

反向代理負載均衡

IP負載均衡

數據鏈路層負載均衡

負載均衡算法

輪詢

加權輪詢

隨機

最小鏈接

原地址散列

分布式緩存集群的伸縮性設計
Memcached分布式緩存集群的訪問模型

用程序通過Memcached客戶端訪問Memcached服務器集群，Memcached客戶端主要由一組API、Memcached服務器集群路由算法、Memcached服務器集群列表以及通信模塊構成

路由算法負責根據應用程序輸入的緩存數據KEY計算得到應該將數據寫入到Memcached的哪臺服務器（寫緩存）或者應該從哪臺服務器讀數據（讀緩存）

Memcached分布式緩存集群的伸縮性挑戰

挑戰主要針對路由算法，當集群擴容時，如何保證路由算法可以得到新加入的服務器？

解決方法： 在網站訪問量最少的時候擴容，然后通過模擬請求的方法逐漸預熱緩存，使得緩存服務器中的數據重新分布

分布式緩存的一致性Hash算法

數據存儲服務器集群的伸縮性設計
數據存儲服務器必須保證數據的可靠存儲，任何情況下都必須保證數據的可用性和正確性

關系數據庫集群的伸縮性設計

利用主從結構實現讀寫分離

根據不同業務的數據，放到不同的數據庫集群中，即數據庫分庫

對于特別大的表，進行分片處理

NoSQL數據庫的伸縮性設計

HBase

7 隨需應變 - 可擴展架構
可擴展性：在對現有系統影響最小的情況下，系統功能可持續擴展或者提升的能力
實現可擴展的手段：低耦合，高內聚

利用分布式消息隊列降低系統耦合性
事件驅動架構（Event Driven Architecture）

定義：通過在低耦合的模塊之間傳輸事件消息，以保持模塊的松散耦合，并借助事件消息的通信完成模塊間合作。典型的場景是生產著消費者模型

分布式消息隊列

利用分布式服務打造可服用的業務平臺
需要將超大型的、復雜系統查分成可獨立部署的模塊，從而降低耦合性

Web Service與企業分布式服務

Web Service比較臃腫，可以考慮使用REST

或者使用開源的解決方案，例如Dubbo

可擴展的數據結構
8 固若金湯 - 安全架構
典型攻擊方式
XSS攻擊（跨站腳本攻擊）

1） 消毒；

2. HttpOnly

1） 反射型；

2） 持久型

黑客通過篡改網頁，注入惡意HTML腳本，在用戶瀏覽網頁時，控制用戶瀏覽器進行惡意操作的一種攻擊方式

分類：

解決方法：

注入攻擊

1） 消毒；

2） 參數綁定

1） SQL注入攻擊；

2） OS注入攻擊

分類：

解決方法：

CSRF攻擊（跨站點請求偽造）

1） 表單Token；

2） 驗證碼；

3） Referer check

攻擊者通過跨站請求，以合法用戶的身份進行非法操作

解決方法： 識別請求者身份：

其他攻擊方式

Error Code，可能顯示異常堆棧，從而暴露危險信息，解決方法：使用統一的500頁面

HTML注釋，注釋可能會暴露危險信息，解決方法：code review或者自動掃描

文件上傳，可能上傳病毒文件，解決方法：設置上傳文件白名單，只允許上傳指定類型的文件

路徑遍歷， 在URL中使用相對路徑，遍歷系統未開放的目錄和文件，解決方法： 將資源文件部署在獨立的服務器上，使用獨立域名

信息加密技術以及密鑰管理
單項散列加密，包括MD5、SHA等

對稱加密， 包括DES算法、RC算法等

非對稱加密， 包括RSA算法等

密鑰安全管理

將密鑰和算法放在一個獨立的服務器上，甚至做成一個專用的硬件設置，對外提供加密和解密服務

將加解密算法放在應用系統中，密鑰則放在獨立服務器中，在存儲時，將密鑰切分成數片，分別存儲在不同的介質中

后記
在大型網站的建設中，千萬不要一味遵循一些所謂的標準，因為有些標準的指定根本不是針對大型網站系統的。

不能為了技術而技術，能落地的架構才是好架構，架構設計不能堆砌概念和模式，不能面面俱到卻不解決具體問題。

做架構設計的目的不是為了炫耀自己知道多少術語。

不要企圖去設計一個大型網站

尤其很多傳統企業進入互聯網時，會試圖在互聯網領域開發一個大型網站復制其在傳統行業的優勢地位，但是互聯網發展運行有其自己的規律，短暫的互聯網歷史已經一再證明這種企圖是行不通的。

互聯網沒有門檻，誰都可以進來玩，但是進來后，最好把那些陳舊的思想和包袱放下。

互聯網是一種精神，一種開發、分享、自由的精神；越是不計回報越是獲得豐厚的回報。

架構師人在職場，需要處理好個人、團隊、公司的利益。需要不斷在工作中發現問題、解決問題，提升工作經驗、知識技能和核心競爭力，擴大自身影響力。

新員工首先要做的事情是融入團隊，等熟悉了情況，再尋找突破口，擇機而動

新員工最不需要做的事情就是證明自己的能力。

把“我的問題”表述成“我們的問題”

給上司提封閉式問題，給下屬提開放式問題

支出問題而不是批評人

用贊同的方式提出問題

在解決我的問題之前，先解決你的問題

適當的逃避問題

架構師領導藝術

不要只有架構師一個人擁有架構

讓其他人維護框架與架構文檔

是事情成就了人，而不是人成就了事

共享美好藍圖

一群優秀的人做一件他們熱愛的事，一定能取得成功

尋找一個值得共同奮斗的目標，營造一個讓大家都能最大限度發揮自我價值的工作氛圍

關注人而不是產品

發掘人的優秀

共同參與架構

學會妥協
1、具有1-5工作經驗的，面對目前流行的技術不知從何下手，需要突破技術瓶頸的可以加。

2、在公司待久了，過得很安逸，但跳槽時面試碰壁。需要在短時間內進修、跳槽拿高薪的可以加。

3、如果沒有工作經驗，但基礎非常扎實，對java工作機制，常用設計思想，常用java開發框架掌握熟練的，可以加。

4、覺得自己很牛B，一般需求都能搞定。但是所學的知識點沒有系統化，很難在技術領域繼續突破的可以加。

群號：java高級進階群654675708備注好信息！
6.阿里Java高級大牛直播講解知識點，分享知識，多年工作經驗的梳理和總結，帶著大家全面、科學地建立自己的技術體系和技術認知！

成就他人