專訪阿里王賢：我所理解的網站架構

 

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

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

賢哥：目前在負責某直播平臺，包括總體的技術架構以及業務推廣，平臺旨在提供直播的一站式解決方案，涵蓋了大型音視頻直播、超大直播間中的聊天、彈幕、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也不傻，你獲得的回報多是經濟上的回報+成長空間的總和，而兩部分加起來，大部分公司給出的價位應該是差很少的。

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