大型網站技術架構演進與性能優化（簡體書）

本書從一名親歷者的角度，闡述了一個網站在業務量飛速發展的過程中所遇到的技術轉型等各種問題及解決思路。從技術發展上看，網站經歷了Web應用系統從分布式、無線多端、中台到國際化的改造；在解決大流量問題的方向上，涉及了從端的優化到管道到服務端甚至到基礎環境優化的各個層面。書中總結的寶貴經驗教訓可以幫助讀者瞭解當網站遇到類似問題時，應如何思考不同的解決思路、為什麼要這樣做、並最終做出合適的方案選擇。

2009年加入淘寶，一直關注性能優化領域，經歷了淘寶PV從1億到10億的發展歷程，參與了淘寶高訪問量Web系統模板引擎的改造、靜態化、無線化、CDN等優化改造項目。先後研究過分布式數據庫Cassandra系統、Tomcat、Jetty等系統的源碼。一直參與淘寶訪問量高的系統頁面詳情系統的優化工作，設計並實現了sketch模板引擎、MVC框架Feiba等，將服務端性能提升近50%左右；所在的性能優化小組一直在做詳情的前端優化，將詳情頁的首屏展示時間縮短為1s之內。著有技術暢銷書《深入分析Java Web技術內幕（修訂版）》一書

前言
從1億到50億的技術之路

從2009年到2016年，筆者非常幸運地經歷了網站PV從1億到50億的飛速發展歷程，在此過程中積累了一些大流量高併發網站架構設計和優化的經驗。從技術發展來看，筆者經歷了Web應用系統從分布式、無線多端、中台到國際化的改造；在解決大流量問題的方向上，積累了很多從端的優化到管道到服務端甚至到基礎環境優化的經驗。現在您手頭這本書所介紹的內容，大部分是筆者看到、學到的，是親身參與和實踐的經驗。
本書要表達的內容並不是簡單羅列所做過的事情，而主要是幫助讀者瞭解當網站遇到類似問題時，應如何思考不同的解決思路、為什麼要這樣做、如何做出最終的方案選擇……其實每種架構的選擇必然有它專屬的現實場景，因此本書涉及的這些話題也不一定就是最完美的解決方案。但，我希望本書的分享能啟發大家在解決類似問題時的思考和判斷。
一、架構演進之路
本書分成上下兩篇。上篇主要介紹整個網站由於業務發展所經歷的幾次主要的架構演進，包括：從PHP到Java的改造、分布式改造、無線化改造、中台的改造、國際化改造。下篇主要介紹如何從不同的層次解決整個網站在大流量情況下遇到的性能瓶頸，包括端和管道的優化、應用層代碼級優化、應用架構的優化、端到端的全鏈路優化。最後介紹在做架構和性能優化的過程中必須面對的穩定性問題――如何體系化地解決網站的穩定性，這是非常關鍵的。
階段一 從PHP到Java很多網站早期都是基於Linux+Apache+MySQL+PHP架構的網站，從當時來看，這種非常流行的個人網站架構的確也非常匹配當時的發展狀態。PHP語言的特性是快速發佈，從頁面渲染到數據庫訪問，均可以在一個頁面裡全部搞定。
即使放到今天，這種架構仍然還有很多人在用，它的優點就是非常簡單高效，但缺點也非常明顯：擴展性和分布式不好，不適合企業級的、複雜業務邏輯的大規模協同開發。
隨著網站的發展，大家覺得應該將PHP切換到Java。為什麼要切換到Java語言呢？一般來說，企業選擇開發語言會有如下考慮。
（1）語言本身的特性。每種語言開發出來都有它的特性和所適合的場景，像Python、PHP這類腳本語言非常適合快速簡單的開發方式，而Java則比較適合構建複雜業務邏輯的企業級開發，但是開發效率會比PHP要差一點。
（2）程序員隊伍。企業選擇何種開發語言，還要看市場上的人才隊伍是不是足夠大，是不是有很高層次的人才。是否有高層次的人才，取決於當前的行業老大是不是也在用這種語言，比如當前的頂級互聯網公司如果在用Java，那麼自然這些公司的Java人才比較多，這樣，他們的經驗可以被快速複製到其他公司中。
（3）語言所對應的工具生態是否完善。一個語言是否有生命力，要看這個語言對應的生態工具是否完善，它的社區是否活躍。因為我們要用到各種工具，而我們也不可能自己去寫每種工具，因此，是否能方便地利用開源工具，快速提升開發效率也是非常關鍵的。像現在很多大公司開源了很多Java的中間件產品，這些中間件可以直接拿來使用，就不需要再重新開發了。
綜合以上因素，電商網站選擇Java語言作為主要的系統開發語言是非常合適的。
從PHP切換到Java後，整個網站採用WebX+EJB+iBatis+JBoss+Oracle（後面又將EJB改成Spring）的架構，但是隨著業務量的不斷增大，存儲層的瓶頸暴露出來。為了解決存儲問題，就逐漸用上了非常昂貴的IBM小型機、Oracle的數據庫以及EMC的高端存儲（IOE）；並對數據庫做了分庫的拆分，分布式緩存（Tair）也隨之誕生，分布式文件系統TFS開始出現，CDN也慢慢建立了。
階段二 分布式改造
所謂分布式改造，就是儘量讓系統無狀態化，或者讓有狀態的信息封裝在一定範圍內，以免限制應用的橫向擴展。簡單來說，就是即便某個應用的少數服務器“宕”掉，也不會影響整體業務的穩定性。
要實現應用的分布式改造必須先解決以下幾個問題。
（1）把應用微服務化：即將大量粗粒度的應用邏輯拆小，做服務化改造。
（2）必須先建立分布式服務框架。必須具備分布式RPC框架、異步消息系統、分布式數據層、分布式文件系統、和服務的發現、註冊和管理。
（3）必須要解決分布式Session問題。
為了做業務的服務化改造，我們大量拆分了當時的業務系統，形成了商品中心、交易中心、用戶中心、店鋪中心。這些服務作為底層服務供上層的前臺系統調用。
現在來看，系統的分布式改造為網站接下來5年的發展奠定了很好的基礎，整個網站的擴展性非常好。幾乎每個初創企業都必須經歷一次分布式化的改造，才能為企業的長期發展奠定基礎。筆者前面提及的幾個重要的中間件產品和關鍵的分布式Session等技術在《深入分析Java Web技術內幕（修訂版）》一書中有詳細的介紹，感興趣的讀者可以自行去學習瞭解。
階段三 無線化改造
到了2013年，無線技術已經非常火爆了。在此之前，無線的業務總是跟著PC走，基本上是PC做好後無線再複製一份，而且無線和PC還不是同一個前臺系統，導致一個功能要做兩遍，並且無線部門的開發人員本來就不多。這些給業務的發展帶來很多問題。因此2013年底，啟動了All in 無線項目，目標就是用一套系統、一套架構快速支撐多端的個性化，並在服務端做了很多模塊化和組件化的改造。
隨著無線技術的發展，我們也開始嘗試一些新技術，最具代表性的就是Node。 Node在業界很火，前端同學非常推崇，而且它也大幅提升了前端的開發效率和體驗。目前大家也多方嘗試使用Node技術，並且用在一些業務線上。但是，從今天來看，Node並沒有達到我們想像中的發展前景。這其中有多種原因，本書的後續章節會專門介紹網站的無線化改造實踐，也將分享Node在實際使用中的一些思考。
階段四 中台改造
中台這個概念早期是由美軍的作戰體系演化而來的，技術上的“中台”主要是指學習這種高效、靈活和強大的指揮作戰體系。電商經過十幾年的發展，組織已經龐大而複雜，業務不斷細化拆分，也導致野蠻發展的系統越來越不可維護，開發和改造效率極低，也有很多新業務不得不重複造輪子，所以中台的目標是為了解決效率問題，同時降低創新成本。書中會有單獨的一章介紹筆者看到、學到的中台的實踐和思考。
階段五 國際化
國際化一般會有兩種思路：一種是一套原始代碼部署到多個地方，各地的系統基本沒有什麼關聯、保持相互獨立，每個地方再根據本地實際情況做一些個性化的定制。一般來說，會精簡原始代碼，減少不必要的依賴。這種思路在一些跨國公司用得比較多，但是這個對技術要求比較低，不是我們介紹的重點。
另一種思路就是我們要介紹的國際化，它主要是解決如何將一套系統部署到多地的問題。一般國際化有兩個發展階段：第一個階段是在國內實現了交易的單元化；第二個階段是實現了中美的跨國部署。
國際化的本質仍然是要解決以下的通用問題：多語言問題、多時區問題、數據路由問題、全球數據的同步與複製問題。這些內容我們將在第5章介紹，提供一些可參考的通用思路。
二、挑戰性能瓶頸
從第5章開始將介紹網站PV量從1億到50億的發展過程中應用系統遇到的各種性能瓶頸，以及我們的解決方案。這個過程可大致分為3個時間段。
第1個時間段：主要解決網站的易用性和擴展性問題。例如當時提的“去IOE”就是將數據庫從Oracle遷到MySQL上，通過分庫分表來解決擴展性問題，同時做了很多網頁端的優化工作，如JavaScript（以下簡稱JS）的異步加載、首屏優先渲染等。
第2個時間段：這段時間網站的流量增長非常迅速，每年雙11的流量更是異常瘋狂，系統出現了性能瓶頸。記得某次評估雙11的流量，光詳情頁系統就需要增加上萬台服務器，簡直無法想像！所以必須考慮用非常規手段來優化性能。這個階段我們主要通過靜態化技術來解決讀系統的性能瓶頸，大概用了1～2年的時間來持續迭代，直到實現了靜態化系統改造才算徹底解決了性能問題，使系統能夠支持上百萬的QPS。
第3個時間段：由於業務系統的複雜性上升非常快、業務的耦合度比較高，給系統的穩定性帶來很大挑戰，所以這個階段進行了系統的穩定性建設，產出了很多穩定性工具和產品，另外性能優化也更朝著架構優化的方向發展。
我們還做了很多提升應用性能和開發效率的工作。
從端到中間的管道、再到應用層以及基礎設施的優化，本書會分成4項內容章來介紹：應用層代碼優化、應用架構的優化、全鏈路的優化和基礎設施的優化。
最後一章我們會介紹在整個網站飛速發展的同時，如何在進行架構的升級、應對突發的大流量這些極端的情況下，仍能保持整體網站的高可用和穩定性。至於如何做好雙11的穩定性，這些內容已有多次的分享，本章會做一些系統的介紹。
三、組織架構的變遷
如果說技術是生產力，那麼組織就決定了生產關係了，而生產關係要適應生產力的發展。筆者當時所在的團隊是業務平臺，可以理解成技術大團隊中的架構師團隊，本身沒有具體的業務產品，專注於解決一些橫向的、架構上的問題。一般每個重要項目中都會有一名架構師參與，業務平臺和業務的關聯比較直接、緊密。
中間件團隊和業務平臺相比，則和業務的距離稍微遠一點，專注于業務開發過程中偏公共和通用的技術組件。這個團隊和業務也相對比較緊密，業務開發中一些通用的技術組件，例如同步遠程調用RPC框架、異步通信消息框架、業務動態配置框架、Web開發框架、分布式數據層、分布式Session框架等，都是在業務開發中會用到且需要統一和規範使用的通用組件。
由於業務平臺、中間件團隊和業務的關係相對緊密，因此團隊的組織關係一定要和業務開發捆綁在一起。在早期，這兩個團隊的Leader最好也是業務開發團隊的Leader，而且這個Leader要有強力的話語權。否則這兩個團隊的業務很難落地。架構師和中間件團隊可以理解為業務開發中偏精英一點的團隊，從長期發展來看，業務開發也有強烈的意願要往偏技術的方向發展，所以他們的關係不一定是長期穩定的。
當技術團隊人員擴張到接近1000人時，業務平臺就慢慢解散了：

1 構建大型網站：分布式改造 1
1.1 為什麼要做分布式化 1
1.2 典型的分布式架構 2
1.3 分布式配置框架 4
1.4 分布式RPC框架 6
1.5 分布式消息框架 8
1.6 分布式數據層 11
1.7 分布式文件系統 12
1.8 應用的服務化改造 15
1.9 分布式化遇到的典型問題 16
1.10 分布式消息通道服務的設計 19
1.11 典型的分布式集群設計思路 21
1.12 總結 24
2 無線化：無線時代下的架構演進 26
2.1 無線環境下的新挑戰 26
2.2 端的演進 28
2.3 無線鏈路的優化 32
2.4 服務端的演進 36
2.5 思考：開發語言選擇的思考 44
2.6 總結 46
3 大型網站平臺化演進：大中台小前臺 49
3.1 為什麼需要中台 49
3.2 什麼是中台 53
3.3 提升中台的效率 55
3.4 中台是否能解決一切問題 64
3.5 總結 65
4 全球化下的網站演進：全球部署方案 66
4.1 國際化的背景 67
4.2 面臨的技術挑戰 68
4.3 全球部署的目標架構 69
4.4 何為單元化 69
4.5 單元化解決什麼問題 70
4.6 單元化數據分片方案 70
4.7 數據路由方案 74
4.8 接入層路由 78
4.9 服務層路由 79
4.10 數據層路由 81
4.11 Sequence ID的衝突問題 83
4.12 異地多活 84
4.13 多語言問題 85
4.14 多時區問題 86
4.15 全球數據同步與數據路由 89
4.16 通用版與定製版的選擇 90
4.17 全球化部署中遇到的坑 91
4.18 總結 92
5 應用程序優化：代碼級優化 93
5.1 優化思路 93
5.2 影響性能的關鍵因素 97
5.3 Java特性的優化 102
5.4 減少併發衝突 104
5.5 減少序列化 105
5.6 減少字符到字節的轉換 105
5.7 使用長連接 106
5.8 總結 106
6 應用架構探索：合併部署 108
6.1 什麼是架構 108
6.2 什麼是合併部署 110
6.3 能解決什麼問題 112
6.4 如何解決 114
6.5 取得的效果 118
6.6 更進一步地做多版本部署 118
6.7 關於高密度部署的思考 121
6.8 總結 122
7 鏈路優化：大秒系統的極致優化思路 123
7.1 一些數據 123
7.2 熱點隔離 124
7.3 動靜分離 125
7.4 基於時間分片削峰 133
7.5 數據分層校驗 134
7.6 實時熱點發現 136
7.7 關鍵技術優化點 137
7.8 大促熱點問題思考 140
7.9 總結 141
8 全域基礎設施優化：資源調度優化 142
8.1 什麼是資源調度 142
8.2 資源抽象層 144
8.3 物理資源調度 149
8.4 應用層調度 152
8.5 遇到的問題 155
8.6 總結 164
9 網站高可用建設：大型網站的穩定性建設 165
9.1 故障帶來的影響 165
9.2 網站的可用性指標 166
9.3 穩定性建設思路 167
9.4 高可用體系化建設 171
9.5 研發人員的轉變 180
9.6 穩定性組織保障 182
9.7 疑難問題排查思路 183
9.8 總結 190
附錄 給新人成長的幾點建議 191
參考資料 197