<系統架構>

• 指的是互聯網的系統架構 (分布式系統架構)

• 因為現今大多數的應用系統都建立在互聯網上

• 傳統企業系統其客戶大多是內部員工與互聯網廣大的用戶不同

• 主要談論分布式系統架構

<互聯網系統架構面臨的挑戰>

• 對系統架構的要求

高併發、大流量

• 高併發的用戶

• 大流量的訪問

高可用

• 系統需 7 x 24 不間斷服務

• 即使升級硬件或軟件時，依然必須保持高可用

• 用戶感受不到停機和升級

海量數據

• 需要儲存、管理海量數據

用戶分布廣泛、網路情況複雜

• 為全球用戶提供服務

• 各地網路情況千差萬別

• 營運商網路互通難

• 需管理多個數據中心

安全環境惡劣

• 互聯網是開放性的

• 更容易遭受駭客攻擊

• 須保證系統安全、防止非法訪問、數據洩密

需求快速變更、發布頻繁

• 為快速適應市場，滿足用戶需求

• 需求變化快速，產品發布頻率也提高

• 需快速適應新功能、開發新功能

• 軟件系統如何部署

• 軟件版本如何管理

• 模塊如何分解

• 解決 - 微服務架構

漸進式發展

• 所有大型互聯網均是從一個小網站，漸進發展起來的

• 系統架構如何因應由小到大、緩慢變化的過程

• 系統架構本身如何漸進式發展

<應對高併發挑戰的兩個技術方向>

高併發為互聯網最中心問題

• 高併發 - 大量用戶同時對系統提交請求

• 系統需同時進行服務處理

• 為每個用戶創立線程或進程

• 消耗一定的 CPU

• 佔據一定內存

• 消耗一定的磁盤訪問

• 消耗一定的網路帶寬空間

• 系統必須提供足夠多的系統資源

• 挑戰

• 如何提供計算資源

• 如何構建系統，使資源能夠有效整合，為用戶提供服務

兩種技術思路

垂直伸縮

• 增強單一服務器的功能、計算能力去提升系統處理能力

• 通過升級單一服務器硬件及網路吞吐能力實現

• 方法

• 使用 RAID 增加 I/O 吞吐能力

• 使用 SSD 改善 I/O 訪問速度

• 增加內存減少 I/O 操作

• 升級網路接口或增加網路接口提高網路吞吐能力

• 更新服務器，使用更多處理器或更多超線程

• 缺點

• 達到某個程度後，增加計算能力需要更多的花費

• 服務器有物理極限

• 互聯網應用幾乎沒有極限

• 操作系統的設計或應用程序自身制約垂直伸縮

• 隨著操作系統管理的資源越來越大

• 操作系統設計的複雜性也越來越大

• 應用程序設計的複雜性也越來越大

• 操作系統設計及應用程序設計也有極限

• 大部分情況下都不會使用垂直伸縮

水平伸縮 (分布式系統)

• 通過增加同類服務器提升計算能力的一類架構方法

• 將服務器構成一個集群

• 共同對外提供服務

• 共同處理用戶併發的請求

• 克服垂直伸縮單位計算成本隨計算能力增加而迅速飆升的問題

• 可以增加更多服務器，不會遭遇單台服務器的極限

• 是互聯網架構主要的技術手段及關鍵架構方法

• 應對互聯網本身漸進式發展的趨勢、發展的路徑

• 互聯網架構

• 如何構建服務器程一個集群

• 各服務器分別承擔甚麼角色

• 各服務器如何構建成一個系統

• 如何共同對外服務

• 以滿足高併發用戶請求的壓力

• 學習各種分布式技術，就是來解決上述問題

• 分布式緩存如何作集群、如何伸縮

• 負載均衡服務器如何作集群、如何伸縮

• 分布式數據庫如何作集群、如何伸縮

• 各服務器運行甚麼程序、如何通信

比較



• 虛線 - 垂直伸縮

• 早期(物理限制之前) - 線性增加

• 後期 - 指數增加

• 實線 - 水平伸縮

• 早期 - 可能比垂直伸縮高一些

• 後期 - 增加比垂直伸縮平穩，約略為線性增加

<分布式架構演化>

第零階段 - 最簡單的互聯網應用架構 (單一服務器)



• 最簡單的互聯網應用架構

• 功能簡單

• 用戶少

• 系統結構簡單

• 爭用同一台服務器的資源

第一階段 - 應用和數據分離



• 應用程序、文件系統及數據庫系統各自部署在一個獨立的服務器上

• 文件: 應用程序的靜態資源

• CSS，Javascript, 圖片、影音檔...

• 相當於提升三倍的服務資源

• 簡單的服務器集群

• 這種分離對系統架構及技術要求的挑戰比較低

• 將原本 localhost 的數據庫改成遠程調用

• 將本地的文件系統轉成 mount 遠程的文件系統 

• 用最小的技術成本和代價提升計算機處理能力

• 代表互聯網架構最核心的思路

• 利用不斷地增加服務器，提升系統處理的能力

第二階段 - 使用緩存改善系統性能



• 在應用程序與低速的存儲服務中，插入一個高速的存儲服務 (緩存)

• 高速 - 內存

• 低速 - 硬碟

• 先在高速緩存中提取數據

• 若不存在再從低速緩存中提取數據，並用新數據更新緩存

• 分類

• 本地緩存

• 分布式遠程緩存

• 可形成緩存服務器集群，有多台緩存服務器

• 順序

• 本地緩存 -> 分布式遠程緩存 -> 數據或文件服務器

• 功用

• 加快數據訪問速度

• 緩存通常儲存計算後結果，也可以減輕應用程序計算時間

• 降低文件及數據庫系統的訪問壓力

第三階段 - 使用應用服務器群及改善系統併發處理能力



• 建立應用服務器集群

• 通過負載均衡調度服務器，將併發請求分發給不同的服務器

• 解決第二階段使用緩存後，高併發瓶頸落到應用程序的問題

第四階段 - 數據庫讀寫分離



• 原因

• 當第四階段應用服務器集群處理資料時，有些計算操作與數據庫相關

• 當寫入時也必須寫如數據庫中

• 但數據庫只有一台，便成為瓶頸，應用服務器集群會等待數據庫的處理結果

• 解決

• 使用主從分離方式的數據庫，實現讀寫分離

• 資料寫入主數據庫

• 通過數據庫間的主從複製，更新從數據庫

• 資料由從服務器處讀取

• 由 "數據訪問模塊" 自動處理主從的寫或讀，應用程序不用區分主從

第五階段 - 使用反向代理和 CDN 加速網站響應



• CDN 內容分發網路

• 部署於網路營運商機房的服務器

• 將用戶想要的數據直接緩存CDN

• CDN服務器 = 在網路營運商機房的一台緩存服務器

• 通常為一些靜態的數據及靜態的資源

• 若訪問的資源不在 CDN 中，將透過 "反向代理服務器" 

• 反向代理服務器 = 在各地數據中心的緩存服務器

• 正向代理 - 代理使用者訪問目標網站

• 反向代理 - 代理目標網站服務使用者

• 代理整個機房提供服務

• 請求

• 絕大部分的請求，通過 CDN 返回

• 剩下小部分中的絕大部分請求，通過反向代理服務器返回

• 只有小部分中的小部分請求會通過負載均衡服務器，由應用服務器返回

第六階段 - 使用分布式文件系統和分布式數據庫系統



• 原因

• 第五階段雖然也是數據庫讀寫分離，但

• 整個數據庫存儲能力並沒有提升，主從數據庫是一樣的

• 數據庫只能寫入主數據庫，只有一台服務器處理寫的操作

• 若存儲的數據特別多，則無法寫入單一數據庫

• 解決

• 使用分布式數據庫集群

• 對數據進行分片處理

• 文件系統也可以形成分布式集群

• 透過 "統一數據訪問模塊" 對分布式緩存、分布式文件、分布式數據庫進行統一介面的存儲

• 當需要更多的文件或數據庫時，僅需增加分布式文件或數據庫服務器

第七階段 - 使用 NoSQL 和搜尋引擎



• 增進數據庫的查找操作

• 普通數據庫的問題

• 對模糊查找支持不足

• 對複雜的操作，處理較慢

• 可通過搜索引擎及 NoSQL來改善

• 數據的存儲能力

• 數據的查詢速度

第八階段 - 業務拆分



• 功能面隨系統及用戶需求不斷增加，使系統越趨複雜

• 對複雜的功能進行業務拆分

• 將不同業務，拆分至不同的應用服務器集群

• 好處

• 開發、維護更簡單

• 擴容、集群的伸縮更加靈活

• 系統整體處理能力更加強大

• 業務的發展也變得更加靈活和快速

• 各業務服務間

• 透過 RPC 、HTTP 進行相互調用

• 透過異部的消息對列進行通信

• 業務間進行依賴和調用，但沒有直接耦合

第九階段 - 微服務及中台化



• 拆分後的業務服務，可能會依賴一些共同的服務

• 將這些不同的公用服務拆分出來，構建一個個獨立的微服務集群 (中台)

• 各業務服務均依賴這些不同的微服務集群

• 提供業務服務一些基礎的服務

• 可以利用中台服務，快速構建新的業務服務

• 微服務式為目前互聯網架構的主要架構模式

• 微服務的調用如何完成

• 微服務本身如何設計

• 微服務間的依賴關係如何設計

• 如何對微服務進行建模

• 如何對微服務進行設計

第十階段 - 大數據與智能化



• 之前的互聯網主要提供

• 各式各樣的功能和服務

• 由用戶對它進行訪問

• 所有功能服務對用戶而言是統一的

• 如何對不同的用戶提供不同的服務?

• 根據用戶個人的自身特點提供不同的服務

• 使系統顯現智能的特點

• 如今日頭條依據不同用戶，提供不同頭條

• 千人千面，個性化推薦 --> 大數據與智能化技術

• 通過大數據進行分析、挖掘

• 發現不同用戶的偏好

<架構模式與要素>

架構模式

• 模式描述一個不斷重複發生的問題及該問題解決方案的核心

• 關鍵在模式的可重複性

• 問題、場景可重複性

• 解決方案可重複使用

模式

分層

• 將系統在橫向維度上切分成幾個部分

• 每個部份負責相對比較單一的職責

• 通過上層對下層依賴調用組成一個完整的系統

• 分層以後的模塊或層次可以進行分布式部署

• Example

• 視圖層 (UI)

• 應用邏輯層

• 公用服務層

• 基礎設施層

• 存儲層

分割

• 將系統在縱向方面對軟體進行切分

• 將不同功能和服務分割

• 包裝成高內聚低耦合的模塊

• 分割以後的功能和服務可以進行分布式部署

• 好處

• 便於不同模塊的分布式部署

• 提高網站併發處理能力及功能擴展能力

• 可與分層合用，進行系統切割，切割後的模塊可以分布式部署

• 獨立的發展

• 獨立的演化

• 獨立的維護

• 獨立的集群部署

分布式

• 將分層分割後的模塊部署在不同的服務器上

• 通過遠程調用協同工作

• 使用更多計算機，得到更多資源、處理更多併發訪問與數據量

• Example

• 分布式應用和服務

• 分布式靜態資源

• 分布式數據和存儲

• 分布式計算

集群

• 將獨立部署的服務器集群化

• 將多台相同應用的服務器構成一個集群

• 通過負載均衡設備對外提供服務

緩存

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

• 是改善軟件性能的第一手段

• 構建多級緩存架構

• Example

• CDN

• 反向代理

• 本地緩存

• 遠程緩存

異步

• 降低軟件耦合性

• 系統解耦合的重要手段

• 另外還有分層、分割、分布式

• 將一個業務操作分成多個階段

• 每個階段透過共享數據而不是直接調用的方訪進行協作

• 透過消息對列

• 作用

• 提高系統可用性

• 加快網站響應速度

• 消除併發訪問高峰

冗餘

• 保證在服務器當機的情況下，應用依然可以繼續服務

• 作法

• 服務器冗餘運行

• 數據冗餘備份

自動化

• 在無人值守的情況下，網站可以正常運行

• 目前自動化架構設計，主要集中在運維方面

• 系統自動監控

• 自動部署

• 自動剔除壞掉的服務器

• 自動作集群擴容

安全

• 保證系統不受非法訪問影響

• Example

• 身分認證

• 透過密碼與手機校驗碼

• 加密

• 登錄、交易操作的網路通訊

• 存儲敏感數據

• 驗證碼

• 防止機器人濫用網路資源

• 編碼轉換

• 對XSS攻擊、SQL注入

• XSS: 它允許惡意使用者將程式碼注入到網頁上，其他使用者在觀看網頁時就會受到影響

• 過濾

• 垃圾信息、敏感信息

• 風險控制

• 對轉帳交易等重要操作，根據交易模式和交易信息進行控制

<系統架構核心要素>

• 衡量一個系統架構設計

高性能

• 系統性能問題是系統架構設計升級優化的觸發器

• 任何架構設計方案必須考慮可能會帶來的性能問題

• 從用戶端到數據庫，從代碼到機房部署，影響用戶請求的所有環節都可以進行性能優化

• 性能指標

• 交易響應時間 (Response Time, RT)

• TPS 響應時間

• 每秒處理交易數

• 併發數

• 性能計數器

高可用

• 高可用設計的目標就是當服務器當機的時候，服務或者應用依然可用

• 主要手段是冗餘

• 互聯網應用的硬指標

• 緩衝餘地比較低

• 任何情況下得保證系統式可用的

可伸縮

• 通過不斷向集群中加入服務器的手段來緩解不斷上升的用戶併發訪問壓力和不斷增加的數據存儲需求

• 衡量標準

• 是否可以用多台服務器構建集群

• 是否容易向集群中添加新的服務器

• 加入新的服務器後，是否可以提供和原來服務器無差別的服務

• 是否很容易加入新的服務器

• 是否不會影響其他服務器

• 集群中可容納的總服務器是否有限制

可擴展

• 直接關注系統的功能需求

• 系統架構是否能快快速響應需求變化

• 衡量標準

• 增加新的業務產品時，是否可以實現對現有產品透明無影響

• 是否不需要改動或者很少改動既有業務功能就可以上線新產品

• 不同產品之間是否很少耦合

• 主要手段

• 事件驅動架構

• 分布式微服務架構

安全

• 保護系統不受惡意訪問和攻擊

• 保護網站重要的數據不被竊取

• 對現存和潛在的各種攻擊與竊密手段，是否有可靠的應對策略

<互聯網架構技術一覽>



前端架構

• App 及 Web 開發技術

• 瀏覽器及 HTTP 優化技術

• 動靜態內容分離

• 部署上分離

• 域名上分離

• 在請求的時候分離

• 在CDN緩存靜態內容

• 圖片服務

• CDN

• 反向代理

• DNS

網關及應用層架構

• 網關架構

• 用戶請求的安全認證

• 身分識別

• 負載均衡

• 動態頁面靜態化

• 業務拆分

服務層架構

• 微服務框架

• 分布式消息對列

• 分布式緩存

• 分布式一致性(鎖)服務

存儲層架構

• 分布式文件

• 分布式關係數據庫

• NoSQL 數據庫

後臺架構

• 大數據平台

• 搜索引擎

• 推薦引擎

• 數據倉庫

• 提供數據支持服務

運維與安全

• 數據採集與展示

• 數據監控與報警

• 攻擊與防護

• 數據加密與解密

<案例>

維基百科技術架構



• GeoDNS

• 地域 DNS

• 可解析使用者IP的地理位置，回傳離使用者地理位置最近的伺服器 IP

• LVS - Linux Virtual Server

• 負載均衡服務器

• https://www.itread01.com/content/1541136860.html

• Squid Caching Layers

• 反向代理伺服器

• http://blog.faq-book.com/?p=5210

• Image Server

• 圖片伺服器

• 靜態資源文件伺服器

• Distributed Object Cache (memcached)

• 分布式緩存伺服器

• https://aws.amazon.com/tw/memcached/

• Search (Lucene)

• 搜尋引擎

• http://tw.gitbook.net/lucene/index.html

• Invalidation notification

• 詞條失效通知

• 通知詞條已被更新

淘寶業務發展及技術架構

2003.5 - 2004.1



• 業務

• B to C : 一口價

• C to C : 拍賣

• 馬雲住宅

• LAMP

• Linux

• Apache

• 應用程式集群

• MySQL

• PHP

• 買來的PHP網站做漢化

• MySQL 讀寫分離

• 主從複製

2004.1 - 2004.5

• MySQL 遷移至 Oracle

• 引入SQL Relay 中間件

• 選擇

• 垂直伸縮

• IOE (IBM 服務器、Oracle 數據庫、EMC 儲存陣列)

• 水平伸縮

• MySQL 分布式數據集群

• 技術要為業務服務

• 業務快速發展，故選擇最快速解決方案 - 垂直伸縮

• 對代碼少許改動

• 不需要改動系統架構

2004.2 - 2004.10



• PHP 遷移至 Java

• 對買來的PHP不孰悉，難以快速開發功能

• 故選擇 Java重新開發

• MVC 框架 WebX

• 自行開發

• https://blindpirate.github.io/2016/04/26/Webx%E5%88%9D%E5%AD%A6%E8%80%85%E6%95%99%E7%A8%8B/

• 項目管理工具 AntX

• 基於Ant，自行開發

• https://www.cnblogs.com/Vae1990Silence/p/4667665.html

• 引入搜尋引擎 ISearch

• 雅虎搜索引擎

2004.10 - 2006.10



• weblogic 遷移至 JBoss

• weblogic 運營部署較複雜，不適用於分布式系統

• weblogic 收費，JBoss 開源

• 支持分庫的數據訪問架構

• 拋棄 EJB

• EJB 開發維護複雜

• 代替

• Spring

• 自己的遠程調用

• 引入 Spring

• 基於 BDB 的緩存，ESI

• 建立 CDN

• 類目屬性體系

• 商品細分類、描述

2006.10 - 2007.10



• 分布式緩存 Tbstore (後來的 Tair)

• https://kknews.cc/zh-tw/tech/mk5obz2.html

• 分布式存儲 TFS

• https://developer.aliyun.com/article/224295

• 分布式搜索引擎

• https://www.infoq.cn/article/UYfNARVKZ0zxg7IR6BeQ

宅米網技術變遷

• 校園生活，寢室便利店

架構 1.0

• 挑戰

• 數據庫負載壓力大

• 數據訪問集中在特定時段

• 學期中

• 晚間

• 請求響應速度慢

• 目標 50 萬峰值訂單

• 組織

• 碰到的問題

• 一個新業務需要三組一同合作

• 當人數擴增時，溝通代價大

架構 2.0

• 解決負載壓力

• 利用緩存

• CDN

• Redis

• 分布式文件系統

• 靜態圖片服務

• 外購

• 自帶 CDN

• 數據庫讀寫分離

• 一主多從

• 一從 : 系統讀的操作

• 一從 : 大數據分析

• 主從複製

• 導入大數據平台提供業務運營數據

• kafka : 訊息對列

• 挑戰

• 代碼耦合嚴重，相同代碼重複開發

• 訂單表達到數據庫存儲極限

• 目標 200 萬峰值訂單

• 組織

• 每組各自有自己的前、後端及測試

架構 3.0

• 解決代碼耦合

• 業務，公用服務分離

• 公用服務導入微服務 (分布式服務集群)

• 解決數據庫存儲極限

• 冷熱訂單分離

• 熱訂單 : 一段時間內 (一個月、一個星期) 訂單

• 更新頻率高

• 冷訂單 : 一段時間外訂單

• 大部分僅讀取操作

• 移至其他容易擴充的數據庫

• ex: MongoDB

• 批處理任務

• 定期從熱訂單數據庫移出訂單至冷訂單數據庫

• 組織

• 架構組統籌產品及數據平台架構

大數據平台