以下為2012年全球架構師峰會ArchSummit第一天早上的實錄資料。

【時間】2012年8月10日 上午

【地點】深圳萬科國際會議中心大宴會廳 

【實錄內容】 

【主持人霍泰穩】我是InfoQ的創始人兼CEO，今天上午的串場由我來主持。現場有多少同學從華南地區過來的？（全場大部分人舉手）這個效果正是我們InfoQ想要的，今年要在華南做一次全球峰會，主要是為了華南朋友不要那么周折去參加活動。第一次在北京做活動的時候，很多朋友從深圳、廣州過去，華為、騰訊每年都有很多人參加，做了一個簡單的回訪，去北京參會最大問題是什么？很多人說太遠，三天會議的票價還沒有差旅費那么高。

在去年在杭州做了另外一場全球軟件開發，今年在深圳做Archsummit，Archsummit主要關注架構方面，全球軟件開發大會除了架構包括軟件開發和項目管理方面。

在今天上午有三個主題演講：

第一，大數據的技術趨勢和演變。

第二，騰訊開放平臺、架構設計揭秘。

第三，一個圓桌論壇。

在座的都知道Facebook，這次我們邀請到Facebook前數據團隊的負責人，也是Apache蜂巢的創始人。今天分享中首先會談到大數據的驅動力，接著是演化、遵循的路徑，背后的故事，還會談一些方向以及包括一些挑戰。

第二個主題演講嘉賓是湯道生，騰訊公司的高級執行副總裁，有四個人直接向馬化騰匯報的，湯經理是其中一個。今天分享的是騰訊開放平臺架構設計揭秘，主要包含幾方面的內容：

如何實現整個海量處理架構、如何把這種架構的能力提供給創業團隊，現在創業人士越來越多，不能在開放平臺上做事情，要自己做事情。騰訊開放平臺會提供什么幫助。以及會談到很多人關心的安全問題，如果放在騰訊開發平臺上怎么保障數據的安全性。

第三個是圓桌論壇，邀請了幾位嘉賓，主持人是王宏，來自上海大眾點評網的高級架構師，從一開始創建在大眾點評工作，架構是由他來主導設計的。有四個參與者：

黃冬，土豆網產品與技術副總裁，是啄木鳥社區的創始人；

廖若雪，百度技術委員會主席；

湯道生剛才介紹了；

吳永強，去哪兒CTO，現在主要負責技術團隊的管理。

接下來邀請下午的主持人介紹一下負責的專題包含哪些內容，聽了簡單的介紹對下午有一個簡單的了解。下午可以自由選擇相關的場地，有請吳永強。

【吳永強】主持人一說壓力很大，我主題專題是架構的伸展與演變。我們覺得架構像一個孩子的心智一樣，架構像他的父母，怎么在企業不斷擴張、成長的過程中，帶領著架構不停地往上升級。

主要講師有：

第一，來自于人人網的劉源，從人人網的特點講到遇到的問題和解決方案，從很具體的故障當中分析大型系統中的共性問題。

第二，來自騰訊的張松國，講得騰訊微博架構引進的三個階段，分的非常清楚。包括第一個階段的平臺化，第二個階段的性能優化，到第三個階段更高層次的要求，比如說高質量運維方面的內容。

第三，來自淘寶的趙超，他在淘寶待了十幾年，見證了淘寶從最開始很簡單的架構，到現在承載了中國電子商務網站中最大流量變遷的過程。講得東西很有意思，基本上他講大家都會覺得像說相聲一樣，非常有意思。

第四，Ashish講的是Facebook海量數據架構演變過程。

歡迎大家下午參加我們的專題，謝謝！

【主持人】這個專題就在這個會場，下面一個主持人是來自百度的廖若雪。

【廖若雪】大家好！下午我這邊主持的話題是“搜索新時代”，搜索引擎從發展開始，架構是搜索里面一個革新的技術，我們處理互聯網網站、互聯網數據，達到PP級的分布式計算和存儲平臺。我們現在認為搜索引擎對于大多數用戶來說是隨時可用的系統，如何解決這方面的問題？如何提供高可用性？提供隨時可用的服務體驗？都是搜索遇到的問題，今天在下午講師有：

首先，百度公司最早架構師的陳競凱，會講搜索引擎的架構，一開始怎么做？發展到什么程度？思考以及展望。競凱對百度搜索引擎最了解，最清楚的架構師之一。

第二，來自搜狗的茹立云，主要講來自I網核心的問題，不止是針對PC互聯網上的數據，去抓取應用非常好的價值。無線互聯網時代的數據，非常具有現實和將來的意義。

第三，一淘網的曲琳，主要講大的應用垂直搜索，與一般的網頁搜索相比除了遇到的問題，還會遇到更復雜的策略、更復雜數據相關的問題，更重要的是如何建立一個很有效的運維系統提供高可靠性、可用性的系統。聽完這樣專題會有問題，所以最后我們有一個圓桌論壇，有什么問題可以一起討論，充分解決大家的問題，充分理解在這里的分享，謝謝！

【主持人】謝謝！下面有請海量視頻的處理與分發的黃冬。

【黃冬】深圳來了之后先被出租車凍了一下，又熱了一下。視頻網站帶寬用很多，用的很大，量也很大。光大沒用，還要有新的東西。今天講與視頻網站相關的新技術和面對的新問題。跟大家介紹一下視頻網站新興的不同的方向。

首先，來自微酷的首席架構師趙志猛，主要分享在微視上遇到的問題，傳統的視頻特性和微視頻遇到的問題，如何做好的、快的架構，這個內容很新的。

第二，來自于視訊天下的廖雪峰，基于視頻的SaaS，可以用視訊天下的平臺搭建視頻網站，搭建視頻網站上的各個服務，因為是SaaS的平臺，匯集了現有的視頻網站經驗，以及面對中小用戶出現問題一系列的處理，有非常精彩的處理。

第三部分，來自于土豆網，會很細致的說一下在土豆網如何完成整個視頻網站最核心CDN部分處理的特性和實踐方法。土豆網CDN的架構非常獨特，在國內視頻網站里面最與眾不同的一個，歡迎大家一起聽一聽。

最后，杜嵩會為大家講一個特別的話題，視頻廣告的架構，視頻網站的廣告和傳統互聯網不同，互聯網是基于網頁的廣告，而視頻廣告有很多獨特的特性，決定了一個截然不同的架構。如何面對用戶訪問的特性以及后面的數據處理都有非常精彩的分享。

所有有關視頻相關的部分我相信都會有很好的分享，希望大家到我們的會場來聽一聽，謝謝！

【主持人】非常感謝騰訊和騰訊大講堂，假設沒有騰訊的支持，全球架構師峰會在深圳舉辦非常困難的。在和騰訊溝通過程中非常愉快，給整個大會，包括在組織上、資金上、內容上給了非常多的支持。非常感謝另外一個VIP的贊助商VMware，感謝它的支持。

QCon杭州在10月份，有需要的同學報名。讓我們掌聲有請來自Apache Hive的Ashish，有請他來第一個分享！

#p#

【Ashish Thusoo】各位上午好！我叫Ashish，第一次來到中國，感謝主辦方邀請我來參加這次活動，今天談一談大數據架構以及怎么樣不斷的演進，與其說演進，不如說革命。

首先，看一下今天講的三大主題：

第一，大數據的需求。當今世界需要大數據，有哪些驅動因素促使我們不同方式考慮大數據？以不同方式處理數據。

第二，技術給我們帶來哪些架構上的調整或者權衡。比如說新的技術和傳統上90年代的數據技術有哪些變革？架構上做了哪些調整？要哪些優化？不同緯度做權衡的標準。

第三，未來。我們哪些技術問題需要解決的？

以上是我講的三大主題，希望大家會覺得有意思，從中學到一些東西。

 

首先，看一下變革的驅動因素是什么？我們生活在不斷變革的世界中，有三個技術的參數，在大數據方面帶來很大的變化：

第一，設備。第二，基礎設施。第三，應用程序。

以上三點結合在一起，不但快速改變我們的生活，而且變革給我們帶來很多的需求，這里講了三個技術上的驅動因素，分別意味著什么？具體來看一看。

首先，看一下設備。現在看到的圖是手持設備發展過程，上世紀90年代的手機非常大，不可能隨手拿著，放到包里才能帶出去，最新的是現在看到的iphone，獲得了非常大的變化。比如說PDA或者其他的智能手機，現在有一些重要的能力，以前無法設想的，永遠保持網絡聯系，可以查詢到它的位置。

有非常強勁的功能，可以用GPS、有攝像頭，可以進行重力感應，調整現在的溫度。手機從感官的角度來講，把人的感官延伸，這些程序給我們帶來很多數據。除了講得PDA和所聯系的設備部分，包括iphone，其他設備也在進化，包括智能讀表器、健康情況小設備，融匯在我們生活中，非常強勁，也給我們產生很多數據。這些設備產生了很多數據，也讓我們想想怎么好好管理這些大數據。

互聯性，現在看到的是國際電信聯盟下載的材料，是關于全球移動用戶的用戶數量。2004年的情況，藍色是密度非常低，在亞洲和非洲地區。黃色密度最高，用的最多是橙色的。在一些不是特別發達的國家，甚至世界各地，手機用戶數量越來越多，不僅講得是互聯性，還有帶寬，新的無線傳輸技術，使得手機設備方面的數據傳輸越來越快，最大的手機傳輸數據100兆已經不是問題，未來會越來越高，相互聯系的能力會越來越強，帶寬越來越寬，以及我們說的感應設備等。這種技術上的大融合趨勢，能夠讓我們看到了最后一個應用。所有新的技術要通過應用才能實現。

現在看到很多基于云計算的程序，很多應用化計算都是基于“云”的，在90年代關注企業里面有10個人、100人、1000人，現在規模和容量擴大，不僅幾千、幾萬，甚至上百萬、上千萬，現在設備做得越來越多，聯系性越強，設備越強，有更大的帶寬，基于云的集中式的數據。這三點是需要的大數據。感應式的設備生產數據。更多的聯系性把數據到云端，在云端做些什么呢？這么多的數據怎么運作快速生成的大量數據。大數據意味著很多人一起做很多的事情。要關注大數據的三個特點：大容量、高速度、種類繁多。不止有一些表格、數據，應對非常多的數據。

舉一個例子，在容量方面，2011年數字宇宙里面，我們所存儲的數據是1.8個ZB，1個ZB相當于100萬個GB，2009到2020年中間，數據總數量達到35個ZB。

再來看一看速度，數字形成的速度也讓人瞠目結舌。現在的數據來自于知名的互聯網應用，推測的數量每天3.4億，而且數據不是最新的，最近數據增加非常多，另外每分鐘上傳的視頻72小時，每秒290萬封郵件，數據生成的速度非常快。另外還有視頻、圖片、應用、記錄等，不僅僅講得傳統意義上的圖表，現在還包括各種各樣的文件。

現在講得數據和過去講得數據不一樣，是大容量、高速度、種類繁多的數據。這對系統架構有什么影響呢？影響非常深遠，直接關系到在過去這么多年以來，怎么樣向數據不斷嚴謹。回到上世紀90年代，我們關注的是結構性的數據，怎么樣數據處理更快。現在的應用越來越繁雜，需要不同的規格以及不同的擴展，因此我們的關注在過去十年里也出現了變化。原來只是關注簡單的性能，到現在可擴展性、可應用型。原來只是機械、剛性、結構性的數據，現在已經靈活半結構化的數據。我們講得是數據結構、數據架構里面顛覆性的變化。

現在看一個平臺成功的標準也出現了變化，這種標準的變化是現在看到的技術上的變化，是著重講的。

再深入看一看具體的方面，首先從可擴展性方面，系統怎么樣通過演變解決這兩個要求，很重要的要求是有一個簡單的解決方案來解決復雜的問題，或者簡單的方法解決復雜的問題。怎么解決可擴展性呢？我們要有這樣一套系統能夠處理PD級的數據，每秒操作達到百萬級，這也是我們所面臨的問題，是可擴展性的要求。簡單的方法可以采用分片方法，是很多架構所采用的分而治之的方法。可以把數據問題分成塊，不放在同一個系統上，分成幾個分片，這是一個很基本的理念，這種方法是所有系統當中所通用的構想，所以接到系統的時候，最核心的一點就是要用分片的設想。

簡單的概念，在深入思考的話，有一些其他的復雜問題解決。比如說，一個很基本的分片問題，怎么樣把某一條記錄導入到不同的分片當中。很多的功能，比如說應該放到某一個分片上，怎么樣快速把這條記錄放在合適的記錄上，確保可用是安全存放的，有很多問題。我們有各種機制解決引導的問題，用的一致性的散列、映射表也來自于這些方法。其他也有一些應用，比如說一條記錄一半放在一邊分片，一半放在另外分片，怎么解決？是分布式的傳送問題。很多系統以前是分別的傳送，來儲存不同部分，怎么確保到達不同的系統呢？今天的系統要有可伸縮性、可擴展性，要用非常高度的簡化方法來處理問題。簡單的問題就是把記錄的兩個部分單獨的看作獨立的兩塊。這部分記錄獨立的看作一個部分放入某一個分片，進入這樣的分類，簡化了數據的分類，存儲就加以簡化，分片的處理把數據分成不同的部分，分到不同的分片上單獨作為一個獨立的部分看待。

另外一個復雜的問題，在分片當中，如果有一個分片壞了，這時有一條新的記錄，記錄往哪放？分片機壞了，不知道往哪放怎么辦？如果一個分片壞了當然可以放到其他分片上，可用上減少，并不是減少到零，只是其中一部分壞了而已。如果整個架構壞了就完蛋了，是其中一塊壞了。我們要用很好的方法，就算是一個分片失效了，也要用到該用的分片機上。我們做不同的副本，把分片進行不同副本的存放。有一套記錄，兩套副本，上帝保佑不要三片全壞就行了。通過復制來解決問題，但是需要有多少個副本呢？數據進來之后應該在副本當中復制多少次呢？要確保記錄安全的話，什么時候要重建一個副本呢？或者一個副本失效了，要建立另外一套副本，怎么把記錄傳送到新的副本當中呢？這里有很多重點，用復制的方法解決問題。同時，這個過程帶來新的問題。所以我們應該在系統構建過程中一體化進行考慮。

以前系統往往是在事后考慮問題，現在在系統構建過程中就要設想到這些問題，在技術當中加以解決，這是內在的設計。這里看到很多不同種類的方法解決，有些用一致性的散列或者在一些零片上進行復制或者恢復，當然有不同方案解決的問題，可以用單一的映射表來解決。解決的方法是多種多樣的，包括怎么樣從一套副本恢復到另一個副本當中。這也是不同架構師的不同方法。但是最基本的一點是設想和思維是一樣的，最基本的方法是要加以簡化，按照這種思路來設計不同解決方法來解決不同問題。

為什么我稱是顛覆式的發展，因為關注點不同，90年代是單片的效能和績效，比如說IO結構做得最好，怎么減少IO的傳送，怎么樣設計出一些更加對緩存敏感的算法，這是90年代在系統設計的時候關注的重點，2000年以后有了顛覆性的變化。最基本的角度是考慮可擴展性、可用性，涉及到分片和復制。這也是我們講到為什么是一種顛覆性的變革。

我們講得第二個層面的變化是柔性數據、靈活性以及半結構化。我們解決柔性數據的問題在哪呢？其中一個是我們的數據庫并不只是記錄和表格，有些數據我們可能是優化專門存放表格、數據和記錄的，但是實際上還要考慮這個應用程序到底怎么樣構建的。可能大家聽過短跑模式，不會坐下來整個架構、整個系統，想到所有的數據、所有的構思再寫應用程序，今天寫應用程序非常快，快速變化，得到反饋馬上調整改變，這個應用程序是不斷改變的過程，我們做一些短跑式的模式，使得整個架構、記錄的結構不能固定下來，固定下來不能靈活的調整程序，我們希望應用程序變化的時候，不需要改變數據的結構。這也是我們現在要解決的問題。通過現在一些系統和架構解決根本性的問題。

現在要構建這種記錄有很多好處，比如說可以得到優化的計劃，可以按照我們應用來優化存儲的布局，包括陣列、分類、縮影、查找等。可以實現一些好處，這個系統可以帶來最優的選擇獲取數據。可以優化數據存儲，不需要把結構性的數據存放在一塊，可以單獨存放起來，但是有利有弊，取舍是我們優化的速度、優化了它的性能表現，但是有沒有優化應用程序的更新呢？如果應用程序的應用發生了改變，數據庫能不能跟的上呢？如果應用程序發生改變，數據表加了一列，結構發生調整，使到我們減速，這也是能夠重建的縮影。我們系統要怎么樣應對這些挑戰，最主要的問題是我們在網上的世界當中，往往在網上操作是很簡單的操作，可以設想我們的前提、觀點，其實要用我的數據系統，要的很簡單，簡單的查找、更新，并不需要去過多的擔心一些非常復雜的操作，但是大部分的操作是簡單操作的話，其實并不需要關注用什么樣的執行計劃，為什么要去把整個的架構放到某個系統當中，如果有些并不用到這些系統，關注的是應用開發速度。解決這樣的訴求，必須要有一種足夠的結構性，來滿足要求。有足夠的結構性來滿足快速讀取的要求。

簡單的方法是把一切的數據分成鍵和值的關系，所有都圍繞這個系統。如果應用程序發生改變，這個也隨之對應。就像一個巨大的散列表。我們的操作只需要找到這個鍵，再看這個鍵對應的值是多少？再提取出來。只需要優化這一步。聽起來很簡單，但是要做很多的工作優化這種結構，使到這個結構運行起來很快。比如說有些經過分類的散列表、分類的文件，這樣才能優化機制、快速存取、范圍查找、快速更新。我過于簡化了這個問題。

應用程序希望獲得的能力，在更新某一個鍵的時候，把關聯的其他數字一起更新，這是另外一個結構。這個結構要增加一部分，數據系統當中增加標簽的一列。不同的系統，有的叫標簽，不同的組、不同的名字。在一個服務器當中，可以進行一種關聯數據同步的更新。在某幾個數字用同一個標簽，屬于同一類、同一組的更新。最根本的是鍵、標簽和值，這個體系使到我們真正能夠響應、優化我們最常用的三種操作：查找、范圍查找、更新，這是專門為企業優化的，同時也可以優化應用程序的開發，應用程序開發的時候，也可以應用短跑模式。

剛才講得這么多對于在線的很需要，但是有沒有一些分析性的應用呢？在座的各位知道，我們做分析過程非常復雜，有不同類、不同組、不同分析工具，另外，在數據上做不同數據的轉換，才能了解到數據的情況。剛才講了三類的分析是比較簡化，怎么查詢、存取等。在簡化之余，過程非常復雜，這個方法在分析過程中能不能用得上呢？在分析的時候查詢非常復雜，這些工具是否合適？有沒有簡單的結構解決分析查詢的問題。

其實很多應用比較關注這個問題，很多數據系統也關注有沒有方法解決分析的問題，其實很簡單用簡單的技術就可以，就是分類。

接下來看看映射和縮減，可以擴展、可以并行分類。不僅僅把它作為一個處理，而是進行更好的分析，把信息分類出來。比如說拿出一個數據集，可以分成不同的分片和分成，分成三個數據集，有紅色、綠色的。我們影射不同的數據集能進行化解。怎么把綠色和紅色的剔出來，放在一起。我們可以分類，非常不錯。我們的用戶可以自己界定所謂的影射函數和化解函數。這樣的話對于用戶來講更加靈活了，不僅僅是原來要贊助的特定數據，還可以用其他類型的數據，用影射工具很快影射出來。比如說有圖像信息分出來，具體的目標去提取。而且在我們所做的這些工作核心就是我們講得可以使用并行的分類。這樣的話可以把原來復雜的架構變成簡單的架構，這種靈活性也是我們現在所要關注的。

除了這些好處之外，還有什么其他優勢呢？在數據信息分類之后，出現故障什么問題。比如說分了幾個小的數據集，如果出現問題了，怎么辦？數據保留下來還是重新再做呢？在一個完全平衡有很多數據的系統里面，重新再做肯定要花很多時間才行。因此在我們的系統里面影射以及化簡的過程中，可以隨時重啟。如果發現影射器里面有些出了問題怎么辦？不需要重新啟動，只要把有問題的影射器重啟就行。在數據分析過程中，不同地方加入了檢查點的功能。其實我們的關注在于首先要把結構變得更加簡單、更加靈活，而且有更高的可用性。就像系統還原一樣，找到有問題的點重新做一下就行了。原來是中間出現小問題就要重新做，現在不用重新做。原來查詢系統沒有任何檢查點的概念。原來我們講得系統只是去關注性能。更多關注結構才能優化速度。進入21世紀之后，我們使用短跑的模式，不像我們原來所說的看單純的性能，在開發構造應用程序出現很多的變化。

前面講到設備的效率和數據的多樣性，在演講一開始就說過。

 

接下來看看未來的前景怎么樣？往哪些方向走？

這個系統里面有一個非常關鍵的主題，和其他的基礎一樣，肯定會讓我們和以前的技術分道揚鑣。但是，在這里發現不能完全各走各的路，還是要把我們發展建立在這個系統之上。現在不僅是新老交替，在新老交替中，還要進一步融合。我們還需要一些舊的SQL，否則無法做影射，還需要一些相應的語言。剛才講得這些方面已經做了很多工作，有些是用新的語言，很多用舊的語言。怎么將其他組件組合在一起呢？新的應用程序是獨立的東西，自己來用非常好、非常不錯，但是如何把新的東西和舊的東西加在一起，或者在新的系統上加入一些其他的組件。現在也在關注其他的情況，現在系統剛剛起步，很少一部分使用，慢慢形成主流之后看更多的結合在一起。

一開始講到了更多關注可用性、可擴展性，效率講得不多。如果數據越來越大、規模越來越大，效率也非常重要，怎么樣能夠有更好的、更高效處理大量的數據。比如說銀行交易，把錢存在一個賬戶轉到另外一個賬戶里面。有些人說，他能夠做，但是現在情況來講，很難把你的錢轉到另外一個賬戶。舊的系統里面關注怎么樣優化資金傳輸的效用。舊的系統做得很不錯，新的系統無法比肩舊的系統，無法解決。

現在很多路徑里面都有圖形，像社交網絡里面圖形，有時候可以做一階分析，二階分析和三階分析怎么傳輸出去，這是做得不足的，要解決。

新的系統里面有很多需要解決問題，但是有些解決方案已經浮出水面了。比如新的范式、新的操作界面、新的應用。新的系統為大眾所接受必須要跨過的橋梁。標準讓更多的人所熟知，或者界面更加簡單，讓一些新的用戶輕松的了解到可用之處。

說到這里想再花點時間講下面這一點。如果要高速人們了解這些信息的情況，把它部署在一鍵式全包的方法，通過云來做。現在具有很強的可用性，或者可以用虛擬機來操作，但是如果用虛擬機的話，不清楚到底什么時候突然有問題。現在可以通過云端來去做，通過云端來做可以有效減少采用這些部署系統的復雜程度。只要放到云端可以解決所有的問題。當然，說到這些，可以說是任重而道遠，有很多的工作要做，尤其是在分析領域。

Apache就在關注這些問題，怎么按需提供系統滿足客戶的需求。另外，我們該使用什么結構？原來的可以繼承下來，通過改進做得更快，可以直接把系統部署在里面做得更快。現在已經做了一些工作，解決了一些小問題，比如說自動擴展、高速緩存等都可以實現改變。我們講得大數據還有很多東西期待解決。我們要讓系統進入主流系統讓更多人所接受。比如說分析師、數據使用者了解，需要很多工作做。

我們可以說剛剛起步，未來還有很長的路要走，非常激動人心的時代就是我們看到在整個應用、基礎設施、設備方面有很多很大的變化，這些變化反過來也讓我們這些系統架構師反思一下過去做得什么，該采用什么變化，改變我們所做得緯度、改變我們品牌與架構成功的標準，不僅看速度、看靈活性，看短跑模式更快部署、怎么應對更加廣泛、大量的用戶。

在這里總結一下，再次感謝主辦方邀請我參加此次峰會，如果大家有問題很樂意回答問題，沒有問題的話講到這里，謝謝各位！

【主持人】由于時間的關系不留提問時間了，接下來是十分鐘的短休，十分鐘之后由騰訊的湯道生為大家講一下騰訊開放平臺的話題。

 

#p#

【主持人】湯道生是騰訊的高級執行副總裁，2005年加入騰訊，參與系統架構設計和平臺規劃的工作，曾擔任QQ空間產品部總經理、QQ秀產品部總經理、互聯網研發部總經理等職務，致力發展騰訊社交網絡服務與增值業務。自2008年10月起擔任互聯網業務系統研發副總裁、公司副總裁、公司高級副總裁，負責互聯網業務系統多項平臺產品策略與技術平臺研發和運營的管理工作。掌聲有請湯道生分享騰訊開放平臺設計！

【湯道生】各位嘉賓、各位技術專家，大家早上好！今天負責高興在這里有這樣一個機會跟大家分享騰訊開放平臺的一些設計理念，架構設計的想法。我是2005年加入騰訊，一開始是作為一個架構師在騰訊參與了不少前期架構的項目、后臺存儲等方面，設計系統也有產品。后來從技術人員轉向到產品業務方向發展。同時，在這個轉型、轉變中，把很多以往在技術上的設計理念、設計方法帶到業務、帶到產品上來，今天我也希望借此機會跟大家分享一下騰訊開放平臺設計上跟平時做的系統架構設計有什么相關地方、類似地方，從而延伸通用系統的設計理念的探討。

據我的理解，系統架構的設計其實很多時候是圍繞資源的管理，不管CPU的資源、內存的資源、還是硬盤IO的資源或者在開放平臺上推廣的資源、用戶的資源。這些往往在系統上，不同階段有不同的稀缺性。系統架構的設計，在允許的時間內、有限的資源內怎么可以建立一個可持續的架構來實現一條可執行的系統，滿足用戶需求或者解決問題。后面的介紹也會圍繞架構設計的主題來探討到底怎么去管理資源、系統的設計跟開放平臺的設計有什么共性的地方。同時，我們發現技術發展經常受到許多經濟因素的影響。05年來到騰訊，從美國一個企業軟件的公司來到騰訊，有一個特別很深的感受，我記得在美國當年我們做很多的設計優先考慮的是開發人員的效率，怎么把語言不斷抽象，提升開發人員的效率。后來我來到騰訊，很不一樣的感受是，騰訊會花很多開發人員的力量、很多人優化每一個細節，到很底層的細節。每一臺設備去擠出能服務用戶服務的量。為什么有這種大的不同考慮？后來自己也深入思考。七八年前國內開發人員的薪酬和成本跟美國薪酬開發人員成本還是有一定的差距，而且騰訊海量的服務，如果在某一臺設備效率提升一點點，放大到上千上萬的設備上，是更大的節省。我們發現系統架構設計，很多時候離不開經濟因素的考慮，不同環境瓶頸不一樣，要特別提升的效率可以是不同的情況。

當然，隨著技術的進步、硬件設備的發展，不同硬件設備發展的速度也不一樣。為什么我們說設計經常是一個動態的考慮，到今天我們也越來越注重開發人員的效率。因為國內開發人員的成本在過去這幾年慢慢起來。我想這是一個非常有趣的話題跟角度去思考。在推動騰訊開放平臺的過程中，有蠻多的感受。好比一個熟悉的操作系統一樣，大家都需要很多資源的管理，不管CPU、內存、硬盤、IO還是開放資源、推廣資源，資源有限、要服務的對象到底是系統上的進程，進程有大有小，有很多服務，同時在不同開放類型上有應用、滿足不同的需求，也有不同的規模。套作系統上的API可以讓我們管理不同的資源，也可以有一些機制做通知的體系，協助不同進程之間的溝通聯系。同樣我們在開放平臺需要把一些資源在一些標準的接口下開放出來，怎么管理應用的溝通，怎么提供用戶通知的體系，有很多類似的地方，硬件設備的標準更不用說了。

提到騰訊的開放平臺，應該從08、09年的農場說起，當時QQ空間還是一個騰訊服務為主的封閉系統，是一個社交網絡。當時看到國外很多的平臺，甚至國內也有很多社交網絡的平臺，都跟著開放API，介入了第三方的應用，我們自己也在不斷思考，到底應該怎么做。我們也發現真正要做好一個開放平臺，所需要的能力或者所遇到的挑戰還蠻多的。一開始嘗試介入了農場來到平臺，在跟第三方合作的過程中，發現服務海量的用戶所需要的能力，對于架構上的要求還蠻高的。所以在發放使用或者嘗試體驗產品過程中怎么去放量。發現放得太快系統頂不住，服務停了，我們有建立怎么防雪崩的機制。我們設計各種各樣的模擬器、外掛，又把很多經驗帶給第三方使用。把很多的數據分析、使用分析，怎么判斷模擬外掛的行為能夠開放出來給第三方使用。當然，數據的可靠性非常重要，我們做所有的事情、目的都是希望為用戶提供更好的服務，讓大家玩的開心、使用的放心。所以，怎么保障數據的可靠性，騰訊原來很多基礎服務，對于存儲這方面特別有高的要求，多份備份，多異地IDC的部署。怎么把這種能力更好的開放出來，而不是說需要每個開發商投入很大的精力做到多點分布，信息同步等一定要求的設計。怎么梳理內部的網絡？

我記得當年我們做農場，要在兩三個月內，從幾十臺的服務器，擴展到幾千臺的服務器，短時間內的擴容，就算我們想怎么去坎服務器，安裝五千臺服務器的規模，對于很多開發商是一個大的、高的要求。同時在增加設備的過程中，我們自己的網絡是分布在不同的城市，有不同的機房。一開始設備在增長的過程中，不同的IDC里面找資源，先把壓力頂住，再逐步優化，后來發現這種過于分散的設備資源，對于外網的壓力也非常高。導致我們后來發現非常頻繁訪問、數據量不多、次數很多，高峰期每秒幾十萬次的請求，怎么樣讓內網架構支撐數據流量，也花了很多的工夫和工作。

我們發現要真正做好一個開放平臺，要了解開發商有什么需求？不僅僅把API開放出來就完事。我們發現真正要提供穩定的服務給到用戶，幫助開發商在海量用戶的情況下，怎么服務好大家，是一個非常巨大的系統工程，也是為什么我們在開放平臺的項目中，經常會說開放需要能力，也是這個原因。

怎么接觸用戶的場景，也是開發者的需要，提供安全穩定的環境，有一整套原來服務內部的云服務體系，也逐步開放出來，給到第三方的開發商使用，怎么建立很好的推廣營銷的渠道，逐步把精準的社交廣告服務提供出來，讓應用開發商接入平臺，有一整套機制定向找合適他們服務的用戶。當然，整個開放平臺是一個商業的合作，也需要可持續的商業模式，騰訊這么多年所積累的支付體系，Q幣支付體系，設計好分成規則讓大家從中獲得雙贏。我們在整個開放平臺的設計里面總結了五個非常重要的要點，我后面也會根據某個點展開，保證設計標準規范、確保規范的執行、保障數據的安全、設定資源分配規則、建立服務體系。

開放意味著標準、規范，有標準才能降低開發的門檻。歡迎大家自由常識，規范保障了用戶的利益，保持公平的競爭。原來這里有一句話叫“整個開放平臺最重要的意義是在于怎么讓業界的合作能夠開展起來共贏”，這是非常重要的環節。在很多其他的領域，手機、安卓作為開放的操作系統，還有傳統PC的產業鏈、API的標準，會看到很多行業內的開發商，就是基于這些標準能夠各自去發展，找到創新的機會。

怎么確保規范的執行？這非常重要，如果定了規范但不執行，等于沒有規范，而且用戶的利益、用戶的需求是最重要的，在我們來看，開放只是一個手段，不是一個目的。目的還是回歸到到底怎么提供用戶最好的服務，多元化的應用。所以在整個規范的執行上，要充分考慮用戶的利益，而且要保持整個生態上多個應用有一個公平競爭的環境，怎么提供運營數據的監控能夠讓我們極早發現應用運營商所出現的問題，以及告訴開發商及時去修正，這些都是怎么確保規范執行需要投入很多精力的地方。

保障數據安全，保障用戶的利益。怎么確保用戶的隱私得到保障？原來我們做開放的時候，經常遇到媒體的挑戰，要怎樣開放才算是真開放？其實這是非常片面的看法，剛才也提到，最重要其實是用戶需要什么，或者用戶在于什么？原來QQ的關系鏈是基于用戶聊天的場景，有很強的保護，是不公開的信息，連好友都不能知道，我的QQ關系鏈里面有誰、什么人。如果我們隨意的把用戶這么重視、有這么高隱私性的信息公開出來給到第三方任意去用，這是會帶來不可想象的后果。所以在整個過程中我們非常敏感、也非常有意識的怎么確保用戶的隱私、確保用戶的數據不要丟失。剛才提到的防外掛、防垃圾廣告，都是最終在確保用戶的體驗。

設定資源分配的規則。前一陣子，在我們行業內，有一個電商平臺的公司，出了比較多的媒體負面報道，也是圍繞在資源分配上管理的問題。在開放平臺內有大量的資源，這些資源往往都會給開發商帶來巨大的利益，怎樣去設計一套自動化的系統去分配，而不是依靠人工的干擾，這是非常重要的一個話題，等于我們的操作系統。難道每一個進程用什么資源都必須要運維人員主動設置，不停去調整才能達到最好的效果或者最高的效率嗎？不是。我們建立的生態是完整的生態，必須能夠調動開發商的積極性，而且給有能力開發商獲得更好、更低的資源，才能把生態體系做得最好，有效率的發揮這些資源使用。

所以，怎么去設計一套沒有太多人工干擾、人工運營的資源分配體系，也是我們做系統設計經常要考慮的地方，怎么去避免資源被壟斷？在開放平臺，當你有好的應用或者成功的應用，獲取了大量的用戶，是不是代表了開發商做下一款的應用是不是有同樣的質量？很難說。我們不想因為一款應用的成功而變成為某一家開發商拿一些資源去導入其他的應用，甚至說把這些資源，少量的開發商壟斷起來。這樣對于創業者，對于中小開發商創新的機會有一定的影響。所以，在整個開放平臺的設計理念，不管是分成的體系還是其他，絕對往中小企業傾斜。其實跟操作系統的資源分配理念有一定的類似，怎么避免本身相對比較輕的應用，需要資源的時候用上，而不是被一兩個跑偏的把所有資源占用住，這里也有很多可以借鑒的地方。

資源成本的透明，怎么避免濫用。在早期做開放平臺的時候，內部對于系統設備的使用成本計算還沒有很好的體系，早期我們把這些成本都算到收入分成的體系里面。導致開發者對于資源的使用效率不太敏感。反正我能賺多少都是按分成比例計算的，用多少資源都是騰訊來承擔的成本。所以導致系統資源的使用效率偏低，而且效率偏低不僅僅是浪費，甚至很多時候是影響性能、影響了用戶體驗。所以，我們后來更清晰地意識到必須要把P跟L兩部分成本，成本和收入的部分能夠區分開，把這些資源的成本，不管是推廣的資源也好、設備資源也好、帶寬資源也好，透明到開發商，讓他們清楚不僅僅要充分的挖掘收入的部分，同時也要考慮怎么在成本的部分有更好的一個平衡。這樣就會讓騰訊有限地系統資源更好、更有效率的提供到各個開發商以及創業者都一樣得到公平的機會。

建立一套服務體系，說白了就是怎么幫開發者成功？我們有各種各樣的培訓文檔、系統，幫助開發者監控整套應用服務的運營體系，甚至還有推廣。在PC年代我們做windows的應用都需要輔助開發商能夠更有效率的開發這個應用。但是在開放平臺，我們不僅僅是載幫助開發商去做軟件，更重要的是提供服務，在互聯網時代，服務是更直接能夠接觸到用戶，是一個全方位體驗的服務體系。怎么提供服務的twos（音）？需要一整套的服務體系，也是我們幫助開發商成功的工具。當然，開發商在這個開放平臺上，不僅僅建立應用，接受穩定的服務，還需要推廣營銷的資源才能幫他們達到成功。

廣告體系，怎么應用好友之間的傳播，來幫助開發商的傳播，把推廣的ROI繼續放大。我們看到很多不同的應用，比如說QQ農場，它的成功并不是到處打廣告，而是很多通過自己邀請好友來玩，通過原來的騰訊所擁有的通訊體系、通知體系來初達用戶，這是零成本的。怎么建立應用，可以在服務體系協助開發商成功的一個非常重要的內容。

我們其實是希望能夠通過開放平臺，建立一個健康的行業合作的生態鏈，而給到用戶多元化的應用，能夠給到廣大的QQ用戶有更多的選擇。

當然，怎么維持一種長期持續的服務，這里有必須要有一個商業模式的支持。早期看到的、現在看到的很多游戲，有一個比較明確的商業模式，已經在開放平臺上獲得非常好的成績。但同時下一步要想的是怎么幫非游戲類的應用找到它的商業模式。比如電商，如果通過這個開放平臺帶動電商的銷售，相信很多的電商服務也很愿意給重點的應用分享收入，所以騰訊會針對不同的垂直領域思考，怎么為不同的垂直領域建立健康的商業模式。優秀可能跑得通，有些跑不通，我們無法逆轉原來跑不通的服務在開放平臺上一定能通。這也是跟開發商、跟業界一起探索的機會。怎么提高用戶的能力，提升ROI，數據驅動自主優化，怎么讓數據成為一個開發商各自能夠使用的工具來不斷完善他們的服務。

騰訊一個角色來承擔這么多開發商的優化以及改善服務的工作，所以最有效的是給到大家最詳細的數據，在不同環節不管是流程率還是營銷的效率等各個方面來幫助開發商意識到在服務運營商的一些問題。

我在騰訊有一段時間抓研發質量、性能問題的工作比較多。當時有些產品比較慢，找團隊開發的同事溝通這個問題。開發人員可能說因為某一段時間抖動，沒關系，就把我打發掉了。我當時也在思考，怎么把團隊里面這么多的開發人員對于性能、對于服務穩定的關注調動起來，后來發現最有效的方法就是拿數據說話，建立整套的體系，讓全天每一個時間的性能、接口都受到監控，而且到了第二天的早上把每個接口有超過1%的請求，超過某個指標的話，會標紅，發一個郵件會看到，甚至開發人員跟負責的KPI綁定，有標紅在上面自然意識到需要重視而且要持續關注的地方，不再需要有人去找某個開發說，你看看到底是什么問題，開發可能說已經重構了某個部分，放心已經搞定了。不再是單點的處理工作。

對于開放平臺整個服務體系的建設也一樣，希望提供最完善的數據，能夠驅動大家發現問題優化服務。

在整個開放平臺的設計上，我們考慮很多跟做系統設計有很多類似的地方。簡單說一下騰訊開放平臺的成績，我們有大概六萬個已經上線注冊的應用，多家月分成超過一千萬，甚至超過兩千萬的，在服務體系里面看到各種各樣的嘗試，有些讓我們非常高興地看到很多非常創新的應用，非常公益的應用，有學車考試的應用。這個體系給開發商新的機會創造了很多成功的創業者，后面我們也希望發展很多非游戲的應用。今天開發商遇到的挑戰很大程度是在于怎么從非常成功的游戲垂直領域擴散到更多的應用，這是今天騰訊開放平臺團隊不斷思考到底要怎樣調整規則，不管是商業模式分成的規則，或者本身應用的能做什么、不能做什么，這些都有挺多的考慮和溝通。

最后，我用馬化騰先生曾經在騰訊開放平臺啟動的時候說過一句話結束：“騰訊過去一直在思考提供在線一體化的服務給到用戶做最好的體驗，但今天我們發現僅僅騰訊的一個力量是不足的，所以我們希望能夠建立一個完善的行業生態鏈，歡迎眾多的開發商跟我們一起提供最好的用戶體驗，能夠在原來關注怎么種一棵樹到現在關注怎么尋找整個生態，培養出一片非常茂盛的樹林”。

希望開放平臺跟大家一起成長，謝謝大家！

 

大家有沒有什么提問，可以提問。

【主持人】很感謝您的分享，我感覺剛才分享的不但適用于騰訊的平臺，基本上所有開放平臺點都靠上了。要做很好的平臺要做到PPT里面列的點。我比較感興趣的是騰訊做開放平臺的時候有沒有像facebook、百度等做過一些比較，或者騰訊開放平臺不同的點在哪里？

還有一個問題是，騰訊的開放平臺的目的是復制的路還是走另外一條不同的道路呢？

【湯道生】騰訊的開放平臺對外公布相對來說比較晚的，外面Facebook也好、ipad也好，他們開放平臺已經跑了一段時間，思考過程中肯定有借鑒其他開放平臺的做法，同時我們也清楚國內的產業畢竟跟產業鏈、行業的發展，跟國外的行業發展不太一樣。所以我們在整個開放平臺的設計，有很多針對本地情況的考慮，盡量避免看到在其他平臺所出現的問題。

剛才我提到在整個分成策略、服務體系構建細節上的考慮，很大程度去傾斜于中小的創業者，確保少的應用開發商分到分成比例，比大的應用更高。比如說在十萬以下月分成的收入，扣掉基本的渠道成本，100%是給到小應用開發商。在其他的開放平臺，一般是統一的分成比例，有意的希望培育小的開發商應用，有一個更好的生存環境和發展的支持。

另一方面，我們是全球最多互聯網用戶的國家，而且這些用戶集再一個時區，代表用戶給系統壓力。成功做出一款非常受歡迎的游戲時，國內互聯網產業的發展相對其他國家還是比較短，我們架構師能力的積累，很多創業者  剛大學畢業已經去嘗試，他們這方面系統架構的經驗相對來說沒這么豐富。我們考慮一整套的體系，如果開發商需要云服務，我們也提供這種云服務基礎的能力，充分去利用騰訊已有的多個城市的IDC接入點，伸縮性很強的資源支撐或者多年內部的監控體系、運營體系、性能監控、設備資源使用情況監控都要開放出來。這些所考慮的點跟面往往要比其他的開放平臺更多。這應該是騰訊開放平臺和其他平臺的區別。

【主持人】由于時間的關系，用更加有效的方式，通過騰訊微博進行交流。騰訊微博“會飛的魚”提了一個問題，你認為最大的難點是在架構設計里面嗎？

【湯道生】最大的難點是深度認識用戶需求點在哪里？滿足這些需求資源瓶頸在哪？往往一個成功的架構師對于產品的需要、用戶的需要充分理解。同時對用戶的行為充分理解。這樣才能準確的判斷在你手上各種資源中哪方面最可能成為你的瓶頸。所以在架構設計里面會特別去照顧到不要讓可能成為瓶頸的資源有一個重組的儲備。

【主持人】請湯總對國內幾大開放平臺都有那些各自鮮明的特點？可以做一個點評。

【湯道生】國內幾大平臺側重點都不一樣，是平臺的建設應用平臺所習慣、所期待的服務，對于不同的開放平臺有不同的要求。比如百度更傾向怎么結合搜索，通過流量的入口來帶動它的應用體系。在阿里系的淘寶也好或者相關電商平臺，它們整個生態平臺更側重于服務好電商的賣家。我想不同的開放平臺都有它的發展方向。

【主持人】騰訊如何思考開放平臺戰略的？這是一個比較艱難的決定，還是水到渠成的需要，背后的動因是什么？

【湯道生】這不是一個艱難的決定，產品發展到某一個階段，開放是必然的。之前在其他的演講里面有看產品發展的過程，首先抓某一個功能需求點的產品，發現用戶喜歡這個產品，會逐步豐富產品變成多功能的產品。然后發現自己產品的領域已經不足以滿足用戶更多的需求，你會拓展到其他的功能點上，讓你需要合作，就會找一些合作伙伴。從產品發展成為平臺。

當用戶非常頻繁使用你的平臺，能夠滿足更多的需求，自身少量的合作伙伴不能滿足自然就要開放，能夠調動更大行業有能力的人來參與這樣一個平臺的建設。一步步發展，我覺得開放是一個必然的過程，但是在內部也艱難的部分，畢竟騰訊原來也有很多應用的開發，轉型的過程怎么去做內部協調。怎么在公司內部上下游一個統一的認識，花了不少的工作去做這個轉型。

【主持人】由于時間的關系，湯道生的演講到此結束！

#p#

 

【主持人】接下來讓我們用熱烈的掌聲有請王宏！

【主持人（王宏）】接下來請四位嘉賓：

騰訊高級副總裁湯道生；

去哪兒CTO吳永強；

百度技術委員會主席廖若雪；

土豆網產品技術副總裁黃冬。

 

第一個問題在社區中討論非常多、非常熱烈，回答各種各樣。這個問題是你們現在還寫代碼嗎？

【廖若雪】還寫一些。

【黃冬】個人愛好，寫點。

【主持人（王宏）】你們覺得架構師這個角色應該寫代碼嗎？

【廖若雪】我覺得需要。架構師如果不是持續寫代碼、不是持續對技術的東西做一些了解，知識會過時，會形成錯誤的概念、錯誤的方法論證。

【黃冬】我覺得必須寫，而且更重要的是要看一些代碼，理解他們怎么工作或者怎么做一些事情，這樣才能真正理解自己架構的特性和應用是不是正確的。

【主持人（王宏）】從兩位的回答中，架構師到一定級別，可能沒有那么多時間寫代碼，但是一定要完成的是對自己系統了解、對底層深入的了解，這樣在系統運營中有一些情況和問題能夠快速解決這些問題，這是架構師最基本的能力。

架構師你覺得應該有什么樣的最基本能力？

【湯道生】對于數據的敏感。不管寫不寫代碼，看代碼一定要的，很多時候架構一定是框架，框架里面填什么內容、細節怎么實現，其實是非常重要的。但是作為一個架構師，時間分配很多時候經常要了解細節，而且要做出判斷，細節的體現很多時候不一定通過代碼，需要更客觀地去看一些數據，而且要考慮架構不僅僅是程序的架構，可以是網絡的架構，可以是設備資源的獨特性所帶來的對于應用有不同的要求。最終我覺得是要深度了解整個服務體系在關鍵點上的數據表現充分的抓取分析，這是作為一個架構師非常重要的數據。

【吳永強】我覺得架構師第一步還是思維能力，重要的難題是鑒定問題。如果問題不清楚，之后所做的工作都是錯的。

第二，基本方法論，需要抽象和簡化，比較難，怎么樣把抽象的問題變成簡單的問題。

【主持人（王宏）】從幾位回答過程中不難看出，架構師要有敏銳的觀察力，對系統各個點到面上升到框架結構，之后不同的發展才有不同的路線問題。

這些基本素質以外相對已經做到CTO的級別，怎么樣發覺一位好的架構師，看到閃亮點，放到合適的問題，這是很多架構師需要了解怎么看人的。

【黃冬】這個問題問的很尖銳，我覺得有幾點很重要：

第一，如果好的架構師，應該在代碼的編寫，業務的理解、整個系統的運行以及運行之后整個項目的運營商要充分了解。所以一個好的架構師的基礎是在四種工作上有多的經驗。如果沒有這個基礎要素，做事情的時候有些判斷更多是奪來品，不是自己思考的。

第二，要有敏銳的觀察力，在這四種工作上或多或少產生好的抽象、好的運行結果。架構師還有一個特性，當一件事情難以解決的時候，承擔起一個責任，一個判斷、觀察，并且勇于承擔責任，產生好結果的循環要發現。有了基礎的經驗、素質外加一些特別事情的表現，是我認為有基礎成為架構師的一個判斷。當然，還有一個重要的話題是，也許在某一點上有了亮點之后，需要給它在另外幾個層面一些培養的機會。我曾經讓一個架構師從做開發到學習網絡和面對整個系統的運營到業務層面，花了將近四年的時間逐一去經歷，慢慢去成長。

【廖若雪】我再補充兩點：第一，基礎能力和學習能力。尤其是后期，很難說是去花很多精力補充非常基礎的弱點。成功的架構師在自己相關領域的基礎能力比較強。學習能力，怎么把握新知識要點的地方。

第二，架構師面臨的問題和所有資源都非常清晰的了解。我們常說，這個事情是不是能夠說清楚，說清楚說起來很簡單，但是對很多問題的細節、方方面面，抓住問題的關鍵點都需要提出很高的要求，是不是能夠在別人問你問題的時候，尤其是你看到問題，后續怎么補充、補足，使得認識加深，找到資源分配，給到方案。

第三，對于架構師來說，應該有一些追求。追求就是對架構上面的一種簡單或者美的追求。不是把這事做完了能夠滿足目標就OK了，希望能夠做出更好的東西，更美、更簡單的東西。這是我的幾點感受。

【吳永強】我只補充一點，我覺得架構上有一個很重要的是能不能應對變化。互聯網公司大公司比較穩定，小公司變化非常多，而且系統的性能跟著流量、業務的復雜度發生變化，有沒有辦法自己突破設定很多結構性的東西，否則沒辦法跟上公司的發展。

【湯道生】幾位專家把要點都說了，我非常認同學習能力很重要。架構師放在不同場景、不同領域能夠很快速的抓到關鍵點，學習到新的領域，是一個基本的數值。如果在這樣的基礎下有機會在不同的崗位提煉一些經驗、沉淀一些經驗。在開發、運營、網絡各個方面有機會積累的話，這個人的視野、看問題的廣度會有一個更好的基礎。

對于用戶需求的了解，架構師的“架構”只是一個命詞，是一個手段。架構是用來解決問題的，反過來說是解決問題的能力。我們看到有不少的架構師或者技術人員發展到一定的階段遇到的瓶頸，是手上架構的能力，對于實際要解決的問題、目的有點遠，脫離了。最后不理解用戶的需求，或者不夠充分的掌握服務要達到什么目的。很難通過架構的設計達到好的結果，我覺得這一點是一個架構師在個人發展過程不斷提升的地方。

【主持人（王宏）】聽了幾位對架構師的要求做一個總結，架構師發展而來多數是程序員，以前在做程序員的時候做得是某一個點、某一塊的功能開發，要上升到一個前瞻性、系統化。還有一個，一定要有遠瞻性。

幾位都提到一定要了解系統運營中實際的一些問題，要落地、接地氣，不單單在技術層面上探討所謂的深度、復雜性就可以了，一定要了解到自己系統運營的特色，這一點蠻有意思的。

【湯道生】落地就是通過不同的崗位上解決、提問題，剛才大家都有提到。

【吳永強】軟件就是為了解決問題，不解決問題就沒有價值，每個工程師都應該有這個概念。

【主持人（王宏）】原來我是作為工程，需求很明確，各方面需求來自設計部門、產品部門、運營部門，跟他們的需求很近。做到架構出現一個問題，我的需求太多、太遠，導致試點上有些段，朝著某些方面深入下去，開始脫離了基本的業務需求，脫離業務線。若雪深有體會。

【廖若雪】我們做架構要解決實際問題，不是解決漂亮的問題。我們需求分析能力非常重要，如何才能把需求看東西，給出一個方案。這里有一個問題有一點感受。很多人說需求看不清楚怎么辦。有時候需要根據實際情況，確實要看你的經驗。看不到問題的時候，看架構師本身的潛在性能。是不是能夠比別人看得更遠一點，這就是核心的問題。

【黃冬】我經歷過很多架構，單純從視頻網站的架構，自己經歷有三個，土豆網的視頻架構截然不同。反過來講，截然不同的架構由一個架構師設計出來的時候，一定受到很多的挑戰。一個優秀的架構師設計這個架構的時候，一定會遵從某一個甚至幾個最需要解決的業務需求。但是業務人員也罷、工程師也罷，會不斷的挑戰。一個好的架構師在設計之初就應該知道如何用一個（K英文）在特定的業務下達到最好。我比較郁悶的是一些架構師會說某某某是怎樣做的，我們也這樣做，但是一個真正有效的架構師，能夠有執行力的架構師，恰巧是把架構尖銳的問題解決好的同時，規避好架構在實際當中用法的問題。

我認為一個好架構的落地是非常艱辛的，整個系統運行過程中看到的數據，用巧妙的方法在不改變架構，不讓大量工作廢棄的情況下仍然運行良好。

【主持人（王宏）】作為架構師能夠把架構上升到美的程度。把架構做得簡單，所謂簡單是系統結構，思維是簡單的。新的系統上線要說服使用，成為一個成功的演說點。說難聽點是忽悠，忽悠要基本能力的。當別人提到一個問題，怎么解決他們提出的問題，深刻地考驗了一個架構師對系統每一個細節的了解。這里延伸出一個問題，作為一個架構師具備這么多的能力，到底在技術深度上做更多的發展，還是廣度上發展。我們要了解各種各樣的學科還是只是在一門。像騰訊、淘寶對數據庫的基本代碼很深入的研究下去，也有人做系統的。

【吳永強】我覺得這個東西跟學習一樣的，一個好的人或者比較成功的人一定具備特別好的能力，一個歸納、一個演繹，可以把兩點結合起來，廣度要有，但是要學會歸納。深度也要有，要學會演繹。操作系統里面如果學的很深，基本上其他的軟件結構都能演繹出來。

我認為架構廣度和深度都要有。

【黃冬】首先，我認為一個架構師的出發點一定是足夠深的深度，如果沒有閃光點，沒有機會成為一個架構師。所以在一開始的時候一定有深度產生的，也許是一個非常好的DPA，也許是一個非常好的寫代碼的工程師，也許是對硬件非常精通或者對業務非常精通的人，一定非常深入擅長。但是當他的職業生涯走向架構師，必須放棄往下鉆，一定足夠廣，可以把自己的深度當成業務愛好，不能當成自己的工作。

作為一個好的架構一定是所有的層面都能有所了解，才能綜合和抽象，我覺得是分前后期。

【吳永強】我覺得即使做了架構師以后應該在深度上繼續深。

【黃冬】所以說是愛好。

【吳永強】我覺得跟愛好無關，是工作上的問題。

【廖若雪】如果不加深深度，廣度做不上去，反過來也是一樣的。很多是融會貫通的。融會貫通的時候，會發現深度和廣度可以轉換的。

【黃冬】如果這么講，他的深度積累是積累下來的，正是因為有廣度才轉換的。深度是一個愛好，廣度發揮大的價值。

【湯道生】這兩個是相互幫助的。在某個地方可以轉深，解決大的問題只有一個領域的知識不夠，自然多方面的了解才能解決。單項考慮廣度和深度兩者是疊加的。很多時候有一個誤區，不是說所有的語言都學一遍就很狂，這不是廣度，只是在解決問題上面需要用到的工具。所以我覺得真正廣度的體現，還是在于解決問題的時候是否考慮足夠全面。甚至說，剛才主持人提到程序員原來很明確給我一堆需求，怎么按照這個需求實現就好了，我覺得那個時候也許離目標稍微遠的時候，雖然感覺很明確，因為有人幫你過濾了怎么做，而不是真正了解，到底服務業務用戶需要什么，視頻服務商用戶需要流暢、不卡一堆的要求，但經過很多重的翻譯下來到一個開發人員的需求可能是播放器加一個斷點重播或者其他的功能。這對于你實際的問題理解不足，可以說這是一個很缺乏對于廣度在每一層所需要考慮的問題的廣泛了解。

還是要端到端，中間的事情有設備的關系、網絡的關系，甚至用戶體驗的關系，把這些都打通，才是一個架構師所需要的廣度。

【主持人（王宏）】這個問題下面有很多人也有不同的想法。再討論下去有各種各樣的想法，稍微有一個暫停。

架構師雖然是統稱，架構師有分類嗎？

【黃冬】我覺得架構師在我所看到的層面，橫向有幾個不同層面：

第一，好的代碼。現在知道很多好的框架，本身就是一個良好的架構。在代碼、工程師的層面也是有架構設計和一些良好的架構，我們可以看到。

第二，結合整個系統的運行，會不會有良好的架構。比如（英文）結合系統資源、結合計算機處理能力。

第三，產品。如何給用戶提供好的服務。

再往上走甚至可以提升到產業鏈、行業、商業模式的架構。比如說騰訊的開放平臺，截然不同的架構，解決什么樣的問題、該不該這樣做。

縱向走的話，我認識幾個非常資深的信息架構，只是做信息分類，有一個圖片做圖片庫，怎么給圖片建立一套體系結構，管這個人叫首席信息架構設計師。包括圖書館的分類也是截然不同的，信息架構是截然不同的東西，還包括硬件的架構，真的體現不同的行業不同的職位。

【主持人（王宏）】若雪是技術委員會的主席，看過很多架構師，怎么看？

【廖若雪】這里有一個核心的問題，定義什么是架構師。從能力上講，很多架構師很像，他們的側重點、相對的領域或者在架構層面上解決問題的思路和方法都有不同的地方。

從計算機領域來看，架構師從分類來看并不是很好的緯度，更多的是側重點。側重點是不是分成幾類，在我看來并不是這樣的，他們之間可以看到很好的作為策略的架構師。他們能力可以轉換的。

【主持人（王宏）】這個問題只是跟上面一個進行呼應。在我看來，架構師的基礎能力，最基礎的算法，數據與數據結構、網絡、TCB的東西，反而是架構師最根本、最需要掌握的知識，之后對這個知識進行總結、歸納，上升到高度之后看到全面才能有一定的深入了解。還要有一定的遠瞻性，對公司未來的發展方向都要了解。

接下來把時間交給大家。

【提問】剛才談了很多架構師優秀的地方，我比較關心的，比如說我是一個工程，定了這樣的方向，如何培養自己的能力？如何一點點向這個方向走？架構師有一個機會的成分給你，公司給你環境，如何尋找這樣的環境和抓住這個機會。

【黃冬】捉所以說橫向和縱向都有不同領域，現在作為一名工程師，最需要做的事情就是仔細去琢磨討論的代碼。

什么叫架構？我自己是這么認為的，一個能夠隨著時間的變化和業務的變化不去發生改變的穩定的結構，稱之為架構。一個架構師一定是對這樣的東西加以設計、靈活運用，讓這樣的結構不輕易改變，能夠持久運行做這樣的設計來。

如果自己是一個程序員，每切到一個需求時，往前往左右想一步，看自己的代碼能夠運行多久，業務和時間的變化都不會產生影響。越能多寫這樣的代碼，就證明在培養這樣的能力。

第二，當自己所做出來東西越來越多的時候，看深度上能不能再深一些的同時，看自己能不能再做一些截然不同的東西。包括系統、運營的東西。

最后，有沒有一個公司、環境多理解業務，能夠讓自己運用網絡、系統代碼和業務自己所設計的東西進行運行。這是一個聽起來很漫長的過程，是一個有心人自己培養自己的過程。

【主持人（王宏）】這個問題挺有意思，架構的正面講了，可以聊一聊架構的反面。架構的反面講一天一夜都講不完，失敗是成功之母。

【提問】架構師和軟件開發主管有時候意見不一致，架構師做交流的時候還是挺困難的。架構師成為獨立的架構師也是一個發展方向。對于自己要不要成為軟件開發主管兼架構師，還是獨立的架構師？發展方向方面有什么建議？

【湯道生】這是管理問題，不是架構的問題了。程序經理也好、項目經理也好、架構師也好，純粹說哪個級別或者哪個職位，太不科學了。我原來在不同崗位扮演過不同角色，最健康的合作方式還是拿數據說話，或者對于實際用戶的行為能夠有好的判斷，真的能講通為什么這個好、為什么不好。為什么這個階段好，等到下一個階段采取另外一個策略。

我記得有一次我們團隊在討論一個face的問題，300個好友怎么更新，300人不同的好友，看到的視圖不一樣。到底存儲系統應該怎么設計才合理？有程序經理說，facebook是這樣做，把更新發到一個存儲來做。架構師說看著別人很穩定的，只是一個系統的設計，不一定是最優的。我們去分析到底用戶的行為是怎樣的？或者最終存儲放什么在內存、放什么在硬盤。放在內存的信息最好是少量而且是不變的。最后想了另外一種方式，把個人的更新落地到存儲，但是能夠被內存存起來。這樣的話只有更新的人落地，后來發現架構師通過實際用戶的行為、實際的資源（英文）更準確的判斷，用更少的IO，充分利用內存的特征來解決這個問題。最后我們發現我們的設計是跟原來facebook開源的不一樣，但是實際的結果更符合我們的需求。那個人抓住重點，充分理解系統資源，最后按照數據來決定。

【主持人（王宏）】架構師到底需不需要具備人員管理能力？

【黃冬】手里沒槍怎么能搶得了政權呢？

【廖若雪】跟各個公司的風格和管理相關的，可以不要。

【吳永強】管理層面太虛幻了，是實際的管理還是對人影響力。

【主持人（王宏）】隨便你定義。

【吳永強】那就很廣了。

【湯道生】如果你有能力，自然會得到。

【提問】性格決定命運，現在又提倡情商比智商更重要。性格方面有什么地方能夠比較適合做架構師？

【湯道生】兩個都要。

【吳永強】智商是必須的，智商如果高到一定程度，情商可以不要了。

【廖若雪】智商是一個必要條件。情商會更加有助于你成功，任何事情都是這樣的，不光是做架構師。

【黃冬】我認為做架構師的特點就是智商一定要高，作為一個公司的管理必須情商高。

【主持人（王宏）】一個小時很快就過去了，聊到后面越來越盡興，由于時間關系到此結束，非常謝謝大家！