 |
-- 會員 / 註冊 --
|
 |
|
|
|
高可用架構（第1卷） ( 簡體 字) |
| 作者：高可用架構社區 | 類別：1. -> 程式設計 -> 綜合 |
| 譯者： |
| 出版社：電子工業出版社 |  3dWoo書號： 47850
詢問書籍請說出此書號！【缺書】
NT售價： 540 元 |
| 出版日：10/1/2017 |
| 頁數：652 |
| 光碟數：0 |
|
站長推薦：   |
| 印刷：黑白印刷 | 語系： ( 簡體 版 ) |
| |
加入購物車  │加到我的最愛
(請先登入會員) |
| ISBN：9787121314667 |
| 作者序 | 譯者序 | 前言 | 內容簡介 | 目錄 | 序 |
| (簡體書上所述之下載連結耗時費功, 恕不適用在台灣, 若讀者需要請自行嘗試, 恕不保證) |
| 作者序： |
| 譯者序： |
前言：推薦序1技術沒有高低
高可用架構居然成書了，厚厚的一本，讓人贊嘆。從TimYang建立這個社群開始，我就一直參與其中，然而一切發生得如此之快，如此之自然，也是出乎意料。我想，這也是俠少約我寫序的原因之一吧。
這里面有太多熟悉的朋友，確切地說，我跟他們中的大多數人都是很好的朋友。他們都樂于將自己的所知所學分享給社區，而我也每每從他們那里學到各種技術。
你可能會驚訝于本書內容的跨度之大，從業務系統到數據庫，從容器到安全，從社區建設到行業觀察，包羅萬象。同時，講解內容又實實在在，沒有很多空話，偶有沒說清楚的地方，肯定會有問答環節來補充說明。因為都是群內聽講的人提問，所以問答也非常契合主題。
這就保證了本書在特定章節上，比大多數同類書要講得透徹、明白，適合初級人員閱讀。同時，又對中高級技術人員有更大的價值。我們經常說架構師對技術的把握要有深度，也要有廣度。廣度從何而來，只能是讀萬卷書，閱千套系統積累而來。本書無疑是一個很好的素材源泉。
具體的內容我不在此贅述，相信大家仔細閱讀后會收獲頗豐。這里我還是介紹一下背后的這群人——這個由分享者和聽眾共同組成的大群體，這個稱為高可用架構群的組織。
我經常講，高可用架構這些群，像極了《一代宗師》里的金樓。因為你仔細看，技術圈就是互聯網時代的武林。大家聚在這里，是因為在自己的領域里有所建樹，都身懷絕技面對這個世界。所以我們會看到驕傲和拼搏，也會看到爭論。因為很多人也都想著，功夫是一橫一豎，站著的才有資格說話，錯的，躺下。
但是幸運的是，他們找到了一種方式，來平息這種內心的躁動，就是通過在群里進行分享和答疑來進行“比武”。你說你的方式可行，就來分享吧。只要你的話我能懂，只要你的回答能使我滿意，我便服氣。而且慢慢地，大家也都認可了這種方式，技術領域之寬廣，并非一個人可以統領。而承認一個人在某一個領域比你強并不丟人，更并不意味著你不可以在另外的領域獨領風騷。
隨著時間的流逝，這種技術驅動的交流也慢慢發酵成了真正的友情。金樓戲里最讓我感動的一幕。葉問比武前，金樓里的各位師傅都出來幫忙。三姐說，八卦手黑，小心。賬房說，形意拳霸道，千萬別輕敵。勇哥說，追風趕月別留情，你一定得響啊。
因為過去的這些坦誠交往，那些原本會被視為對手的人，在你遇到困難的時候，可以堅定地站在你身后。而當你遇到各種行業上的新事件，也會在群里表達自己真實的聲音，期待從群里接收來自各方的諍言。
一群所學為一人學，一人可頂一群人。
這種健康的氛圍，在技術圈里也愈發變得可貴。現在互聯網在迅猛發展，很多新的技術被發明和引入了進來，碰撞和爭論在所難免。但有一些圈子卻變得特別吵鬧，為了一個框架，為了一個語言就可以爭到頭破血流，發出各種攻擊和謾罵，甚至堵上事業和人品，想想實在是讓人遺憾。
高可用架構的這群人，他們都是工作在各個公司的一線技術管理人員，掌握著業界先進的工程技術。但其實他們也很普通，跟你一樣，每天都在默默得工作和學習。不一樣的是，他們可以聚在一起，輸出這樣優質的內容。
他們對技術的追求，他們共同的性格特質，也許更值得你體會。如果看完本書，你能夠在技術理念有進一步的思考，那肯定是比看一本書本身收獲更大的。
“其實天下之大，又何止南北？勉強求全等于固步自封，在你眼中這塊餅是一個武林，對我來講是一個世界。所謂大成若缺，有缺憾才能有進步，真管用的話，南拳又何止北傳吶？”
我在葉先生出生的佛山旁邊，廣州，腦海中不斷回響這段話。
一樂環信首席架構師兼云通訊事業部總經理
推薦序2
如果去問架構師什么是架構，可能會得到很多不同的答案，每個架構師都會對“架構”有不一樣的理解，當然這不分對錯，數據架構、應用架構、物理架構、組織架構等都是架構，甚至不僅在計算機行業，各行各業都會有類似的角色，但我覺得有一個核心的概念是共通的：架構必定是長期的生產活動中，經過深度思考，積累下來的最佳實踐和可復用的合理抽象。
作為Tim叔的朋友，我也是Tim叔發起的高可用架構微信群的早期成員之一，看著高可用架構群一步步發展起來，聚集了一大批一線的互聯網架構師一起探討和交流技術和架構上的問題。同時這個群也是國內最早的一批嘗試“在線群分享”這種形式的微信群，過去技術會議的分享受限于時間和空間，在它卻這種形式下變得更加靈活和輕量，同時也能更好地沉淀下來。這里不得不提到Tim叔其人，雖然我不清楚技術群分享這個形式是否為Tim獨創，但是確是非常“Tim-ish”的一個形式，Tim是國內最早的分布式系統和高可用架構的實踐者，同時也是一個活躍的技術，Blogger，我大概從2009年開始訂閱Tim叔的Blog（后端技術），上面有很多很有價值和深度的技術文章，也算是看著Tim叔的Blog成長起來的程序員。互聯網的分享精神，在這里就是一個很好的體現。隨著近幾年國內的互聯網的蓬勃發展，新技術層出不窮，行業內也涌現出了很多優秀的工程師和架構師，Tim這兩年就聚集起這樣的一撥人，創造一個平臺，能讓大家的經驗互相分享，思想互相碰撞，這本書就是一個很棒的階段性的產物。
在一名工程師在成長的過程中，是否培養出“大局觀”是一個重要的轉折點，而快速提升自己“大局觀”的方法之一就是多觀察別人是怎么做的，并從中分析優勢和劣勢，在你面對不同的選擇時多看看別人的思考過程，見多必然識廣，也許此時你并不能直接解決自己遇到的問題，但更重要的是吸取別人的經驗，思考得更全面。這幾年隨著互聯網以及移動互聯網的爆發，后端技術迭代的速度很快，新技術層見疊出，從RDBMS到NoSQL再到最近的NewSQL；從單模塊到SOA再到微服務；從簡單的腳本部署和簡單的HA到容器化的自動部署及調度；從單機到分布式再到最近的云和Serverless……面對琳瑯滿目的設計和工具，該如何做出選擇，本書不會明確告訴你答案，但是會通過一篇篇實際案例和分享來拓展你的眼界和視野，在你面臨選擇的時候能給到你一些啟發。
本書并不是面向編程初學者的書，涉及一些比較深的內容，面也很廣，建議有一定經驗并希望更進一步的工程師和架構師閱讀，你們一定會喜歡的。
再次感謝各位分享者和架構師，也感謝Tim和高可用架構團隊的工作人員！
黃東旭PingCAPCTO
2017年8月寫于海南三亞
推薦序3
我開始以為這是從理論開始的一本講高可用的書，結果我拿到電子稿后發現上來就是很多不同公司的具體高可用的架構案例，而且是精選過的案例。從案例切入，會更加直接直觀地讓讀者去了解高可用的架構，并且也提供了非常好的可參考的實例，如果讀者在自己的場景中遇到類似問題，可以直接參考。除具體案例外，本書還通過不同公司中的系統的設計、改造的經驗來介紹高可用的原理和分布式的實踐，這個做法也比較有特色，依然選擇了從具體的實踐經驗和具體的實例出發，而沒有去憑空介紹很多道理，實踐性非常強，并且案例所涵蓋的范圍是非常廣泛的，和第1章的案例精選一樣，都來自眾的公司的實踐。結束了前兩章對高可用架構的案例和原理的介紹后，第3章用電商架構作為一個專題點進行了展開，在體量比較大的時候，利用電商的后端架構解決高可用還是有比較大挑戰的，一些電商的經驗還可以移植或者轉化到別的系統當中，比較有參考價值。第4章從容器和云計算切入，這對高可用來說是一個重要的基礎設施，不論基于公有云還是自己在內部做私有云亦或是采用混合云，云都是現在后端繞不過去的一個話題，而說到容器，就等同與說到了Docker，其輕量化以及通過Image來快速部署應用的特點，也使得Docker得到了廣泛的應用。有了容器和云的支撐，那么如何在自身運維保障上能夠適配高可用的要求，則是第5章提到的內容。沒有高效的、自動的、可靠的運維支撐，是很難保障我們系統的高可用的。再接下來就到了大數據與數據庫的部分，做高可用也好，做水平擴展也好，有狀態的節點總是最難處理的，這個章節專門針對數據庫層面去做了案例的分析，大數據本身不僅僅包括了狀態，還包括了計算，而大數據的計算往往是單個任務比較重的，那么做到高可用的挑戰和處理我們很多前臺的并發更高但是處理時長短、消耗資源小的并發任務有很大不同，這也是第6章會介紹的內容。最后一章，介紹的是安全和網工，這個部分本身為整體應用系統提供了安全的防護和保障，進而使得從用戶層面看系統是可用的。
本書的章節設置、前后的邏輯性很強，特別讓我贊嘆的是全書所有章節都是具體的案例，沒有大套的理論、空洞的說教，都是從具體實際案例出發來介紹，一方面會給讀者更強的現場感，一方面這些一個個具體的案例都是讀者可參考的，相信這本書會給讀者在高可用架構方面帶來更多的信息和收獲。
曾憲杰現任美麗聯合集團技術副總裁
推薦序4
記得我還在新浪工作的那會兒，作為一名職場工程師新人，很早就開始關注Tim的技術博客。在理想國際大廈里也常見到Tim，但那時Tim對我來說是“只可遠觀而不可褻玩焉”。
很多年過去，隨著自己在技術上的成長，我有幸加入到Tim組織的高可用架構群里。高可用群里的一項基本規則就是：大家要積極做技術分享。當時作為相對年輕的成員，我有些焦慮，畢竟與群里的大拿比較，我做的事情似乎不夠高大上。但在百度完成一段搶購類型項目后，我發現在項目中總有些值得提煉的技術可以分享，于是主動聯系了Tim并表達了分享的意愿。讓人意外的是，在Tim事先了解內容的情況下，我也順利地完成了一場人氣爆棚的群內技術分享，總體反饋是，效果不錯！事后也的確有同學聯系我，采用了我的一些思路在公司內實現了搶購方案，同樣，我也從高可用架構的其他分享里升華了技術視野，自此，我感受到了技術交流的重要性。
近兩年我參加了不少技術會議，翻譯了技術書籍，也隨著團隊內不少同學嘗試圖文、現場的技術交流，能明顯感受到技術社區的活躍以及中國技術的快速崛起。當得知高可用組織要與博文視點聯合出品《高可用架構（第1卷）》一書時，我強烈支持，能夠讓更多的人學習到高可用組織這幾年的積累，這是讓人興奮的！雖然本書中我分享的部分已經是兩年前的方案，但現在看來，其中的設計思想與問題思考依然有參考價值。在得到博文視點送來的樣書時，我又重新閱讀了書中一些大拿的技術分享，反倒相比之前通過手機閱讀文章有了更多的收獲！
所以，這本高可用架構一書，一定可以作為你技術進階路上常伴左右的好書！
呂毅鏈家大數據部負責人
前言
成為一名優秀的架構師需要哪些條件？首先需要有扎實的編程理論基礎，對軟件運作的原理以及算法有深入的理解；其次還需要有豐富的實踐，能夠將理論與實際相結合。除此之外，從他人優秀的實踐經驗中學習，是成為卓越架構師最有效的方法。筆者在剛開發微博之初，國內并沒有類似社交網絡的技術經驗，但在國外，Facebook、Twitter等公司的工程師發表的相關實踐文章，給了筆者所在團隊架構師很多啟發，團隊也順利地搭建了自己的架構，成功應對了業務的飛速增長。
搭建高并發及高可用大型系統長期都是業界難題，Twitter在創建之初，也多次出現不穩定甚至宕機的現象。不少架構師可能有同感，大型系統中任何一個小的模塊設計不慎，就可能會導致部分用戶訪問失敗，甚至全站不能訪問的后果，給用戶體驗帶來巨大的傷害。因此在微博核心系統中，團隊中的架構師將系統可用性作為設計的首要考慮因素，如履薄冰，一路走來，終于在可用性方面跟同類產品相比取得了更好的成績。類似的，系統可用性也應該是大部分互聯網系統架構最基本的要求，這也是筆者發起及參與高可用架構社區的原因。
系統的可用性在過去、現在以及未來都是架構領域最重要的一個環節，但是相關的知識并沒有太多現成的渠道可以獲取。物以類聚，人以群分，高可用架構技術社區聚集了業界關注互聯網架構的人群，并將各大一線公司具有豐富經驗的架構師在社區的分享沉淀成本書中的文章。此外社區也舉辦全國各地架構主題的技術沙龍、每年一度的全球互聯網架構大會（thegiac.com）以及以高并發為主題的編程競賽活動，是學習及了解架構最有效的圈子。本書內容是高可用架構社區眾多講師對架構領域內容的一個階段總結，也是社區長期活動的一個結晶。
帶給我們架構方面啟發的未必需要長篇大論，像上面提到的各種形式的偏重實踐的架構總結與思考的文章，往往會帶給我們更多幫助。無獨有偶，短小的技術啟迪文章在歷史上也廣受歡迎，筆者喜歡的《編程珠璣》一書中就提到，Jon Bentley在《ACM通訊》發表的有關編程的短文竟然成為了該學術期刊的王牌欄目之一，給工程師帶來的啟發一直影響至今。希望本書中各種架構設計思想，也能夠長期伴隨讀者的技術職業生涯。
本書感謝Carson、陳剛、杜日旭、方圓、付海軍、郭軍、國忠、胡淼、計盛宇、李慶豐、劉世杰、劉偉、劉蕓、呂濤、莫俊彬、秋翾、鄧啟明、蘇傳朋、蘇小勇、四正、王杰、熊煉、俠天、余長洪、永莉、葉青、尹雯玉、魏佳、曾健生、臧秀濤等高可用架構志愿者對內容的大力貢獻（按姓名拼音為序，由于篇幅關系所有志愿者未能全部列出），如果沒有他們出于技術的熱愛對優秀架構思想分享的推動，也不會有本書的內容。在此，對上述所有付出時間的志愿者表示由衷的感謝。
楊衛華 微博研發副總經理,高可用架構技術社區共同發起人
2017.9.26 |
內容簡介：本書由數十位一線架構師的實踐與經驗凝結而成，選材兼顧技術性、前瞻性與專業深度。各技術焦點，均由極具代表性的領域專家或實踐先行者撰文深度剖析，共同組成“高可用”的全局視野與領先高度，內容包括精華案例、分布式原理、電商架構等熱門專題，及云計算、容器、運維、大數據、安全等重點方向。不僅架構師可以從中受益，其他IT、互聯網技術從業者同樣可以得到提升 |
目錄：第1 章 高可用架構案例精選 1
郭斯杰／1.1 Twitter 高性能分布式日志系統架構解析 1
1.1.1 為什么需要分布式日志. 1
1.1.2 Twitter 如何考慮這個問題 4
1.1.3 基于Apache BookKeeper 構建DistributeLog 5
1.1.4 DistributeLog 案例分享13
1.1.5 疑問與解惑.13
顏國平／1.2 騰訊基于用戶畫像大數據的電商防刷架構.16
1.2.1 背景介紹16
1.2.2 黑產現狀介紹16
1.2.3 騰訊內部防刷架構18
1.2.4 騰訊大數據收集維度.20
1.2.5 騰訊大數據處理平臺——魔方21
1.2.6 疑問與解惑.24
王淵命／1.3 如何設計類似微信的多終端數據同步協議：Grouk 實踐分享.26
1.3.1 移動互聯網時代多終端數據同步面臨的挑戰26
1.3.2 多終端數據同步與傳統消息投遞協議的差異27
1.3.3 Grouk 在多終端數據同步協議上的探索實踐.28
1.3.4 疑問與解惑.32
周 洋／1.4 如何實現支持數億用戶的長連消息系統：Golang 高并發案例33
1.4.1 關于push 系統對比與性能指標的討論.33
1.4.2 消息系統架構介紹35
1.4.3 哪些因素決定推送系統的效果37
1.4.4 GO 語言開發問題與解決方案.38
1.4.5 消息系統的運維及測試41
1.4.6 疑問與解惑.42
唐福林／1.5 雪球在股市風暴下的高可用架構改造分享.46
1.5.1 雪球公司的介紹46
1.5.2 雪球當前總體架構47
1.5.3 雪球架構優化歷程48
1.5.4 關于架構優化的總結和感想.53
1.5.5 疑問與解惑.54
麥俊生／1.6 億級短視頻社交美拍架構實戰59
1.6.1 短視頻市場的發展59
1.6.2 美拍的發展.60
1.6.3 短視頻所面臨的架構問題61
1.6.4 為支持億級用戶，美拍架構所做的一些改進62
1.6.5 后續發展68
劉道儒／1.7 微博“異地多活”部署經驗談69
1.7.1 微博異地多活建設歷程69
1.7.2 微博異地多活面臨的挑戰70
1.7.3 異地多活的最佳實踐.73
1.7.4 異地多活的新方向74
孫宇聰／1.8 來自Google 的高可用架構理念與實踐75
1.8.1 決定可用性的兩大因素76
1.8.2 高可用性方案77
1.8.3 可用性7 級圖表80
1.8.4 疑問與解惑.81
那 誰／1.9 深入理解同步／異步與阻塞／非阻塞區別84
1.9.1 同步與異步.84
1.9.2 阻塞與非阻塞85
1.9.3 與多路復用I/O 的聯系86
第2 章 高可用架構原理與分布式實踐.88
黃東旭／2.1 Codis 作者細說分布式Redis 架構設計88
2.1.1 Redis、Redis Cluster 和Codis88
2.1.2 我們更愛一致性90
2.1.3 Codis 在生產環境中的使用經驗和坑91
2.1.4 分布式數據庫和分布式架構.94
2.1.5 疑問與解惑.95
霍泰穩／2.2 給你介紹一個不一樣的硅谷.98
2.2.1 Uber .98
2.2.2 Coursera.99
2.2.3 Airbnb102
2.2.4 硅谷行帶給我的一些影響106
2.2.5 疑問與解惑106
金自翔／2.3 解耦的藝術——大型互聯網業務系統的插件化改造110
2.3.1 插件化.110
2.3.2 如何處理用戶交互115
2.3.3 如何處理數據.115
2.3.4 總結116
沈 劍／2.4 從零開始搭建高可用IM 系統117
2.4.1 什么是IM117
2.4.2 協議設計118
2.4.3 WEB 聊天室.122
2.4.4 IM 典型業務場景126
2.4.5 疑問與解惑126
陳宗志／2.5 360 分布式存儲系統Bada 的架構設計和應用.129
2.5.1 主要應用場景.129
2.5.2 整體架構130
2.5.3 主要模塊131
2.5.4 數據分布策略.132
2.5.5 請求流程133
2.5.6 多機房架構134
2.5.7 FAQ138
2.5.8 疑問與解惑139
張 亮／2.6 新一代分布式任務調度框架：當當Elastic-Job 開源項目
的10 項特性143
2.6.1 為什么需要作業（定時任務）.143
2.6.2 當當之前使用的作業系統144
2.6.3 Elastic-Job 的來歷.144
2.6.4 Elastic-Job 包含的功能145
2.6.5 Elastic-Job 的部署和使用.146
2.6.6 對開源產品的開發理念.147
2.6.7 未來展望148
2.6.8 疑問與解惑149
付海軍／2.7 互聯網DSP 廣告系統架構及關鍵技術解析152
2.7.1 優秀DSP 系統的特點152
2.7.2 程序化購買的特點153
2.7.3 在線廣告的核心問題156
2.7.4 在線廣告的挑戰.156
2.7.5 DSP 系統架構.157
2.7.6 RTB 投放引擎的架構.158
2.7.7 DMP160
2.7.8 廣告系統DMP 數據處理的架構.160
2.7.9 用戶畫像的方法.162
2.7.10 廣告行業的反作弊.165
2.7.11 P2P 流量互刷166
2.7.12 CPS 引流作弊167
2.7.13 疑問與解惑168
王衛華／2.8 億級規模的Elasticsearch 優化實戰170
2.8.1 索引性能（Index Performance） .170
2.8.2 查詢性能（Query Perofrmance） 171
2.8.3 其他173
2.8.4 疑問與解惑174
楊衛華／2.9 微博分布式存儲考試題：案例講解及作業精選179
2.9.1 訪問場景179
2.9.2 設計180
2.9.3 sharding 策略180
2.9.4 案例精選181
李 凱／2.10 架構師需要了解的Paxos 原理、歷程及實戰.184
2.10.1 數據庫高可用性難題184
2.10.2 Paxos 協議簡單回顧.185
2.10.3 Basic Paxos 同步日志的理論模型186
2.10.4 Multi Paxos 的實際應用.187
2.10.5 依賴時鐘誤差的變種Paxos 選主協議簡單分析190
2.10.6 疑問與解惑191
溫 銘／2.11 OpenResty 的現在和未來193
2.11.1 OpenResty 是什么，適合什么場景下使用.193
2.11.2 某安全公司服務端技術選型的標準194
2.11.3 如何在項目中引入新技術.196
2.11.4 如何入門以及學習的正確方法197
2.11.5 OpenResty 中的測試和調試.199
2.11.6 NginScript 是否會替代OpenResty201
2.11.7 未來重點解決的問題和新增特性.202
2.11.8 開源社區建設203
2.11.9 疑問與解惑.203
第3 章 電商架構熱點專題.205
張開濤／3.1 億級商品詳情頁架構演進技術解密.205
3.1.1 商品詳情頁205
3.1.2 商品詳情頁發展史209
3.1.3 遇到的一些問題和解決方案220
3.1.4 總結228
3.1.5 疑問與解惑229
楊 超／3.2 大促系統全流量壓測及穩定性保證——京東交易架構.232
3.2.1 交易系統的三個階段232
3.2.2 交易系統的三層結構233
3.2.3 交易系統的訪問特征234
3.2.4 應對大促的第1 步：全鏈路全流量線上壓測.234
3.2.5 應對大促的第2 步：根據壓力表現進行調優.237
3.2.6 異步和異構240
3.2.7 應對大促的第3 步：分流與限流242
3.2.8 應對大促的第4 步：容災降級.244
3.2.9 應對大促的第5 步：完善監控.245
3.2.10 疑問與解惑246
呂 毅／3.3 秒殺系統架構解密與防刷設計.248
3.3.1 搶購業務介紹.248
3.3.2 具體搶購項目中的設計.249
3.3.3 如何解耦前后端壓力250
3.3.4 如何保證商品庫的庫存可靠252
3.3.5 如何與第三方多方對賬.254
3.3.6 項目總結255
3.3.7 疑問與解惑255
王富平／3.4 Lambda 架構與推薦在電商網站實踐.257
3.4.1 Lambda 架構257
3.4.2 1 號店推薦系統實踐260
3.4.3 Lambda 的未來262
3.4.4 思考263
3.4.5 疑問與解惑263
楊 碩／3.5 某公司線上真實流量壓測工具構建.265
3.5.1 為什么要開發一個通用的壓測工具265
3.5.2 常見的壓測工具.266
3.5.3 構建自己的壓測工具266
3.5.4 疑問與解惑271
第4 章 容器與云計算.273
陳 飛／4.1 微博基于Docker 容器的混合云遷移實戰.273
4.1.1 為什么要采用混合云的架構273
4.1.2 跨云的資源管理與調度.275
4.1.3 容器的編排與服務發現.278
4.1.4 混合云監控體系.284
4.1.5 前進路上遇到的那些坑.286
4.1.6 疑問與解惑286
高 磊／4.2 互聯網金融創業公司Docker 實踐287
4.2.1 背景介紹287
4.2.2 容器選型287
4.2.3 應用遷移288
4.2.4 彈性擴容291
4.2.5 未來規劃295
4.2.6 疑問與解惑295
高永超／4.3 使用開源Calico 構建Docker 多租戶網絡.297
4.3.1 PaaS 平臺的網絡需求.297
4.3.2 使用Calico 實現Docker 的跨服務器通訊.298
4.3.3 利用Profile 實現ACL301
4.3.4 性能測試306
4.3.5 Calico 的發展308
4.3.6 疑問與解惑309
彭哲夫／4.4 解析Docker 在芒果TV 的實踐之路310
4.4.1 豆瓣時期310
4.4.2 芒果TV 的Nebulium Engine .311
4.4.3 Project Eru .312
4.4.4 細節313
4.4.5 網絡314
4.4.6 存儲315
4.4.7 Scale316
4.4.8 資源分配和集群調度316
4.4.9 服務發現和安全.317
4.4.10 實例317
4.4.11 總結318
4.4.12 疑問與解惑318
王關勝／4.5 微博基于Docker 的混合云平臺設計與實踐323
4.5.1 微博的業務場景及混合云背景.323
4.5.2 三大基礎設施助力微博混合云.326
4.5.3 微博混合云DCP 系統設計核心：自動化、彈性調度328
4.5.4 引入阿里云作為第3 機房，實現彈性調度架構330
4.5.5 大規模集群操作自動化.331
4.5.6 不怕峰值事件.332
第5 章 運維保障333
王 康／5.1 360 如何用QConf 搞定兩萬以上服務器的配置管理.333
5.1.1 設計初衷333
5.1.2 整體認識334
5.1.3 架構介紹335
5.1.4 QConf 服務端336
5.1.5 QConf 客戶端336
5.1.6 QConf 管理端340
5.1.7 其他341
5.1.8 疑問與解惑343
尤 勇／5.2 深度剖析開源分布式監控CAT347
5.2.1 背景介紹347
5.2.2 整體設計348
5.2.3 客戶端設計349
5.2.4 服務端設計352
5.2.5 總結感悟357
楊尚剛／5.3 單表60 億記錄等大數據場景的MySQL 優化和運維之道359
5.3.1 前言359
5.3.2 數據庫開發規范.360
5.3.3 數據庫運維規范.363
5.3.4 性能優化368
5.3.5 疑問與解惑375
秦 迪／5.4 微博在大規模、高負載系統問題排查方法379
5.4.1 背景379
5.4.2 排查方法及線索.379
5.4.3 總結384
5.4.4 疑問與解惑385
秦 迪／5.5 系統運維之為什么每個團隊存在大量爛代碼387
5.5.1 寫爛代碼很容易.387
5.5.2 爛代碼終究是爛代碼388
5.5.3 重構不是萬能藥.392
5.5.4 寫好代碼很難.393
5.5.5 悲觀的結語394
秦 迪／5.6 系統運維之評價代碼優劣的方法395
5.6.1 什么是好代碼.395
5.6.2 結語403
5.6.3 參考閱讀403
秦 迪／5.7 系統運維之如何應對爛代碼404
5.7.1 改善可維護性.404
5.7.2 改善性能與健壯性409
5.7.3 改善生存環境.412
5.7.4 個人感想414
第6 章 大數據與數據庫415
王 勁／6.1 某音樂公司的大數據實踐.415
6.1.1 什么是大數據.415
6.1.2 某音樂公司大數據技術架構418
6.1.3 在大數據平臺重構過程中踩過的坑425
6.1.4 后續的持續改進.430
王新春／6.2 實時計算在點評.431
6.2.1 實時計算在點評的使用場景431
6.2.2 實時計算在業界的使用場景432
6.2.3 點評如何構建實時計算平臺433
6.2.4 Storm 基礎知識簡單介紹.434
6.2.5 如何保證業務運行的可靠性436
6.2.6 Storm 使用經驗分享438
6.2.7 關于計算框架的后續想法442
6.2.8 疑問與解惑442
王衛華／6.3 百姓網Elasticsearch 2.x 升級之路.446
6.3.1 Elasticsearch 2.x 變化446
6.3.2 升級之路448
6.3.3 優化或建議451
6.3.4 百姓之道452
6.3.5 后話：Elasticsearch 5.0453
6.3.6 升級2.x 版本成功，5.x 版本還會遠嗎454
董西成 張虔熙／6.4 Hadoop、HBase 年度回顧457
6.4.1 Hadoop 2015 技術發展457
6.4.2 HBase 2015 年技術發展460
6.4.3 疑問與解惑466
常 雷／6.5 解密Apache HAWQ——功能強大的SQL-on-Hadoop 引擎.469
6.5.1 HAWQ 基本介紹469
6.5.2 Apache HAWQ 系統架構.472
6.5.3 HAWQ 中短期規劃.479
6.5.4 貢獻到Apache HAWQ 社區479
6.5.5 疑問與解惑480
蕭少聰／6.6 PostgresSQL HA 高可用架構實戰.482
6.6.1 PostgreSQL 背景介紹.482
6.6.2 在PostgreSQL 下如何實現數據復制技術的HA 高可用集群483
6.6.3 Corosync+Pacemaker MS 模式介紹484
6.6.4 Corosync+Pacemaker M/S 環境配置485
6.6.5 Corosync+Pacemaker HA 基礎配置488
6.6.5 PostgreSQL Sync 模式當前的問題492
6.6.6 疑問與解惑492
王晶昱／6.7 從NoSQL 歷史看未來.495
6.7.1 前言495
6.7.2 1970 年：We have no SQL496
6.7.3 1980 年：Know SQL 497
6.7.4 2000 年：No SQL .502
6.7.5 2005 年：不僅僅是SQL 504
6.7.6 2013 年：No，SQL .505
6.7.7 阿里的技術選擇.505
6.7.8 疑問與解惑506
楊尚剛／6.8 MySQL 5.7 新特性大全和未來展望.508
6.8.1 提高運維效率的特性508
6.8.2 優化器Server 層改進.511
6.8.3 InnoDB 層優化513
6.8.4 未來發展517
6.8.5 運維經驗總結.518
6.8.6 疑問與解惑519
譚 政／6.9 大數據盤點之Spark 篇521
6.9.1 Spark 的特性以及功能521
6.9.2 Spark 在Hulu 的實踐.525
6.9.3 Spark 未來的發展趨勢528
6.9.4 參考文章530
6.9.5 疑問與解惑530
蕭少聰／6.10 從Postgres 95 到PostgreSQL 9.5：新版亮眼特性532
6.10.1 Postgres 95 介紹532
6.10.2 PostgresSQL 版本發展歷史533
6.10.3 PostgresSQL 9.5 的亮眼特性534
6.10.4 PostgresSQL 還可以做什么544
6.10.5 疑問與解惑547
畢洪宇／6.11 MongoDB 2015 回顧：全新里程碑式的WiredTiger 存儲引擎551
6.11.1 存儲引擎的發展551
6.11.2 復制集改進.555
6.11.3 自動分片機制556
6.11.4 其他新特性介紹556
6.11.5 疑問與解惑.558
王曉偉／6.12 基于Xapian 的垂直搜索引擎的構建分析561
6.12.1 垂直搜索的應用場景561
6.12.2 技術選型.563
6.12.3 垂直搜索的引擎架構564
6.12.4 垂直搜索技術和業務細節.566
6.12.5 疑問與解惑568
第7 章 安全與網絡572
郭 偉／7.1 揭秘DDoS 防護——騰訊云大禹系統572
7.1.1 有關DDoS 簡介的問答.574
7.1.2 有關大禹系統簡介的問答575
7.1.3 有關大禹系統硬件防護能力的問答576
7.1.4 有關算法設計的問答577
7.1.5 大禹和其他產品、技術的區別.578
馮 磊 趙星宇／7.2 App 域名劫持之DNS 高可用——開源版
HttpDNS 方案詳解580
7.2.1 HttpDNSLib 庫組成.581
7.2.2 HttpDNS 交互流程582
7.2.3 代碼結構583
7.2.4 開發過程中的一些問題及應對.586
7.2.5 疑問與解惑593
馬 濤／7.3 CDN 對流媒體和應用分發的支持及優化595
7.3.1 CDN 系統工作原理.595
7.3.2 網絡分發過程中ISP 的影響602
7.3.3 防盜鏈.603
7.3.4 內容分發系統的問題和應對思路604
7.3.5 P2P 穿墻打洞607
7.3.6 疑問與解惑609
馬 濤／7.4 HTTPS 環境使用第三方CDN 的證書難題與最佳實踐611
蔣海滔／7.5 互聯網主要安全威脅分析及應對方案613
7.5.1 互聯網Web 應用面臨的主要威脅613
7.5.2 威脅應對方案.616
7.5.3 疑問與解惑624 |
| 序： |
|
