《程式設計師 2014 精華本》緊緊圍繞大數據、電商架構、智慧型硬體、移動開發、團隊管理等熱門話題，進行了全面而深入的解讀。分為專題篇，對話篇，管理篇，產品篇，移動篇，雲計算篇，技術篇七個篇章。
基本介紹
- 書名：程式設計師2014精華本
- 作者：程式設計師編輯部 編
- ISBN：978-7-121-25471-0
- 類別：程式語言
- 頁數：468
- 定價：59
- 出版社：電子工業出版社
- 出版時間：2015-02
- 裝幀：平裝
- 開本：16
基本信息,主要內容,作者簡介,編輯推薦,目錄,專題篇,對話篇,管理篇,產品篇,移動篇,雲計算篇,技術篇,章節選讀,
基本信息
程式設計師2014精華本（《程式設計師》雜誌2014年12期雜誌精華文章匯總，講述成功產品背後的技術、人和事）
程式設計師編輯部 編
ISBN 978-7-121-25471-0
2015年2月出版
定價：59.00元
468頁
16開
主要內容
《程式設計師2014 精華本》緊緊圍繞大數據、電商架構、智慧型硬體、移動開發、團隊管理等熱門話題，進行了全面而深入的解讀。
基於原有欄目和2014年度熱點，《程式設計師2014 精華本》的結構分為以下七個篇章。
專題篇：綜合了2014 年1-12 月封面報導，內容包括雙11 背後的技術、大數據實時處理、程式語言、我們是MAKER、雲計算理想與現實、移動開發工具、打造高效團隊、安全新知、微信開發、移動5 年、電商峰值系統架構設計、2014 TOP50 最具價值CTO 等12 個主題。
對話篇：由程式設計師記者直接採訪大師級人物和知名技術人，在思想、實踐等方面進行深刻碰撞。
管理篇：主要是來自軟體方法、個人成長、一分鐘先生等欄目的真知灼見。
產品篇：主要分享產品設計方面的方法、理念和實踐。
移動篇：匯聚移動開發領域的觀點、工具和技術。
雲計算篇：雲計算和大數據領域的熱門技術和實踐，特別是2014 年大紅大紫的Docker 和Spark。
技術篇：包括語言與工具、技術實踐等方面內容。
作者簡介
《程式設計師》是中國影響力最大的開發者專業期刊，創辦於2000年10月，以產業化、專業化、人文化、個性化的獨特定位來關注程式設計師專業群體，同CSDN網站形成良好的資源互補。其讀者群包括開發者、項目經理、技術總監(CTO&CIO)、IT專業人士、編程愛好者等。《程式設計師》創刊以來，以其高質量的內容受到廣大讀者的好評。第一期至今，每期讀者調查滿意度都超過90%。
編輯推薦
1、《程式設計師2014精華本》緊緊圍繞大數據、電商架構、智慧型硬體、移動開發、團隊管理等熱門話題，進行了全面而深入的解讀。
2、《程式設計師2014精華本》由程式設計師編輯部精心打造，對《程式設計師》雜誌2014年的內容再次進行了最佳化整合，內容更加聚焦，是一份濃縮的饕餮盛宴，值得閱讀。
目錄
專題篇
雙11背後的技術 1
網購狂歡節背後的技術閱兵 1
雙 11 的前端實踐3
天貓瀏覽型套用的 CDN 靜態化架構演變8
個性化技術在雙 11 的套用12
聚石塔：電子商務雲平台 2013 年雙 11 歷程15
支付寶的架構變遷18
中間件技術的雙 11 實踐25
軟負載：分散式系統的引路人25
分散式服務框架：分散式服務的組織者27
訊息中間件：分散式訊息的廣播員27
EagleEye ：分散式調用的跟蹤者30
數據層：分散式數據存儲的橋樑32
套用伺服器：系統運行的託管員34
穩定性平台：系統穩定運行的保障者36
雙 11 資料庫技術38
大規模離線計算集群故障管理實踐40
千萬 QPS 能力的高性能 DNS 防護系統41
阿里的 SDN 實踐42
阿里整機架伺服器解決方案44
大數據實時處理46
實時和互動：技術與現實的糾纏46
大數據時代之實時數據傳輸47
HBase 在內容推薦引擎系統中的套用50
實時處理之流式計算平台的實踐53
Storm 在騰訊的套用55
京東基於 Samza 的流式計算實踐58
Spark Streaming：大規模流式數據處理的新貴61
Presto實現解析63
基於Impala構建實時大數據查詢系統實踐66
百度實時計算系統69
百分點實時計算實踐：架構和算法72
程式語言76
新系統語言Rust—Rust 項目技術負責人 Brian Anderson 專訪76
Rust語言：安全地並發77
讓高性能科學計算為人人所用—科學計算語言 Julia 發明團隊專訪78
Julia語言初探81
全棧語言的力量—Red 語言設計者 Nenad Rakocevic 專訪84
Red語言：向編程複雜性反擊85
Go語言技巧88
Node.js背後的V8引擎最佳化技術91
向小眾學習95
淺談Common Lisp的宏編程97
中間語言和虛擬機漫談100
未來工具與未來語言—JetBrains CEO 專訪103
我們是MAKER105
理解創客105
我們正經歷一場真正的革命—3D Robotics CEO、美國《連線》雜誌前總編 Chris Anderson 專訪107
想改變世界，先改變自己—知名 Hacker、發明家 Mitch Altman 專訪 109
創客天下《Make》及 Maker Faire 創辦人、—O'Reilly Media 創始人 Dale Dougherty 專訪 110
別懷疑，每個人都是創客—美國 16 歲創客 Joey Hudy 專訪111
開發板，開源和創客113
充滿樂趣的創客之路115
高中生創客的自我養成117
機器人領域創業那五年—RoboPeak 創始人陳士凱專訪119
雲計算，理想與現實123
我所經歷的“餘額寶”的那些故事123
電信行業雲計算實施經驗談—浙江電信業務雲資源池核心技術解析127
廣電行業雲基礎平台構建實踐—細解北京網路廣播電視台雲基礎支撐平台項目 129
港華燃氣核心業務雲端之路132
軌道交通行業的企業雲計算—廣州捷運的企業雲平台構建135
移動開發工具139
次時代互動原型神器Origami檔案139
Facebook POP，邁向大師操作之路143
New Relic漫談—Mobile APM 給我們帶來什麼？145
那些好用的 iOS 開發工具149
這些年用的iOS UI自動化測試工具152
打造高效團隊155
打造高效開發團隊155
精益化的團隊高效協作157
小站會，大智慧158
自組織團隊建設的“催化劑”從組織到團隊163
知識管理應該圍繞學習展開165
高效能技術團隊的協同工具箱167
安全新知171
普通開發者的網路安全必讀171
挑戰與機遇：新型網路中的安全困局172
構建更加安全的智慧型移動平台174
移動支付安全的挑戰與對策175
Android安全研究經驗談176
解密Android簡訊木馬為何屢殺不盡179
微信開發182
微信生態的滲透與價值182
以招行為例，微信公眾賬號開發高級篇184
妝媒體微信公眾號背後的酸甜苦辣186
微氣象，大民生188
高性能微信公眾平台開發189
微信支付開發關鍵點技術解析191
如何使用微信設計二次認證194
移動5年197
大話移動5年—移動網際網路發展歷程與回顧197
從SDK回顧iOS系統發展199
移動5年，Android生態系統的演進202
移動安全這五年204
HTML5回首，在你的時代到來前208
盤點移動網際網路入口爭戰211
2010-2014：App Store中那些遺失的遊戲現象214
移動網際網路：五年洗禮，造就產業新變局—《唱吧》CEO 陳華專訪217
扁平化和參與感—小米聯合創始人、副總裁黎萬強專訪219
從TalkBox看IM即時通信工具的演變—TalkBox 團隊被微信顛覆後的創業思考220
移動五年，創業者眼中的變遷222
電商峰值系統架構設計224
快穩炫：電商峰值系統架構三字訣224
傳統企業電商峰值系統應對實踐225
噹噹網系統分級與海量信息動態發布實踐227
京東峰值系統設計230
“米粉節”背後的故事—小米網搶購系統開發實踐232
海爾電商峰值系統架構設計最佳實踐235
唯品會峰值系統架構演變238
1號店電商峰值與流式計算241
如何在雙11中創造99.99%的可用性—蘑菇街在大型促銷活動中的穩定性實踐242
履單流程的彈性架構—麥包包峰值架構實踐245
2014 TOP50最具價值CTO248
從呼叫中心到移動網際網路的演進—攜程高級技術副總裁葉亞明專訪248
要學會面對黎明前的黑暗樂視網 CTO 楊永強專訪250
能做存儲的超級計算機—XtremIO CTO 任宇翔和以色列團隊的創業故事251
技術女神的自我奮鬥—MediaV CTO 胡寧專訪253
做個不一樣的“分享”平台—途家網聯合創始人兼 CTO Melissa Yang（楊孟彤）專訪254
以軟體革新硬體體驗—極路由 CTO 康曉寧專訪256
開發+技術驅動—途牛旅遊網 CTO 湯崢嶸專訪258
一位 DBA 老兵心中的國產資料庫之夢—南大通用高級副總裁兼 CTO 武新專訪261
建立技術體系，保障公司業務—趕集網 CTO 羅劍專訪263
對話篇
C++ 之父 Bjarne Stroustrup訪談錄265
C++與編程人生—《C++ Primer》作者 Stanley B.Lippman 專訪 270
我的目標永遠是讓人開懷—Perl之父 Larry Wall訪談錄273
與時鐘的對抗—訪圖靈獎得主Ivan Sutherland276
2013年圖靈獎得主Leslie Lamport278
反饋即一切—實時計算系統 Storm 創始人Nathan Marz 訪談錄279
Andrew Ng談Deep Learning282
永遠追求下一個Big Thing—LSI 院士兼首席架構師 Robert Ober 專訪283
管理篇
軟體方法286
探索式測試解密—無探索，不測試！286
探索過程改進最佳實踐288
Competence：技術粗放型向管理精細型的轉變 291
刀鋒管理體系—創業公司流程改進紀實294
個人成長297
給技術人上的管理課：控制和計畫297
給技術人上的管理課：平衡和集中299
給技術人上的管理課：激勵與授權301
軟體測試人員的基本修養303
向上管理：管理自己的老闆304
創業團隊的招聘與留人306
做一個“高大上”的架構師—蔡氏架構設計方法論之初體驗308
一分鐘先生312
小技術團隊管理工具大比拼312
技術人員如何參與產品設計討論？316
技術團隊如何留住人才321
技術走向管理要實現哪些轉變325
產品篇
火鍋與煎餅331
引導的設計331
躺槍的網際網路思維332
不靠譜的“用戶體驗”332
用戶的鞋子333
對不起333
產品文化334
設計流程335
辯無勝335
高級山寨336
為了體驗336
低能的“智慧型”337
聊聊阿里的內部創新機制—賽馬338
70後大叔的90後產品煉成之路—田行智談《碰碰》和他的創業故事339
網際網路思維與硬體創新—印美圖在軟硬整合產品中的實踐341
ANTVT KIT，不做中國的 Oculus343
移動篇
遊戲346
從頂級遊戲開發者倒下看產品型行業的危機感346
刷任務：在無聊與微獎勵中搖擺348
不良遊戲體驗對玩家的負面限制351
以開發者角度看其遊戲體驗心態353
手遊中Boss異能和巨型形態的設定355
免費體驗增值模式改變遊戲的五種形態357
消費引導與遊戲內容供給不足的悖論360
從恐怖與驚悚元素談玩家的情感代入362
開發365
iOS 套用安全開發你不知道的那些事365
解析Swift函式式編程367
Material Design ：過去、現在和未來371
Gradle：更智慧型的Android構建系統373
邁步進入跨平台開發時代375
雲計算篇
Docker377
Docker 的生態系統和未來377
基於Docker的Auto Scaling實踐380
基於Docker的通用計算平台實踐384
網易Docker部署運維實踐387
Spark392
Spark 與 MLlib：當機器學習遇見分散式系統392
Spark MLlib：矩陣參數的模式394
使用Spark+MLlib構建用戶標籤系統397
快刀初試：Spark GraphX在淘寶的實踐400
大數據405
Kafka 在唯品會的套用實踐405
大眾點評的數據架構之道407
騰訊CKV海量分散式存儲系統—日訪問過萬億次背後的技術挑戰409
騰訊CKV海量分散式存儲運營實踐411
百度實時計算套用實踐414
基於Storm的美團實時計算套用實踐417
服務化Cache系統—小米網 Redis 實踐421
蝦米在個性化音樂推薦領域的實踐424
大規模微博用戶興趣圖譜挖掘427
Summingbird Twitter實時訊息處理基礎平台429
技術篇
語言與工具434
逆世界：讓 C++走進 Python434
你應該更新的 Java 知識437
PostScript語言裡的珠璣439
node-webkit：HTML5桌面套用運行環境441
Ruby並發框架縱橫談443
JVM 中的全異步框架 Vert.x446
技術實踐449
機器人與關鍵技術解析449
圖書評論排序對於用戶購買的影響452
門戶級 UGC 系統的技術進化路線—新浪新聞評論系統的架構演進和經驗總結455
章節選讀
網購狂歡節背後的技術閱兵
文 / 莊卓然
從光棍節到網購狂歡節
2013 年是雙 11 的第五個年頭，從 2009 年的“光棍節”到現在的“網購狂歡節”，單單是名字上的變化，大家就能從中感受到業務規模發生的轉變。
2013 年雙 11，天貓和淘寶單日成交額達到 350.19 億元，網站 PV 過百億，成就了 14 個銷售過億的商家。
其中，有 76% 的商家處理工作是在聚石塔雲計算平台上完成的，並且無一漏單、無一故障。
支付寶實現成功支付 1.88 億筆交易，再次刷新了 2012 年同期 1.0580 億筆交易的全球紀錄，最高每分鐘支付 79 萬筆交易。
手機淘寶整體支付寶成交額為 53.5 億元是 2012 年的 5.6倍（9.6 億元）；單日活躍用戶達 1.27 億；手機淘寶單日交易成交筆數達 3590 萬筆，交易筆數占整體的 21%。
天貓雙 11 共產生快遞包裹 1.52 億件，僅雙 11 當天，國各大快遞企業共處理 6000 多萬件包裹，是 2012 年雙 11 最高峰的 1.7 倍。
在瘋狂的業務數據背後，是阿里技術團隊的一次整體大閱兵，從天貓、淘寶到支付寶，從 PC 到無線，從研發到運維保障，各個環節都面臨著巨大的挑戰。
雙 11 業務
生態在開始介紹這些挑戰之前，我們先用一張圖來看一看，作為消費者，你在 2013 年的雙 11 大促中都會經歷哪些業務過程，如圖 1 所示。
首先，你會通過各種終端（PC、手機、平板）訪問淘寶、天貓、聚划算的導購市場，豐富多樣的導購產品會幫助你發現和挑選自己心儀的商品。大數據的基礎平台支撐了大量有價值的數據套用，以保證你在這個環節的購物體驗。穩定的交易平台確保了優惠價格的準確計算、庫存的及時扣減和擔保交易的訂單有效生成。這時，你就可以通過支付寶安全放心地進行支付寶餘額或者網上銀行支付，滿心歡喜地等待包裹的送達。
這時就開始輪到面向商家的系統忙碌起來了。聚石塔提供的雲推送功能在第一時間將交易訂單同步到部署在聚石塔雲工作平台上的商家 ERP、WMS、CRM 軟體中，並且為這部分軟體提供了動態彈性擴容的能力和安全方面的有效保護，以便大商家在大量訂單面前，可以像日常情況一樣，快速組織商品出庫和發貨，而不用額外擔心自己軟體的處理能力。
最後出場的是菜鳥網路打造的雷達預警系統，通過大數據的力量，對商家的備貨、消費者購買行為、物流服務能力進行預測，並與國家氣象局、交通部實時發布的天氣、道路情況進行同步運算，將未來半天至七天的預測結果反饋到 13 家快遞公司，以便快遞公司提前調配運力。最終，所有的包裹得以第一時間送到消費者的手中。
挑戰和技術準備
業務跨數量級的快速發展對整體架構帶來了新挑戰經歷了過去幾年“去 IOE”（IBM 小型機、Oracle、EMC 高端存儲）整體架構改造，整個阿里集團建立了基於中間件、PCServer的輕量級分散式SOA架構，保證了伺服器、資料庫、網路、
機房各個層面無單點，可以以較小的成本支持水平擴展，提升網站的負載能力。但隨著這幾年雙 11 業務的飛速增長，PV、同時線上用戶數、峰值交易和峰值支付等核心指標都開始跨越到新的數量級，架構在更高負載能力要求下的一些缺陷開始暴露出來。
第一，大規模訪問請求帶來的機房網路瓶頸。
雙 11 當天有數億用戶訪問天貓和淘寶的系統，高峰期甚至有數千萬人同時線上。以天貓的“商品詳情”頁面為例，集群峰值 QPS 達到了十萬以上的量級，是平時峰值 QPS 的數十倍。這樣的突發性流量增長，使得機房的網路容量面臨著巨大壓力。如何能夠利用合理的成本應對瞬間飆高所帶來的網路壓力，確保活動完整周期內用戶回響時間的穩定性，以及局部出現問題時的高可用性，成了首先需要面對的問題。著眼於未來，從 2011 年起，我們就開始了對瀏覽型的套用
進行新的架構改造。歷經頁面細粒度的動靜分離、統一快取接入、CDN 靜態化三個階段。最終，將更新頻率不高的內容偽靜態化直接快取到 CDN，通過統一的秒級失效機制控制快取的更新操作，讓絕大多數內容請求不需要回流到主機房，直接在用戶最近的 CDN 節點就能夠完成。這種方式一方面極大地緩解了主機
房網路的壓力，另一方面也最佳化了用戶頁面的回響時間。徐昭的《天貓瀏覽型套用的 CDN 靜態化架構演變》將帶大家更深入地了解我們是如何經歷這一過程的。
第二，超大規模系統如何繼續保持在不同層面上的水平伸縮性。
首先，伺服器需求的增多，導致未來單一地區的 IDC 資源已無法滿足容量增長的需求，機房供電能力成為短期內無法逾越的瓶頸。其次，簡單地橫向擴展 IDC 機房，機房之間的網路流量又成為了新的瓶頸。多機房的套用、快取、資料庫等訪問的相互穿透，也加劇著跨機房的流量增長。最後，核心服務集群的套用伺服器的規模增長，使對應的資料庫連線數成為了瓶頸。每增加一台資料庫伺服器，對應的套用伺服器都需要連線上來，資料庫的連線數馬上就不夠分配了。也就是說，在今天的業務規模下，我們無法繼續針對核心服務的資料庫層再做橫
向的水平擴展了。為了解決以上問題，2013 年雙 11 我們嘗試了新的邏輯機房
的架構方案，將數據水平拆分（Sharding）的思路向上提到接入層。以支付寶為例，先將完成某一特定業務需要的系統、核心服務、資料庫組合抽象成一個業務單元（Zone）的概念，業務單元從套用伺服器、快取到資料庫可以獨立封閉運行。然後，從入口處根據用戶請求路由到不同的邏輯業務單元，實現了單元級別
的可伸縮性。不再依賴同城 IDC，讓交易、支付這樣複雜的業務單元具備了大規模跨地域部署的能力。胡喜的《支付寶的架構變遷》會有更加深入和全面的介紹。
第三，如何更大程度地“壓榨”單伺服器的系統資源。
虛擬化技術已作為各大網站提升物理機資源利用率的基礎技術。以天貓和淘寶網為例，2010 年我們引入 Xen 虛擬化技術，1 台物理機裝 3 個虛擬機，一定程度上降低了成本。但隨著機器規模的快速增長，我們發現其中 1/3 的虛擬機的 Peak load<0.5，這意味著我們的運維成本還是不夠低。主要有以下幾方面原因：
■單台物理機上跑的套用不夠多；
■分給套用的機型及機器數是靜態的；
■集群的資源利用率不均衡。
為了最大化物理機的資源性能，從 2012 年開始，我們大規模地套用了新的基於 LXC 的虛擬化方案，成功地在每台物理機（16Core/48GB）運行了 12 個套用實例，物理機的 load 提升到2~10。這對大促時期的成本控制非常有幫助，也為內部私有雲的完整構建，摸索了一條可行的路徑。
消費者對用戶體驗有了更高的要求千人千面的購物體驗
有一個很現實的問題擺在了我們面前：大促當天有幾億消費者會來到我們的網站，在上百萬商家和過億商品裡面挑選自己心儀的寶貝。光靠運營人肉製作的活動頁面和消費者的主動搜尋已遠遠不可能滿足需求。因此，需要在產品上轉變思路，營造從以業務為中心到以用戶為中心的大促體驗。雙 11 應該是面向消費者的“我的雙 11”，而不是“天貓的雙 11”。基於此，2013 年的雙 11 大促中大面積套用了個性化算法，從 PC 到無線，從“會場”到“詳情”，真正意義上為消費者打造了一個“我的雙 11”。從最終效果來看，2013 年雙 11 的用戶購買轉化率提高了 10 個百分點。張奇會在《個性化技術在雙11 的套用》中介紹在個性化推薦系統架構、機器學習算法套用和算法的快速評測方面的思考。
多終端的業務一致性
移動智慧型終端的快速崛起，讓更多的消費者可以隨時隨地訪問天貓和淘寶，但也讓我們開始深入地思考，在業務快速發展的前提下，如何在不同終端上快速提供本質相同的服務。2013 年我們首次在預熱期的大型活動中嘗試了基於 Canvas 的Web App 解決方案，極大程度地提升了開發效率。天貓前端團隊的鄢學鵾會在《雙 11 的前端實踐》一文中分享 Mobile First的理念是如何在雙 11 中實踐的。
穩定性的極致要求
容量預估、依賴治理、監控
這一環節是歷年雙 11 技術成功與否的關鍵環節。中間件團隊的《中間件技術的雙 11 實踐》除了會介紹在 SOA 架構體系中扮演重要角色的中間件產品之外，也會就容量預估、依賴治理和監控的雙 11 實踐做精彩介紹。
業務降級、限流預案
從 2010 年雙 11 開始，每年都會有針對性地準備一些技術預案，在流量超出預期時做好限流保護，在局部系統處理能力出現瓶頸時進行優雅降級，以提升整體的吞吐率，保證核心業務的正常運行。
2013 年，我們在技術環節準備了 2000 多套應急預案，大到遭受駭客攻擊、各類業務應急動作，小到伺服器機房空調發生故障，均有詳細預案。不僅各伺服器機房，甚至西溪園區雙 11大促指揮辦公現場都準備了柴油發電機。此外，2013 年針對雙11 進行了上百次的內部演習，其中全網大規模演習就進行了 10餘次，以確保每一個預案的有效性。
全鏈路壓測
壓力測試對於評估網站性能的重要性是不言而喻的，但無論是線下模擬的單一集群壓測，還是線上引流壓測，都只能暴露一些基本的單點問題。對於雙11當天高峰期的真實壓力模擬，這兩種傳統的壓力測試方式還存在著巨大偏差。
首先是業務處理鏈路的複雜性，對於像天貓這樣一個分散式處理平台，一筆交易的創建會涉及多個套用集群的處理，在能力評估時也應該考慮的是一個處理鏈路而不僅僅是單一套用集群的處理能力。其次是套用之外的風險點，像網路、資料庫等，很難在傳統壓測中體現出來。
為了精確評估核心交易集群中各個環節的能力瓶頸，2013年我們實現了一套新的全鏈路壓測評估體系。通過線上真實用戶數據與人為測試數據相結合的方式，首次成功地在生產環境中模擬出相對真實的超大規模訪問流量，將前端系統、網路、資料庫等一整套系統環境完整地納入壓測範圍，貼近實際的套用場景，為評估淘寶和天貓交易核心鏈路的實際承載能力提供有說服力的數據依據。這一方面可以驗證交易核心鏈路上各種限流和預案的準確性，另一方面也可以充分暴露全鏈路上的各種瓶頸和隱藏的風險點，讓壓力測試的工作真正落實到了確定性的層面上。
基礎運維能力提升的預研
在支撐好現有業務的同時，如何將基礎運維能力（高穩定性、彈性調度、低能耗、快速交付等）提升到新的量級，成了阿里技術團隊未來面臨的新挑戰。為了迎接這方面的挑戰，2013 年雙11 我們也小範圍做了一些面向未來的基礎運維預研工作。
首先，可以預見的是，隨著業務的不斷發展，阿里會有越來越多 IDC 布點。雖然邏輯機房的方案已能解決交易支付環節場景下的跨機房調用問題，但隨著雲計算的推廣，我們依然面臨著大量跨機房調用的場景。現階段，交換機的網路路由主要是基於 IP 做簡單識別，並不會通過識別套用類型提供智慧型調度。當大規模出現多個 IDC 時，跨機房的用戶體驗問題會越來越成為瓶頸。為了解決這一問題，我們 2013 年在交換機的 OS 層面做了大量自主研發工作，定製自主的交換機 OS，實現軟體定義網路（SDN），對管控和成本兩個層面都有較大的改進。龐俊英的《阿里的 SDN 實踐》將簡單介紹我們如何讓套用流量通過SDN識別出來，從而實現不同流量的長途鏈路和短途鏈路調度。
其次，在未來的 3~5 年，阿里的伺服器將擴大到幾十萬甚至百萬級的規模，如果延續以前按伺服器進行交付的模式，交付速度和能耗都會很快出現瓶頸。因此，我們 2013 年嘗試了整機架伺服器解決方案，通過標準化、流程化、定製化，解耦各個交付環節在 IDC 現場部署的時間串列關係，提升交付的質量和效率。除此之外，其中例如統一機架Backbone模組這樣的設計，將整體的耗電量降低了接近10%。放在百萬級伺服器的規模下，無疑會節省一筆極大的開銷。武鵬的《阿里整機架伺服器解決方案》會展示我們在低能耗、快速交付上的思考和方案。
經驗小結
對於技術人員而言，雙 11 絕對是一次奇幻體驗，在這裡有豐富的場景可以實現個人技術上的奇思妙想，同時也經歷著最極致的技術考驗。經歷了 5 年雙 11，我來小結一下技術準備上的一些經驗心得。
提前明確架構目標。
架構和基礎技術的調整往往帶來套用系統的傷筋動骨，前面介紹的一些大架構改造，周期往往需要2~3 年，試錯成本非常高。因此對於架構師和技術核心決策者而言，要有足夠的前瞻性，在選型設計上一定從全局發展和核心問題出發，準確定位、明確目標，才能統一團隊的整體方向。
不過度追求過程中的完美。
我們在內部總把系統架構的過程類比為建造水壩——上下游級聯，同時兼顧對於全局生態的影響。但落實到實施層面才是挑戰的開始，大家總是會傾向於考慮是否優雅完美，從而讓方案的複雜度不斷提升。架構師需能夠兼顧成本、資源、時間等各方面的因素，敢於做取捨，勇於捨棄一些收效甚微的最佳化。到準備後期更是如此，發生問題不可怕，可怕的是解決問題的時候又引入新問題。沒有 100%完美的方案，能滿足業務現階段發展需要的方案就是好方案。
細節決定成敗。
分散式系統的好處在於松耦合、靈活性和可快速擴展，但同時也帶來了一系列麻煩，包括數據的一致性、分散式事務、各種套用在服務層的數據相互干擾等。在大促這樣的峰值壓力下，這些小問題都會被無限放大。因此，前期準備過程中要謹記不能放過任何微小的細節，僥倖心理更是萬萬要不得，擔心出問題的角落往往一定會出問題，最沒問題的地方或許會是風險最大的地方。另外，儘可能工具化一切人為操作環節，在架構上做好約束，同時時刻確保留有“Plan B”，只
有這樣才能夠確保對最終結果有把握。
最後，350 億絕對不是終點，數字本身並無特殊意義，也不會是我們的終極需求，阿里“讓天下沒有難做的生意”的使命還在繼續。用技術的力量重構整個電商生態，改善更多人的生活，還有很多路要走，讓我們一起共同期待更多的技術奇蹟。
