王賢（花名賢哥），淘寶技術部技術專家，在分散式系統架構設計、高併發系統設計、系統穩定性保障等領域積累了較為豐富的實踐經驗，對新技術有濃厚的興趣。

請先和大家介紹下你和目前所從事的工作，以及關注哪些技術領域？

賢哥：目前在負責某直播平臺，包括整體的技術架構以及業務推廣，平臺旨在提供直播的一站式解決方案，涵蓋了大型音視訊直播、超大直播間中的聊天、彈幕、PPT教學、主播打賞等業務功能模組。大型直播是一個非常有挑戰的業務場景，不僅僅需要解決音視訊的編解碼、切片、分發、穩定性及播放質量監控的所帶來的一系列問題，還需要解決超高併發場景下訊息傳送、信令、心跳等問題，以及對於各種UGC內容的過濾（影象、文字）、多端的相容、數字版權保護等等。

由於之前工作的原因，瞭解和接觸到的東西比較雜，在做雲手機商城時，由於是異構的系統，需要跨平臺部署，去研究過異構SOA架構下的應用通訊、路由、部署、升級、遷移，到了淘寶之後，發現淘寶對於各種場景都有相對應的中介軟體，花了很多的精力去熟悉分散式場景下各種中介軟體的工作原理及使用場景，以便提高系統架構的可靠性降及低工作量，在店鋪那邊呆了幾個月，瞭解到一個複雜建站系統是如何工作的，頁面如何模組化，如何渲染，如何通過靜態化提升效能，後面又做支付寶卡寶，由於那時候資料分析平臺還沒有現在這麼成熟，為了看到系統的執行狀態及業務資料，去研究了資料線上及離線分析，由於那時候頁面是放在支付寶客戶端首屏，對系統可靠性要求很高，又去看系統穩定性保障的各種原理、技術、工具，很多時候都是需求驅動自己去學習新知識，這樣學了之後也能夠馬上用上，遇到一項新技術後，會先去了解一下它是做什麼的，適合什麼場景，等有具體的業務場景之後，再去深入學習。目前關注的主要有這麼幾個領域，包括音視訊領域的技術發展及技術架構(如數字版權保護、編解碼及視訊協議、點對點通訊)，高效能的WEB端雙工通訊（通訊協議效能），音視訊應用的可靠性監控。

能夠談下你是走上技術這條路的？

賢哥：大學學的計算機專業，後又因各種機緣巧合到了淘寶，個人本身對於技術非常有興趣，享受通過實踐所帶來的成就感、滿足感，因此實際上是很自然而然的就選擇了這一行，作為碼農的樂趣在於，可以通過一行行程式碼，表達自己對於這個世界的理解。當然，最主要的原因還是個人興趣，喜歡各種折騰。

畢業至今你都是一直在阿里，是因為技術文化還是其它的原因讓你有這樣的堅守？以及談談畢業這些年來在工作中的收穫和體驗。

賢哥：阿里面臨著整個中國電商行業甚至是全球電商行業的最大的挑戰，無論是從業務規模，還是使用者規模來看，都與其他競爭對手拉開了數量級的差距，這背後實際上是成千上萬的碼農在默默支援，它能夠提供其他地方無法提供的場景和挑戰，這或許是堅持下來的最大原因吧。能夠加入阿里工作的同事，必然是在某個領域有一技之長的，因此，跟每一個同事的合作過程，實際上也是學習的過程，成天與這些行業專家們打成一片，自己看待問題的眼光也會越來越全面，越來越成熟，收穫並不僅僅是從技術上，還有思考問題的方式，人生觀世界觀都有很大的變化和成長，大公司能夠聚集人才，並提供很多學習的機會和交流的氛圍，也鼓勵分享經驗和個人積累，長此以往的這種氛圍的薰陶，也讓人受益匪淺。

在阿里做過的專案非常多，給你印象最深或收穫最大的是？為什麼？

賢哥：實際上也經歷過很多階段，不同的階段，不同的角色，可能體會不盡相同，感悟也不大一樣，從一開始的看的多、做的多，到後來的想的多、設計的多，每個階段關注的點不同，從具體技術細節難點的攻關，到整體方案的把控、風險控制，不同的階段，感受可能也會有所不同。印象比較深的可能有這麼幾件事吧，記得有幾次，夜裡一兩點鐘的樣子收到報警簡訊，系統掛了，然後吭哧吭哧爬起來找問題，各種翻日誌翻程式碼，找到問題之後需要和對應的PE同學一起解決，打電話過去人家早就睡了，也是吭哧吭哧爬起來直到把問題修復，沒有任何怨言，阿里的同學就是這樣，線上有問題第一時間解決，職業素養絕對是值得敬佩。

我實際上是比較懶的一個人，能自動的絕不人肉，有一次一個問答功能剛上線，淘寶的賣家也是挺聰明的，各種小廣告又是賣衣服又是賣手機的好不熱鬧，最後的結果就是整個頁面完全沒法看了，苦逼的運營MM一條一條手工的刪，刪的再快也趕不上發的多，然而我又是那種喜歡多管閒事的人，想到用貝葉斯演算法可以解決這個問題，然後就業餘+週末花了有一兩週的時間開發了一套反垃圾系統，把這事拿出來說並非是這個演算法有多牛逼多厲害，貝葉斯演算法反垃圾並不是什麼新鮮事，而是因為這個事情完全是腦袋一熱去做的，但是又收到了出人意料的效果，實際上這樣的事情也幹了不少，只是這件比較有代表性。

另外一個印象比較深刻的專案是去年的雙十一直播，之前由於工作的變化，剛到新團隊沒幾天，接到一個任務，要設計一套直播系統，能支援XXX萬人同時線上，XXX個主播同時推流，又是遊戲的雙十一雙十二核心玩法，可是以往的雙十一從來沒有做過類似的直播，沒有經驗可借鑑，而此時離雙十一也就一兩個月的時間，那好吧，開始做，方案設計、資源協調、容量評估、壓力測試，中間涉及到N個團隊的合作、協調、擴容，技術上又遇到各種坑，連續加了一兩個月的班，大家都非常疲倦，可以說是遇到的挑戰最多的一個專案，所有的東西都得從零開始，上線的時間節點又無法往後推，謝天謝地最終我們解決了所有的問題，在雙十一雙十二期間總體表現的比較平穩，雖然並不完美。當然，這一切並不是靠天吃飯，跟前期的方案和小夥伴們的努力密不可分，實際上這裡面收穫也是蠻多的。

當然，不論是處於什麼角色，做好手頭的工作是本分，但是也不要被自己當前的角色所侷限，多去了解一下週圍的人在幹什麼，瞭解系統的設計思路，多問幾個為什麼，為何要這樣設計，這樣設計有什麼好處，有沒有其他更優的方案，主動學習，你能得到更多。

網際網路發展日新月異，技術也在不斷的更迭，在新技術來臨時，作為技術人員的你，有什麼學習方法或技能可分享？

賢哥：技術總是從無到有，從有到優，顛覆整個行業的技術，在誕生初期也是襁褓中的嬰兒，需要不斷完善。因此，對於技術的學習首先要把握脈絡，在理清思路之後，從原始碼學習也很重要，要知道，原始碼面前，了無祕密，不但要知其然，還要知其所以然，這樣就容易觸類旁通，技術的發展往往是演進式的，從最初概念的提出，到原型產生，再到工業化，最後獲得業界的廣泛認可被大規模使用，這中間有一個演變的歷程，所以，只要明白技術的運作機制，也就是所謂的原理、價值、使用場景，就很容易一個feature一個feature的學習。當然，很多東西都是從大洋彼岸來的，從技術投入應用，到相關的文章書籍出來，會有一定的滯後期，然而，等國內翻譯的書籍出來，又是一個漫長的時間，所以，得習慣看英文文件。

當然，最重要的還是要理解技術的核心本質，包括原理、解決什麼樣的問題、什麼樣的場景適合使用，另外，還得看相關的技術的社群活躍度，有沒有可能在未來成為主流，這是非常重要的，通常來說，解決同一領域的問題，可能有很多方案，那麼選擇那個方案，可能將在很長一段時間裡，影響著你和你的團隊，如果選擇了一種不成熟的技術，或者是社群不是那麼活躍的技術，那麼，你就得花更多的時間來解決生產環境中所遇到的問題。當理解了之後，再去學習，實際上就變得容易了，並且，一項技術在出來之後，會不斷的有改進，有新特性，但是都是在原來的基礎上增磚添瓦，當你理解這些技術的本質之後，再去理解這些改進，這些新特性，會變得相對來說更容易一些。

另外就是不要一味的求新，流行的並不一定就是好的，適合你的才是最好的，A來了學A，B來了學B，C來了又覺得C好，學習是有成本的，把時間用在對的地方，多一份堅持。新的技術的引入，還需要考慮到周邊的生態環境，社群是否成熟，否則光是開發各種中介軟體、各種工具，都夠你喝一壺，熱潮褪去，一地雞毛。

在程式設計/開發之餘，還有哪些興趣愛好？目前你一天的生活節奏是怎樣的？

賢哥：每天除了工作中的系統設計、程式設計開發、各種會議之外，業餘時間可以說非常有限了。這些有限的時間一般會被這樣劃分，各種寫作、PPT會花去一部分時間，因為需要將工作中各種經驗，踩過的坑記錄下來，這也是人生的一筆寶貴財富，隨著時間的流逝，很難想起來3年前做過什麼專案，寫過什麼程式碼，獲得過什麼經驗，因此，日常的總結和反思很重要。

然後就是運動，會給自己留出一點時間進行運動，畢竟身體是革命的本錢，身體是自己的，一旦健康出了問題，任何的成功都沒有意義。另外就是看書學習，技術發展的步伐是很快的，如果不能持續學習，可能就會落後，而這些落後的觀念最後將直接反映在你所設計的系統上，另外就是通過看書學習讓自己的知識變得更全面，視野更加開闊，這樣反過來也會使你解決問題的思路更廣，變得更有創造力，看書是一種非常好的學習方式，因為平時快餐式的學習會容易陷入細節而無法瞭解全面，知識無法成體系，因此，也可借看書的時間來好好梳理自己的知識。由於比較喜歡音樂，也會花一部分時間去搜尋各種流行歌曲、輕音樂、鋼琴、小提琴曲目等等，音樂能使人的大腦處於放鬆狀態，再就是陪伴自己的家人，旅行等等。

掌握知識、技術的三個層次

此前，你出版了《大型分散式網站架構設計與實踐》一書，能否分享下你寫書的原因、過程、困難和感悟等？以及介紹下這本書的特色。

賢哥：其實是比較機緣巧合的一件事情，記得是2013年4月份，博文視點的董英女士找到我，問我是否有興趣寫本關於分散式系統方面的書，其實當時已經預感到這個事情做起來會比較難，但是還是義無反顧接下了這個活。主要是覺得，寫書是個高尚的事情，也算是為網際網路技術的發展盡了一絲綿薄之力了，從另一個角度來說，也是難得的一次機會，對之前的知識一個全面的回顧，一些知識點及細節，有些也是知其然不知其所以然，或者是沒有親身驗證，剛好藉此機會深入瞭解和挖掘。

對於知識或者是技術的掌握，個人認為有三個層次，在專案中能做出來是一個層次，將經驗寫出來惠及大家則是一個昇華，當然，能夠在各種場合隨時隨地的清晰表達出來，又是另一個層次。

實際上，真正寫作的過程遠比想象的要困難，在網際網路企業工作本身就是一件比較累比較辛苦的事情，有時候加班到晚上9-10點鐘回家，還要抽出一兩個小時的時間來寫作，週末基本上就一心撲在上面了，時間是一方面，最痛苦的莫過於在這過程中需要不停的上下文切換，工作到寫作，寫作到生活，而寫作又是一件需要靈感的事情，有時候可能在那坐了老半天憋不住幾句話，而在上班的路上你可能又文思如泉湧，很多時候常常不得不等到夜深人靜，才能夠完全靜下心來投入。

寫書的一年多時間裡，簡直可以用煎熬來形容，無數次想過放棄，也曾經質疑過糾結過，能夠堅持下來寫完，我只能說，Oh，my god，謝天謝地，感謝所有陪伴在身邊的人及支援我的人。從一開始這本書的定位就不是曲高和寡，陽春白雪，而是希望讓各個不同崗位以及不同基礎的讀者們，都能夠有所收穫，因此，內容中即有過程，也有總結，當然，每次回過頭來看這本書，寫作時候的那種“戰戰兢兢，如履薄冰”的感覺，依然還在，寫作是嚴肅的事情，每一次落筆，常常會擔心會不會因為自己的理解偏差，誤導讀者，以現在的眼光或者視角來看，這本書遠稱不上完美，但是一本書不可能無休止的寫下去，難免會有不完美的地方，接受瑕疵有時候也挺痛苦的。

避免失敗是所有工程技術的核心

你個人對架構/軟體架構的理解是？

賢哥：以下僅是個人的一些理解，架構不僅僅融合了思想，融合了技術，同時也融合了藝術，好的架構並不僅僅是停留在技術文件裡，而是在實踐的過程中不斷地修正和調整的，這對架構師也提出了更高的要求，僅僅是停留在抽象和概念階段是沒有太大價值的，細節是魔鬼，一些從抽象層面看起來比較簡單的架構，實際上最大的挑戰往往來自於細節，這些細節既包含產品視覺互動功能的實現，也包含業務規則、風險等種種邏輯的處理，還包括技術上的一些難以預知的“坑”，具體的技術方案在實施的過程中，可能需要花費大量的時間跟精力去解決和避免那些極端情況下可能出現的問題。

架構應該滿足一段時間內的業務發展，但是這一段時間到底有多長，有說三個月，有說半年，有說一年，也有說三年，不同的人不同的環境對於這個問題的理解可能不同，創業型公司，或者是嘗試型的業務，風雨飄搖九死一生，優先考慮的是業務模式而非技術架構，因此，此時的架構應該儘可能簡單儘可能容易實現，三個月之後業務變成什麼樣子甚至是否存在，還很難說，這個時候去想三年之後的架構，基本上也是天馬行空，對於比較成熟的業務，或者是對之前穩定的業務系統進行重構，則需要將眼光放長遠些，避免一些在中長期可能面臨的問題，比如資料庫的分庫分表數量，ID的長度，分庫分表的維度等。

另外就是系統需要可擴充套件，在設計時要留有一定的擴充套件點，避免稍有變更就需要整個系統重構的情況出現，對擴充套件開放，對修改封閉，實際上這很好理解，修改原有的系統而不是擴充套件原有的系統，更容易引入新的問題，也會帶來更大的測試工作量。一段時間之內架構的演變，常常會經歷從清晰，再到模糊混亂，再重構，再清晰，然後又變得模糊的過程，市場環境總是瞬息萬變的，因此，系統的設計要遵循對擴充套件開放，對修改封閉的原則，做到這點即可方便及時的接入新流程，又能夠不影響既有的流程。

從巨集觀來看，各個系統間的關係一定不應該是煙囪與煙囪的關係，而是猶如城市裡的高樓大廈，通過公路連線起來，因此，要提高建房子的速度，就要充分利用已有的基礎設施，已有的中介軟體，來降低系統構建的成本和風險。

架構設計的幾個層次，沒有架構也是架構，專注於解決現有問題也能稱為架構，而好的架構應該是即能夠約束開發者又能夠解放開發者使其專注於功能的設計。儘量將複雜的事情變的簡單，而不要將簡單的事情變的複雜，技術從來都不是用來炫的，而是用來解決實際問題的。避免失敗是所有工程技術的核心，架構也是技術，要運用架構技術去緩解風險。

分散式架構 VS. 集中式架構系統，以及思考

分散式系統架構是一個非常廣發的概念，他有著怎樣的特點，以及在網站何時要用分散式？另外它有哪些的場景？

賢哥：分散式架構實際上是解決了集中式架構系統能力進一步向上擴充套件的所面臨的瓶頸，這些瓶頸包括資源、運維、開發維護等，因為單機的硬體受到技術條件的限制，越往上擴充套件，成本可能並非是線性的而是指數級的，分散式架構通過大量廉價的PC Server叢集，使得能力的擴充套件與經濟成本的關係再次迴歸線性，另外當開發團隊的規模越來越大，業務越來越複雜，分散式及服務化也使得系統能夠更好的進行拆解，讓更多的團隊能夠更高效率的在一起協作。

但是，從另一個角度來看，分散式架構也是一種複雜的架構，很多傳統架構下面可以弱化的問題，在分散式環境下變得凸顯，甚至是成為至關重要的問題，比如資料一致性問題，比如網路通訊、序列化、延時問題，比如如何應對失敗的問題，傳統環境下資料一致性通過資料庫事務在相當程度下被弱化了，而分散式環境下將成為一個非常複雜的問題，另外就是分散式架構使得叢集內部的網路通訊變得更加頻繁，通訊協議、序列化方式、通訊延遲、容錯、效能這些都會變得複雜化，分散式環境下的失敗將成為常態，如何處理這些失敗也會變得一個非常複雜的問題，一個成熟的分散式架構體系所依賴的基礎設施很多，從各種中介軟體，到自動化運維體系，監控體系，容災體系，這些都需要一段時間的積累，並且持續投入和付出，因此，在考慮分散式架構的同時，也需要從投入產出以及回報角度綜合考慮，對於創業公司來說，需要想清楚優先要解決的問題是什麼，再來思考企業需要什麼樣的架構，一味地參考大公司的架構，可能會提前讓系統變得過於複雜，失去響應靈活的特點，從而失去競爭力。

我所理解的網站架構

賢哥送福利：

因資料太多，加QQ群：897889510，領取以上免費的學習資源。

大型網站架構設計的思想與原則是什麼？

賢哥：實際上很難說有個一個統一的思想和設計原則，能夠放之四海而皆準，因為每個人對於設計的理解和理念是不同的，個人覺得設計一個複雜的大型網站，實際上是一個分而治之的過程：

首先得充分的理解業務，理解需求，理解當下需要解決的首要問題，以及可能的風險有哪些，再將目標進行分解，進行具體的技術選型、模型設計、架構設計。如果需要解決的核心問題是併發，則可以通過各種快取手段（本地快取、分散式快取），來提高查詢的吞吐，這樣雖然會一定程度上需要在資料一致性上做出犧牲，由強一致性變為最終一致性，但是，如果資料一致性不是核心需要解決的問題，那麼，此問題的優先順序則可以先放一放，反過來如果核心問題變為資料的一致性，如交易系統，那麼再怎麼強調資料的一致性都不為過，由於分散式環境下為了應對高併發的寫入以及海量資料的儲存，通常需要對關係型資料庫進行分庫分表擴充套件，這也給資料一致性帶來了很大的挑戰，原本的單庫事務的強一致性保障，在這個時候升級為跨庫的分散式事務，而通過二階段或者三階段提交所保障的分散式事務，由於分散式事務管理器與資源管理器之間的多次網路通訊成本，吞吐及效率上很難滿足高併發場景下的要求，而這實際上對於交易系統來說，又是一個很難迴避的問題，因此，大家又想出很多的招來解決這個問題，通過可靠訊息系統來保障不失為一種方式，變同步為非同步，但是，又引入新的問題，訊息系統為保證不丟訊息，則很難保證訊息的順序性以及是否重複投遞，這樣作為訊息的接收方，則需要保障訊息處理的冪等性，以及對訊息去重。

個人比較推崇洛克希德·馬丁公司的著名飛機設計師凱利·約翰遜所提出的KISS原則，架構設計能簡單絕不復雜，堅決砍掉任何華而不實的設計，不要因為3年後可能怎樣甚至是一些現實中根本無法出現的場景，加入到當下的架構設計中，導致系統無比複雜。有時候看似引入的是一個很簡單很容易解決的問題，可能在具體的執行過程中，會因此帶來一系列不必要的麻煩，按下葫蘆起來瓢。

另外一點就是對於未經驗證的新技術、新理念的引入一定要慎重，一定要在全方位的驗證過後，再大規模的使用，新技術、新理念的出現，自然有它的誘惑，慎重並不代表保守，技術總是在不斷前進，擁抱變化本身沒有問題，但是引入不成熟的技術看似能帶來短期的收益，但是它的風險或者是後期的成本可能遠遠大於收益。

設計一個大型網站架構時，通常需要從哪些層面去考慮？伺服器/儲存部署方面需要注意哪些問題？

賢哥：大型網站的設計是一個非常複雜的問題，需要考慮的問題很多，比如海量資料的儲存，儲存又分為線上儲存與離線儲存，線上又有關係型資料庫儲存和非關係型資料庫儲存，持久化儲存和記憶體儲存，這些都需要架構師根據具體的場景進行選型。

高併發且允許資料丟失的情況下，可以採用記憶體儲存，而查詢條件單一，只需要根據主鍵進行查詢，則可以選擇key-value型的儲存，對於海量的文件及圖片內容，則可藉助分散式檔案系統以及CDN邊緣節點，即解決了儲存的問題，又能夠將冷熱資料分離，並且通過邊緣節點提高使用者訪問的效率，如果是需要多維度的複雜查詢，則需要使用關係型資料庫。當資料量大，併發寫入請求多的時候，又需要進行分庫分表，由於分庫分表會限制資料的查詢維度，查詢條件必須得帶上分庫分表的鍵，如果需要多個查詢維度，則需要使用資料同步工具同步出另一維度的資料結構，或者是搭建垂直搜尋引擎，以提供多維度的資料查詢，很多情況下難以通過一種儲存工具解決所有問題，因此需要多種儲存複合使用，以提高效率及使用者的使用體驗。

再又如應用的部署，從集中式架構到分散式架構，SOA服務化，再到時下流行的微服務架構，接入層的負載均衡裝置解決了無狀態WEB應用的擴充套件問題，而軟負載中心則解決了服務發現和服務路由的問題，輕量虛擬化及docker的出現使得Martin Fowler所提出的微服務理念能夠更容易成為現實，當然，大型網站還需要考慮比如某個地域出現不可抗力因素時，如何保障整站的可用性以及資料完整性，諸如同城容災，異地容災（如兩地三中心），以及時下正處於風口浪尖的異地雙活、異地多活架構。

大型網站的架構往往不是一蹴而就的，而是通過需求的推動經過多年演變一步步形成的，不同的時期不同的階段不同的規模，所面臨的業務不同、需求不同、需要解決的核心問題也不同，這就導致不同的階段不同的架構，並且架構也是不斷演進與發展的。

大型網站有哪些典型的故障以及通常有哪些解決之道或相應的優化建議呢？

賢哥：一個成規模的網站可能每天都在經歷故障，只不過故障可能在絕大部分人感知到之前就已經修復了，導致故障的原因很多，有可能是業務邏輯的變更對於依賴的測試不充分，或者是不相容的版本升級導致的序列化錯誤，又或者是測試用例未覆蓋到的程式bug，又或者是不同版本jar包的同名類衝突問題等等，也有可能是訪問量太高導致日誌將磁碟打爆，又或者是機器負載過高導致大量執行緒阻塞，又或者是鎖競爭過於激烈導致程序僵死，或者是資料庫連線池用完，JVM頻繁GC等等。

另外也有可能是由於物理環境問題，比如網線被拔掉，光纖被挖斷，機房停電，硬體裝置損壞等等，導致故障的原因可能千奇百怪，很難一一列舉，對於變更所導致的故障，能做的是讓測試用例儘可能全面的覆蓋到每一個細節，包括依賴項，專案設計階段多考慮風險，按照流程來發布，但是也不能因噎廢食，使得釋出流程沉重僵化，對新的業務需求響應緩慢，實際上這也是一個很難拿捏的度。

此外就是要建立起完善的監控系統，包括異常日誌收集分析，業務流程全鏈路校驗，機器執行狀態檢測（負載、qps、磁碟、記憶體、網路、執行水位），歷史資料的分析，異常報警等，對於服務化的架構，還需要完善服務治理，包括強弱依賴管理，呼叫關係（誰呼叫了誰，誰被誰呼叫了），呼叫頻次，異常狀況等，這實際上是一個體系化的工作，也是一個比較基礎的工作，有了這些之後，你才能夠及時的感知到系統的異常狀況，及時定位問題，修復問題。

構建一個網站時，可以選擇開源或自主研發，前者因萬一選用的開源方案在將來才發現某一些特性不滿足，就得推倒重來，而後者則似乎有重複造輪子的嫌疑，對此你怎麼看？

賢哥：這個問題得辯證來看，使用開源能夠降低很大的工作量，但是也會存在潛在的風險，特別是一些未得到廣泛驗證的技術，即便是使用的十分廣泛的如Struts、SSL，也時不時會爆出一些驚人的漏洞，對於小公司來說，使用開源的技術能夠快速的構建出一個勘用的網站，即便是在使用開源軟體的過程中遇到問題，切換的成本可能也不會很高，但是對於大公司而言，切換的成本可能會變得非常的高，因為業務和依賴關係實在是太複雜，一旦大規模使用，影響的範圍可能非常廣，因此在做選擇之前不得不非常之慎重，當然，我們也會有一些比較特殊的需求，開源軟體無法滿足，或者說是走在了開源的前面，這些工具、中介軟體就需要自己動手開發了。

另外就是開源的軟體有些特性實際上與我們的期望有很大的差距，而他們本身的架構可能又不是那麼方便擴充套件，但是這些特性對於我們來說又十分的關鍵，比如Hadoop，它的MapReduce、HDFS、Hive提供一整套海量資料的分析解決方案，但是底層的許可權控制做的很弱，因此我們不得不花了很大的精力開發出一套替代方案，又花費很大的精力將原來Hadoop上的資料和Job遷移到新平臺。對於開源技術的選擇，我們更傾向於選擇一些社群比較活躍比較成熟的軟體，最好是有一些比較成規模的成功案例的，這樣的風險會小一些，畢竟對於一家成熟的電商網站來說，穩定大於一切，系統的不可用時間是跟成交金額直接關聯的，分分秒秒過去的時間，就是實實在在的金錢。

對於較為核心的應用所引入的開源技術，我們也會花費較大的精力深入地去了解，做一些bugfix，避免踩到一些坑。

另外一點就是大公司的很多場景可能是非常特殊的，比如高併發場景下的MySAL資料庫行鎖，大物件常駐記憶體時的JVM的記憶體回收，一些軟體可能為了滿足通用的需求，犧牲了一些特殊場景下的效能。因此，對於我們來說，瞭解這些後，也是有一定的優化空間的，包括從實現上去規避，或者是去改造開源軟體，而做這些的前提就是對開源軟體的瞭解。

一般網站面臨的問題就是負載的問題，當人數多，導致速度慢是主要解決的問題，對此你有什麼建議？

賢哥：相較於傳統企業來說，大部分網際網路企業都會面臨的一個很大的挑戰，隨著使用者規模的不斷擴大，系統的壓力會越來越大，而在創業初期，系統的架構設計往往是一切從簡甚至根本沒有架構，快速迭代，優先滿足業務，而受市場環境的影響業務往往是多變的，因此往往會背下“技術債”，業務邏輯高度耦合，系統不可擴充套件，程式碼結構臃腫，此時不得不進行重構。

“分散式”是應對大流量核心思想，首先，系統得做好準備，支援擴充套件，尤其是在資料、模型層面，因為資料的拆分、擴容、資料遷移最麻煩最費時間，稍有不慎，還可能導致資料不一致，造成的損失也有可能是無法挽回的，方案設計必須得慎之又慎，在資料拆分遷移的同時，新的資料正在源源不斷的寫入，老的資料也常常會面臨高併發的更新，因此，業界經常將資料拆分擴容比喻成是在給一架高速飛行的飛機換引擎，這也是整個擴容過程中，最複雜，技術含量最高，最有挑戰的任務。

再就是集中式應用的業務邏輯拆分，原先團隊規模小，業務量也小，可能會在少數幾個應用上堆了很多程式碼和業務邏輯，而隨著公司規模的增長，業務迅速發展，團隊規模越來越大，集中式的應用維護將會變得十分困難，這既包括開發部署，筆者曾經開發過一個應用，改幾行程式碼，本地編譯打包需要10幾分鐘，本地部署又需要十幾分鍾，這極大的降低了開發的效率，另外這樣的巨無霸工程也會佔用很多伺服器資源，而單機的硬體資源又不可能無限升級，這也會是一個問題，再者就是耦合的業務邏輯也不便於複用，得四處重複造輪子，浪費資源，這又引申出另一塊，也就是企業內部的服務化。

SOA架構包括時下流行的微服務理念，解決的是企業內部資源複用的問題，避免資訊孤島和重複造輪子，提高系統可維護性，降低業務試錯以及系統構建成本，提升企業競爭力。通用的統一的SOA通訊標準，包括通訊協議、序列化反序列化方式，能夠簡化SOA架構的實現，服務的自動註冊、路由、軟負載能降低運維成本，隨著服務的增加，單靠人工來進行服務治理越來越困難，又衍生了服務治理系統，對服務的呼叫，依賴，異常等資訊進行統一的管理。當應用變得無狀態之後，擴容就非常方便了，通過負載均衡軟硬體設施，或者是SOA的軟負載機制，可以根據需要十分方便的增減機器擴充容量，而這種能力幾乎是線性的(在一定規模下)。當然，大部分的場景以及技術解決方案，國外的Yahoo、Google、Facebook、Linkin 、Twitter…，國內的BAT，這些知名的網際網路企業，實際上很大程度上已經充當先驅，後來的追隨者，只需要緊隨前人的腳步，驀直前行，架構的風險已經被大大的降低。

架構師的技能或素養，架構師到底要不要寫程式碼？

成為一名架構師需要哪些的技能或素養？

賢哥：以下僅代表個人觀點，設計符合要求的系統是架構師的基本技能，功能、可用性、可擴充套件性，以及團隊能力、專案執行風險、執行環境都需要綜合考慮，架構師的功力更多體現在技術的綜合運用上，因此對於專案所需要的技術細節的瞭解必須是全面的，這樣才能夠將最合適的技術用在最需要的地方，並且還需要有技術的前瞻性，通過經驗以及積累發現可能潛在的風險，對於問題的理解，不能夠僅停留在表面，邏輯思維和抽象思維能力是一個架構師的重要素質。

當然，作為架構師還需要一個非常重要的技能，就是充分的溝通，完成系統的設計只是萬里長征的第一步，設計思想需要充分的傳達給團隊中，並且從團隊中得到相應的反饋，對方案進行調整，不斷完善，只有在團隊中所有人都瞭解領悟了你的設計之後，後續的推進包括專案的實施才能夠變得順暢，細節是魔鬼，在後續的執行過程中，可能會面臨各種問題，涉及到的方案調整，溝通協調是不可避免的，作為架構師來說，需要有充分的準備，好的架構師能夠帶領團隊高歌猛進，而不稱職的架構師最終會導致矛盾重重，對於合作的團隊來說，需要確認可能的風險，包括介面，時間節點，相容性，對接可能遇到的技術問題，對於可能遇到的風險，架構師必須瞭然於胸，提前準備，從容應對。

Linus Torvalds說，

Talk is cheap, show me the code.

但是我想說的是，

Talk is not cheap, talk is important too!

很多人會問，架構師到底要不要寫程式碼，首先，個人認為，架構師是需要寫程式碼的，無奈時間是有限的，專案的規模越大，所需要思考的細節點越多，自然而然花費的時間越多；除此之外，作為架構師的你還需要傳播佈道，告訴所有人你理解的架構是什麼樣子，告訴大家怎麼做如何做，核心的目標是什麼，核心的風險是什麼；架構師還需要協調各個依賴的關聯絡統，告訴其他人你要做一件什麼事情，需要其他人怎麼配合，做這件事的價值以及其他人為何要配合你，這同樣需要花費大量的時間，那麼，在剩下不多的時間裡，架構師能寫的程式碼可能不多，但是，為了讓你設計的系統不脫離現實，你必須寫程式碼，必須Review核心關鍵程式碼，確保整體架構的思路得到貫徹，確保你的設計是易於實施的，確保潛在的風險得到妥善的控制，特別是在有新技術引入的情況下，原型驗證是必不可少的步驟。有種觀點認為，架構師必須是程式碼貢獻最多的，一個人寫程式碼，自然不需統一思想，但是實際上這很難做到，作為架構師你得記住，不是你一個人在奮鬥，不要讓自己成為團隊的瓶頸，但是，我同樣也不贊成架構師完全不編碼，不親身體驗過，有的風險是很難事先做出判斷的，何況技術本身也在發展，今天的經驗放在明天不一定有效，作為程式設計師的最基本技能，編碼是你學習和積累的最直接的方式。

架構師也是一個普通人，一天只有24小時，需要花費很多時間進行方案設計，技術合理性思考，原型驗證，還需要花費大量的時間給團隊傳達設計思想和目標，為何這樣設計，這樣設計有什麼好處，不這樣設計會有什麼樣的問題，人是最複雜的生物，程式設計師都是非常有個性並且非常聰明的，統一思想統一目標是一個非常艱鉅的任務，一千個人心中有一千個哈姆雷特，同樣，做一件事情可能也有不同的方法，方法太多有時候並不是好事，作為架構師，需要找出最合適的方法，並讓它得到大家認可，這並非是把個人目標轉化為團隊目標的過程，而是不斷地溝通不斷的改進演化之後，在大家充分參與的前提下找到的最適合當前業務場景的方案。

對未來你有著怎樣的規劃和期許？

賢哥：技術這條路註定不是坦途，碼農大多數時候的生活是枯燥無味的，並且這又是一個學無止境的行業，技術的更新換代非常快，失敗的糾結，苦思冥想的無奈，成功的喜悅，其中的酸甜苦辣，我想只有真正的碼農才能體會。

近期來看，應該會繼續專注於直播，阿里在電商領域積累了豐富的經驗，但是對於直播來說還屬於一個有待成熟的領域，還有很大的提升空間，技術挑戰也是比較大的，後續希望能夠做一些事情，降低直播的門檻，降低資源的消耗，提高服務的穩定性。

就跟《戰爭之王》這部電影裡尤里·奧洛夫（Yuri Orlov）的經典臺詞所說的一樣，人總想在有生之年做件大事，只是暫時還沒想好要做什麼，誠然，我不會跟尤里一樣去販賣軍火，社會的發展和變化太快，很難預料自己五年之後會專注於什麼，從事哪方面的工作，但是，作為一個熱愛技術，喜歡專研的人，應該還是會是做跟技術、跟工程能扯上點關係的事情。

最後，想給看這篇文章的讀者說些什麼？

賢哥：當初畢業找工作的時候，說實話也沒想過說一份工作會幹這麼長時間，而且後面可能還要繼續做下去很長時間，實際上畢業的第一份工作非常重要，因為當你開始工作之後，你將不再是一張白紙，而你後續再去找工作的時候，前面的工作經歷將會是很重要的參考，第一份工作將很大程度影響你後續工作的大方向，後續再想要轉型，可所付出的努力和冒的風險可能更大。

選擇有時候很重要，首先得清楚自己喜歡做什麼樣的工作，因為做自己喜歡做的事情，你更願意付出，不會覺得辛苦，更不會覺得痛苦，而是樂在其中，工作是一件長期的事情，因此，值得你好好想想自己到底喜歡做什麼。

另外就是看後續的成長空間，一滴水到了一杯奶中，水就變成了奶，一滴奶到了一杯水中，奶就變成了水，有可能某個公司A給你的offer多了1-2K，而公司B卻能夠提供給你一個更大的舞臺去發揮，去成長，給你提供一套系統的培訓和成長體系，並且周圍都是業界大牛，此時的選擇，考驗著你的智慧。

短期的1-2K，從長遠來看，實際上真的不算什麼，但是損失可能是長期的發展空間，那有人說，工資給的高不說明更重視麼，話雖沒錯，但是去到一個沒有發展空間的公司，或者已經是夕陽產業，也許你確實很優秀，可能你的高度就代表了公司最高的高度，那麼你的空間在哪，這實際上是一個雞頭鳳尾的抉擇問題，選擇一個更有空間更有潛力的公司，可能剛開始你在團隊中並不是那麼出色，但是，認真工作幾年後，你再出去跟同齡人比，區別還是蠻大的，並且，優秀、成熟的公司會有一套相對公平的評價機制，總的來講，會讓足夠優秀並且給公司創造更多價值的人，得到相應的回報，所以也不用擔心回報的問題。實際上HR也不傻，你得到的回報可能是經濟上的回報+成長空間的總和，而兩部分加起來，大部分公司給出的價位應該是差不多的。

機會是總是留給有準備的人，選擇很重要，堅持有時候也很重要，做事情得要能沉的下心，不要怕困難，人生就像騎單車，想保持平衡就得往前走。

如何學習才能快速入門並精通呢？
當真正開始學習的時候難免不知道從哪入手，學習時頻繁踩坑，導致效率低下影響繼續學習的信心，最終浪費大量時間。
為了讓學習變得輕鬆、高效！今天給大家免費分享一套教學資源，幫助大家在成為架構師的道路上披荊斬棘。
群內已經將知識體系整理好（原始碼，筆記，PPT，學習視訊）進群免費領取。
加QQ群：897889510，免費領取資料
享給喜歡Java，喜歡程式設計，有夢想成為架構師的程式設計師們，希望能夠幫助到你們。
最後，做一個愛思考，懂思考，會思考的程式設計師。