?

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

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

賢哥：目前在負責某直播平臺，包括整體的技術架構以及業務推廣，平臺旨在提供直播的一站式解決方案，涵蓋了大型音視頻直播、超大直播間中的聊天、彈幕、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集群，使得能力的擴展與經濟成本的關系再次回歸線性，另外當開發團隊的規模越來越大，業務越來越復雜，分布式及服務化也使得系統能夠更好的進行拆解，讓更多的團隊能夠更高效率的在一起協作。

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

我所理解的網站架構

賢哥送福利：

資料太多，加企鵝群：8 9 7 8 8 9 5 1 0，領取以上免費的學習資源。

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

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

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

個人比較推崇洛克希德·馬丁公司的著名飛機設計師凱利·約翰遜所提出的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也不傻，你得到的回報可能是經濟上的回報+成長空間的總和，而兩部分加起來，大部分公司給出的價位應該是差不多的。

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

轉載于:https://my.oschina.net/u/3985214/blog/2877303

總結

以上是生活随笔為你收集整理的专访阿里王贤：我所理解的网站架构的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。