極客大學架構師訓練營 系統架構 第8課 聽課總結

說明

講師：李智慧

互聯網系統架構核心要素

如何衡量一個系統的架構設計？

高性能

性能是互聯網的一個重要指標，除非是沒得選擇，否則用戶無法忍受一個相應緩慢的應用。一個打開緩慢應用會導致嚴重的用戶流失，很多時候系統性能問題是系統架構升級的觸發器。可以說性能是互聯網系統架構設計的一個重要方面，任何系統架構設計方案都應該考慮可能帶來的性能問題。

也正是因爲性能問題幾乎無處不在，所以優化網站性能的手段也非常多，從用戶端到數據庫，從代碼到機房部署，影響用戶請求的所有環節都可以進行性能優化。

高可用

因爲互聯網分佈式系統使用的服務器硬件通常是普通的商用服務器，這些服務器的設計目標本身並不保證高可用，也就是說，很有可能會出現服務器硬件故障，也就是俗稱的服務器宕機。大型互聯網系統通常都有上萬臺服務器，每天都必定會有一些服務器宕機，因此係統高可用架構設計的前提是必然會出現服務器宕機，而高可用設計的目標就是當服務器宕機的時候，服務或者應用依然可用。

系統高可用的主要手段是冗餘，應用部署在多態服務器上同時提供訪問，數據存儲在多態服務器上互相備份，任何一臺服務器宕機都不會影響應用的整體可用，也不會導致數據丟失。

可伸縮

大型互聯網應用通過集羣的方式將多態服務器組成一個整體共同提供服務。所謂伸縮性是指通過不斷向集羣中加入服務器的手段來緩解不斷上升的用戶併發訪問壓力和不斷增長的數據存儲需求。

衡量架構伸縮性的主要標準就是是否可以用多態服務器構建集羣，是否容易向集羣中添加新的服務器。加入新的服務器後是否提供和原來的服務器無差別的服務。集羣中可容納的總的服務器數量是否有限制。

可擴展

不同於其它架構要素主要關注非功能需求，擴展性架構直接關注系統的功能需求。互聯網應用快速發展，功能不斷擴展，如何設計系統的架構使其能夠快速響應需求變化，是系統可擴展架構主要的目的。

衡量系統架構擴展性好壞的主要標準就是在系統增加新的業務產品時，是否可以實現對現有產品透明無影響，不需要任何改動或者很少改動既有業務功能就可以上線新產品。不同產品之間是否很少耦合，一個產品改動對其它產品無影響，其它產品和功能不需要受牽連進行改動。

可擴展架構的主要手段是事件驅動架構和分佈式服務。

安全

互聯網是開放的，任何人在任何地方都可以訪問系統。系統的安全架構就是保護系統不受惡意訪問和攻擊，保護網站的重要數據不被竊取。

衡量系統安全架構的標準就是針對現存和潛在的各種攻擊和竊取手段，是否有可靠的應對策略。

互聯網系統架構一覽

前端架構

• App 及 Web 開發技術
• 瀏覽器及 HTTP 優化技術
• CDN
• 動靜分離
• 圖片服務
• 反向代理
• DNS

前端請求的服務可以單獨部署一批服務器處理，跟通用性的後臺服務器分離。

網關及應用層架構

• 網關架構
• 負載均衡
• 動態頁面靜態化
  ☞ 比如淘寶韓版衣服一天賣出上百萬件，訪問商品詳情頁，一次需要訪問多個服務，那麼可以把該動態頁面變成靜態頁面。
• 業務拆分

服務層架構

• 微服務框架
• 分佈式消息隊列
• 分佈式緩存
• 分佈式一致性(鎖)服務

存儲層架構

• 分佈式文件
• 分佈式關係數據庫
• NoSQL 數據庫

後臺架構

• 大數據平臺
• 搜索引擎
• 推薦引擎
• 數據倉庫

運維安全

• 數據採集與展示
• 數據監控與報警
• 攻擊與維護
• 數據加密與解密

維基百科技術架構

維基百科：非盈利組織，資金來源主要來自捐款。
訪問量：全球第6大
全球有3個數據中心：韓國、澳大利亞、歐洲
技術團隊：10+個人

服務組件解析

• GeoDNS: DNS Domain Name Service，域名解析。Geo地理位置解析，選擇就近的數據中提供服務。
• LVS: 負載均衡。
• Squid caching layers: 反向代理，緩存服務器。
• Application servers(Apache): PHP
• Image server(Lighttpd): 圖片服務器
• Distributed Object Cache(Mencached): 分佈式對象緩存。
• Core databases(MySQL): 數據庫
• External storage: 引用外部資源存儲
• Invalidation notification: 緩存失效通知，更新緩存數據。
  失效的方式：1. 過期失效(如果3分鐘); 2. 失效通知。當詞條被編輯以後，該條緩存就會被刪除。
  (一般緩存失效的Action，都是刪除該key, value；因爲只有當下個用戶訪問該資源的時候，纔會從數據庫讀取最新的數據。後續多次讀取才會把該數據，緩存起來。)
• Search(Lucene): Lucene 全文檢索。

淘寶早期技術演化

姓名：吳澤明（阿里合夥人）
花名：範禹（阿里合夥人）
團隊：淘寶-技術研發部-產品技術-業務平臺

淘寶 2003

2003年，馬雲老師被上帝開了上帝視角，覺得C2C纔是王道。就跟一堆技術骨幹、產品骨幹、運維骨幹說，他要重新創業，願不願意跟着他一起幹，就到馬雲老師的湖畔花園的房子裏開始開發淘寶。馬雲老師說1個月要上線，當時C2C已經很成熟，考慮時間比較短，就花了2,000美金買了個PHP網站。主要是實現排名這種模式。

淘寶 2004

“快淘!” 的顏色是紫色，跟別的紅色、黃色不搭，因爲雅虎的搜索框也是紫色的。

2004年主要的創新點，是左下角的類目體系。阿里巴巴核心的技術就是建立了類目體系。
爲什麼可以搜索到任何商品，包括比較少見的商品，就是因爲早期就把各種類目規範的很好。
一般賣家、買家的痛點，實際上就是雙方找不到對方的商品。

有了類目，就會有各個類目的運營，就有了各個類目的發展。這纔是淘寶打包EBay的關鍵。
頂尖高手都是看到問題的本質，架構師也要關注問題。

淘寶 2005

淘寶架構 2003.5~2004.1

• 非典時期
• 馬雲的湖畔花園
• LAMP
• MySQL 讀寫分離
  
  

2004.1~2004.5

• MySQL 遷移至 Oracle (垂直伸縮，花錢請Oracle專家搞定、穩定)
• 引入 SQL Relay中間件
  

2004.2 ~ 2004.10

• php 遷移至 java
  ☞ 當年阿里巴巴請Sun公司提供解決方案，因爲阿里巴巴和杭州都沒能吸引到優秀的人才, IT人才大多分佈在北上廣深。
• MVC 框架 WebX
• 項目管理工具 AntX
• 引入搜索引擎 ISearch (雅虎搜索引擎)
  

2004.10 ~ 2006.10

• weblogic 遷移至jboss (weblogic 是收費的， jboss是免費的)
• 支持分庫的數據訪問框架
• 拋棄 EJB
• 引入 Spring
• 引入 BDB 的緩存， ESI
• 建立 CDN
• 類目屬性體系
  

2006.10 ~ 2007.10

業務中心化

2007年，主要的業務都在一個系統（Denali）裏面，經過前面幾年的快速發展，這個系統越來越龐大，同時工程師人數也越來越多，很多地方已經開始出現瓶頸。

• 開發效率：開發工程師，“打包部署一次，半小時過去了，打包一次部署失敗，半天過去了”。
• 需求響應時間：代碼合併、發佈協調、系統發佈進入“火車模型”，火車晚點習以爲常。
• 數據庫連接池：訪問量增加，只好不斷增加 Denali 機器，連接池不夠用了。
• 故障不能很好隔離：一個小功能的故障，導致了整個系統的故障。

應對策略

• 拆分系統：
  ☞ UIC（用戶中心），第一個業務中心在2008年初上線。
  ☞ 千島湖項目，交易中心（TC）；類目屬性中心（Forest）。
  ☞ 五彩石項目，店鋪中心（SC）、商品中心（IC）；評價中心（RC）。
• 拆分數據庫：與業務中心對應、垂直拆分。
• 組織結構支持：
  ☞ 垂直化
  ☞ 產品化
  ☞ 服務化
  

架構升級後

2009 年底，經過幾個重大項目及多個小項目，基本完成了整個系統的業務中心化改造，這時候系統看上去挺美：

• 系統職責清晰、分工明確：系統結構圖看上去不錯，團隊分工也日漸成熟。
• 可維護性：配置實時推送、動態部署…
• 可擴展性: 應用集羣簡單通過水平伸縮就可以支持更多的訪問量。

然而，新的問題開始出現…

簡化 & 監控

穩定性面臨嚴峻挑戰，故障感覺是接連不斷。

• 應用拆分、增加變得不可控：
  ☞ 2008年71個服務；2009年187個服務；2010年 329個服務；
  ☞ 拆分粒度越來越細，矯枉過正。
• 系統依賴關係越來越複雜：
  ☞ 一個非關鍵路徑的系統故障卻影響到了主交易開發人員已經很難搞清楚一次請求後面的系統調用。等出現了故障，才知道哪裏碰到了瓶頸。
• 業務上也有了新的發展
  ☞ 秒殺變得流行
  ☞ 店鋪、詳情頁面的賣家裝修，個性化，頁面變得越來越大，渲染也越來越複雜等等。

簡化 & 監控

穩定性的嚴峻形勢，迫使我們重新審視淘寶的系統，並採取了一系列措施：

• 系統監控：哈勃、CSP等系統，首先讓系統運行情況透明化，瓶頸分析。
• 容量規則：提前做好準備。
• 簡化系統結構
  ☞ Cache，基於數據做交換，而不是每次都遠程接口調用。
  ☞ 異步解耦，按需加載，弱依賴降級容錯…
• 關鍵系統的優化，提升QPS
  ☞ 集中力量優化、簡化交易過程相關係統。
  ☞ 設計專門的秒殺系統。

數據存儲、檢索

2010~2011最近1年，在這方面做了較多工作：

• 商品庫去小型機：
  ☞ 沒有一步到位： PCServer + Oracle + 高端存儲，80%的餘量。
• 歷史訂單查詢：
  ☞ Vsearch + BDB，較低成本解決了查詢問題。
• 用戶中心去IOE：
  ☞ IBM小型機、Oracle、Emc存儲
• 收藏夾：
  ☞ MySQL + Tair + App檢索，解決關鍵字查詢問題。
  ☞ OceanBase 研發。
• 店鋪內搜索、實時搜索引擎
  ☞ Ksearch 的研發、上線、大大節省了機器成本。
• 交易庫
  ☞ 交易按買賣家進行了切分，買家庫（主庫）從1臺小型機擴展到了2臺，代碼層面支持了水平擴展，爲後續打好基礎；
  賣家庫（讀庫）使用了PCServer，解決了大賣家查詢影響交易的問題。
• 交易快照、Notify
  ☞ TFS、MySQL、持久化Tair
  ☞ Notify從Oracle到MySQL
• 搜索Dump中心建設
  ☞ 利用Hadoop集羣計算，提升效率；減少DB重複工作。

宅米網技術變遷

初創互聯網公司的技術發展之路

• 宅米業務規模變遷。
• 宅米技術架構體系變遷。
• 宅米技術團隊組織變遷。

成立於2014年11月，通過首創的寢室便利店模式成爲中國發展速度最快，規模最大的校園生活服務平臺。

訂單峯值在晚上9~11點鐘。場景爲小賣部開到學生宿舍裏面，賣主也是勤工儉學的學生。

架構 1.0

架構 1.0 的挑戰：

• 數據庫負載壓力大
• 請求響應速度慢
• 50 萬 峯值訂單

京東 2012 年，日訂單在 70萬；
美團 2015 年，最大日訂單 200萬；

架構 2.0

架構 2.0 的挑戰：

• 代碼耦合嚴重，相同代碼重複開發。
• 訂單表達到數據庫存儲極限
• 200 萬峯值訂單

架構 3.0

大數據平臺

技術部組織架構 1.0

技術人員數量：2~3

技術部組織架構 2.0

技術人員數量：10+

技術部組織架構 3.0

技術人員數量：50+

創業公司技術團隊管理

構建自驅動的閉環

• 不要分配任務，去完成目標而不是完成工作。
• 加班既不是目的也不是手段。
• 亡羊補牢，沒事不要瞎折騰。（人都有判斷錯誤的時候，可以先等待着，看看會不會發生。發生了纔去把問題解決了，大家才知道問題是你解決的。否則你把問題解決了，別人也不認可是你做的。）

只有優秀的員工才能創建出優秀的企業

• 爲員工的成長買單。
• 先關注人，後關注事。
• 快樂工作。

新浪微博 2010

• 新浪微博從 0 ~ 50,000,000 用戶
• 技術架構經歷了 3 個階段

新浪微博架構 1.0

新浪微博第一個版本：1個產品經理、1個後端、1個前端，一週開發出來。
想清楚的問題都很簡單。

技術特點

• 微博本質是解決發表 / 訂閱問題。
• 第 1 版採用推消息模式，將發表 / 訂閱簡化成 insert / select 問題
  大V發微博的時候，給每個粉絲insert一條記錄。粉絲登錄的時候，select自己的表記錄即可。

技術細節

• 典型 LAMP 架構
• MySQL：單庫單表，MylSAM
  ☞ MPSS（Multi-Port Single Server）
  

快速成長

• 用戶快速增長。
• 出現發表延遲現象，尤其是明星用戶。

架構演變

• 分發推送是造成發表延遲首因
  ☞ 模式改進
• 數據規模增大也代理一定延遲
  ☞ 規模增大： 數據拆分
  ☞ 鎖表問題： 改變引擎
  ☞ 發表過慢： 異步方式

新浪微博架構 2.0

投遞模式優化

• 推模式改進，不需要推送所用用戶
• 存儲及發表峯值壓力減輕
• 投遞延遲減小

數據拆分

• 優先按時間維度拆分
• 內容和索引分開存放
• 內容使用 key-value 方式存儲（NoSQL）
• 索引由於分頁訪問，拆分有挑戰

異步處理

• 發表異步化
• 發表速度及可靠性得到提高
• 使用 MemcachQ
  ☞ 增加 stats queue，適合大規模運維

技術細節

• InnoDB 引進，避免鎖表煩惱
• PHP 中的libmemcached 代替 memcache
  ☞ 在高併發下穩定性極大提高

高速發展

• 系統問題
  ☞ 單點故障、“雪崩”
  ☞ 訪問速度，國內複雜網絡環境
• 數據壓力及峯值
  ☞ MySQL 複製延遲、慢查詢
  ☞ 熱門事件微博發表量，明星評論及粉絲

如何改進

• 系統方面
  ☞ 允許任意模塊失敗
  ☞ 靜態內容 CDN 加速
• 數據壓力及峯值
  ☞ 將數據、功能、部署儘可能拆分
  ☞ 提前容量規劃

平臺化需求

• Web 系統
  ☞ 有用戶行爲纔有請求
• API 系統
  ☞ 輪詢請求
  ☞ 峯值不明顯
  ☞ 用戶行爲很難預測
• 系統規模持續增大
• 平臺化需求
• 新的架構如何設計？

新浪微博架構 3.0

平臺服務

• 平臺服務和應用服務分開，模塊隔離。
• 新微博引擎，實現 Feed Cache 分層。
• 關係多維度索引結構，性能極大提高。
• 計數服務改成基於偏移，更高的一致性、低延遲。

問題本質

• 解決高訪問量、海量數據規模下
• 易於擴展、低延遲
• 高可用
• 異地分佈能力

推薦書籍

注意：以上信息如有侵權，請聯繫作者刪除，謝謝。