-- 會員 / 註冊 --  
 帳號:
 密碼:
  | 註冊 | 忘記密碼
3/26 新書到! 3/19 新書到! 3/14 新書到! 12/12 新書到!
購書流程Q & A站務留言版客服信箱
3ds MaxMayaRhinoAfter EffectsSketchUpZBrushPainterUnity
PhotoShopAutoCadMasterCamSolidWorksCreoUGRevitNuke
C#CC++Java遊戲程式Linux嵌入式PLCFPGAMatlab
駭客資料庫搜索引擎影像處理FluentVR+ARANSYS深度學習
單晶片AVROpenGLArduinoRaspberry Pi電路設計CadenceProtel
HadoopPythonStm32CortexLabview手機程式AndroidiPhone
可查書名,作者,ISBN,3dwoo書號
詳細書籍分類

大型網站技術架構演進與性能優化

( 簡體 字)
作者:許令波類別:1. -> 程式設計 -> 綜合
譯者:
出版社:電子工業出版社大型網站技術架構演進與性能優化 3dWoo書號: 49382
詢問書籍請說出此書號!

缺書
NT售價: 395

出版日:7/1/2018
頁數:216
光碟數:0
站長推薦:
印刷:黑白印刷語系: ( 簡體 版 )
加入購物車 加到我的最愛
(請先登入會員)
ISBN:9787121341359
作者序 | 譯者序 | 前言 | 內容簡介 | 目錄 | 
(簡體書上所述之下載連結耗時費功, 恕不適用在台灣, 若讀者需要請自行嘗試, 恕不保證)
作者序:

譯者序:

前言:

從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人時,業務平臺就慢慢解散了:因為隨著技術團隊分工越來越細,它的專業度也會越來越深,統一的架構師團隊顯然已經無法支撐這么多的業務團隊了。在這種情況下,業務平臺就被拆解分散到各個技術產品團隊中,業務平臺的Leader也成為新的技術團隊的Leader。
中間件團隊在建立伊始,一定要和業務團隊保持緊密關聯,同時,一些中間件產品最好是發展得比較完善后,再獨立,這會比較好。
不過凡事都不是絕對的,人與人之間最大的問題其實就是信任問題。公司內部同事之間的協作最大的問題來自于利益的分配,團隊之間合作最和諧的方式就是既有合作又有制約。這其中很多都是出于業務上的考慮。除了上面所介紹的,還有一個在組織結構上對技術影響比較大的事件——中臺的提出——我們后面會介紹。
四、工程師文化的形成
在我看來,所謂的工程師文化是指就算沒有KPI的考核,大家仍然還會認為某些事情是應該做的,而某些事情是不應該做的。例如,遇到問題必須追根溯源、敬畏線上的每次變更并力保穩定性、在技術溝通上對事不對人、簡單坦誠、做事不給自己也不給別人挖坑等。
筆者感受比較深的是如果一家公司有一個類似雙11這樣的集中活動,那么對公司就是一次技術水平的大考,在這種壓力下,在技術上要追求極致,工程師文化就自然而然地、有默契地形成了。因此,像雙11這種活動能取得大家共識的公共事件可以在很大程度上推動技術的發展。
工程師文化和每個公司目前所處的環境和階段也是息息相關的。如果一個創業公司每天面臨著如何生存的問題,而員工卻在考慮技術的設計是否完美,顯然不是太現實。在這種情況下,業務開發的效率和穩定性會更重要。不過,長久來看,該還的債終究是要還的,一個好的工程師文化的建立對公司未來的良好發展至關重要。
內容簡介:

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

目錄:

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
序: