以下為2012年全球架構師峰會ArchSummit第二天早上的文字實錄。

【主持人】大家早上好！我叫鄭柯，今天上午有三個主題演講：

第一，Pinterest的架構衍變過程。

第二，網(wǎng)絡架構疑難雜癥解析。

第三，郁悶的架構師。

第一，Pinterest是繼Facebook之后成長最快的社交平臺，兩位講師Marty Weiner、Evrhet Milam都是Pinterest的工程師，在Pinterest整個架構里面起到很大的作用，有相應的體驗教訓分享，跟大家分享現(xiàn)在遇到的問題以及未來的規(guī)劃。

第二，由ChinaNetCloud創(chuàng)始人兼CEO、CTO，Steve Mushero帶來的疑難雜癥解析。現(xiàn)在中國網(wǎng)絡環(huán)境在硬件基礎設施層面上某些方面可能是退步了，Steve Mushero給我們講一講有哪些問題可以解決，做好不同的規(guī)劃。包括不同的地區(qū)怎么做、不同行業(yè)的特點需求不一樣、單線多線的接入也是談到的東西。還有怎么利用國外的服務做國內(nèi)的網(wǎng)站。

第三，Simon Brown是獨立的軟件工程師，創(chuàng)了Coding the Architecture，標題是郁悶的架構師，更多從思維方式的角度講，作為一個架構師是怎樣的要求或者應該怎么思考問題。他的要點，架構師需不需要敏捷起來呢？浮現(xiàn)式設計的真正意義是什么？做軟件有什么意義？這些意義對世界賴講會怎樣？

今天下午有三場專題，第一個是海量數(shù)據(jù)之快準狠，主持人友友天宇COO張矩，接下來由張矩來跟大家介紹！

【張矩】大概在一個月以前我看到了一個非常震驚的地圖，最近160年以來所有地震分布的圖，用點的顏色和大小表示地震的強度以及造成的破壞的程度。當這張地圖呈現(xiàn)在你面前的時候，你會非常清晰地看得出來，地震的分布和地球地塊的形狀有非常高的吻合程度，毋庸置疑證明了絕大多數(shù)地震的發(fā)生由地殼運動沖撞導致的。有時候有很多的規(guī)律和研究的成果，通過數(shù)據(jù)的量很清晰的呈現(xiàn)出來。

大數(shù)據(jù)的課題大家不陌生，而且聽說過很多次，大數(shù)據(jù)從數(shù)據(jù)產(chǎn)生的量變到質(zhì)變，給大家?guī)韻湫碌膯栴}。計算機科學在大數(shù)據(jù)量成長到一定程度后變成一個全新的領域。

今天下午請到了業(yè)內(nèi)非常前沿的四位從業(yè)者為大家介紹關于大數(shù)據(jù)存儲處理上嶄新的思路，相信會給大家?guī)砗芏嗟捏@喜。

我覺得大數(shù)據(jù)這件事，可能在一定程度上是技術上的挑戰(zhàn)，我更希望看到、更相信大數(shù)據(jù)的發(fā)展為各個行業(yè)打開一扇更高更多的可能性。相信在座的很多都是大數(shù)據(jù)從業(yè)者，堅信我們的工作有一天對整個社會有非常大的推動作用。有可能利用數(shù)據(jù)的量發(fā)現(xiàn)現(xiàn)在不能治愈疾病的治愈辦法，有可能更有效地避免經(jīng)濟危機或者戰(zhàn)爭。或者說沒有找到更好的辦法規(guī)劃星球的發(fā)展。正是這些可能性是促使大家在這么炎熱的季節(jié)跑到這么炎熱的城市參加這么熱門的討論。

下面我介紹一下今天下午四位演講者的情況。

第一，來自EMC研究院的陶雋，介紹MapReduce在數(shù)據(jù)處理的應用，深度分析如何處理好數(shù)據(jù)的使用。

第二，雅虎研究院的資深架構師韓軼平帶來的基于Hadoop的海量數(shù)據(jù)工作流平臺。

第三個是Linkedin高級工程師Lei Gao帶來的Linkedin的數(shù)據(jù)處理架構，從數(shù)據(jù)總線到消息系統(tǒng)到數(shù)據(jù)的剖析。

最后壓軸的是Pinterest著名社交網(wǎng)站中的工程師，Marty Weiner、Evrhet Milam，他們介紹對于數(shù)據(jù)庫的使用，以及大數(shù)據(jù)下分片如何做到的。

希望大家踴躍參加，下午見！

【主持人】今天下午第二個專題是移動互聯(lián)網(wǎng)的案例分享，主持人是騰訊手機游覽器后臺開發(fā)組總監(jiān)張凱。

【張凱】各位嘉賓、各位朋友、各位行業(yè)內(nèi)的技術牛牛們，大家早上好！剛才上一個主持人說了，非常炎熱的城市，歡迎大家到深圳來，我是騰訊無線游覽器傳輸?shù)募夹g總監(jiān)張凱，加入騰訊已經(jīng)有8年時間了，不光看到了移動互聯(lián)網(wǎng)從2G到3G，甚至到3.5G、4G的發(fā)展，同樣也看到了在整個行業(yè)的發(fā)展過程中，全國各地很多的團隊、很多的架構師們一起在風生水起的行業(yè)里拼搏。如果傳統(tǒng)行業(yè)30年河東、30年河西，在移動互聯(lián)網(wǎng)行業(yè)就是三年河東、三年河西。這幾年看到了安卓的新生、蘋果的崛起，也看到了諾基亞的沒落。在這樣一個行業(yè)里會有非常多的機會和挑戰(zhàn)。記得09年1月份3G牌照正式發(fā)放。從09年4月份，IT時代周刊有一句話說下一座金礦是移動互聯(lián)網(wǎng)。09年到現(xiàn)在3年半的時間，3年半的時間行業(yè)發(fā)生了哪些變化，有哪些歷程。今天非常有幸邀請到四位架構師做分享：

第一個是大眾點評網(wǎng)應用架構師屠毅敏。

第二位是由我來給大家分享一下手機QQ瀏覽器X架構的歷程和演變。

第三位是網(wǎng)易杭州研究院的高級工程師李武先生分享網(wǎng)易移動應用的架構。

最后，由東軟集團UniSDP首席架構師、產(chǎn)品運營經(jīng)理孫廣宇為大家分享HTML5的技術以及基于HTML5構建統(tǒng)一的智能設備應用平臺。

我們在一號分會場不見不散。

【主持人】第三個專題是系統(tǒng)安全設計面面觀，主持人是殷鈞鈞。

【殷鈞鈞】架構師們在做架構權取舍的時候，安全性是一個非常讓人感到頭疼的問題，非常不好的量化，現(xiàn)實中變化非常多，種類非常多，新技術層出不窮，傳統(tǒng)的管理方式很難做一個量化。今天下午邀請到兩位非常資深的兩位安全架構師以及非常資深的黑客。一方面如何滿足系統(tǒng)的要求，另一方面如何更好的面對安全威脅，這兩個角度做一些分享。下面介紹一下今天下午的演講嘉賓和主題。

第一位，Coding the Architecture的創(chuàng)始人Simon Brown，演講的題目是“如何設計安全的架構”，分享過往的架構里面會有怎樣的安全考量，面對不同的場景怎么做安全威脅的分析，更好實現(xiàn)安全的架構。

第二位，來自于支付寶團隊的苗霖，支付寶要求非常高的線上系統(tǒng)，大家非常好奇如何在設計里面更好保障架構權衡和演變過程中確保安全性。今天下午跟大家分享支付寶的安全交易架構。

第三位，非常有藝術家氣質(zhì)的方小頓，是黑客組織80sec創(chuàng)始人、wooyun漏洞報告平臺創(chuàng)始人，江湖人稱劍心，今天下午分享的淺談甲方安全建構建設之道，分享在某著名的互聯(lián)網(wǎng)企業(yè)如何推行他的架構措施的血和淚，有非常多的干貨和亮點。

第四位，方興，是南京瀚海源CEO和創(chuàng)始人，方總的名字年輕一點不太熟悉，往回推個N年在黑客里面鼎鼎大名。方總是獨立發(fā)現(xiàn)高危級別發(fā)現(xiàn)漏洞最多的一個，微軟聘去當顧問，現(xiàn)在為很多一線的互聯(lián)網(wǎng)廠商提供安全資源和服務。今天下午的演講是“基于安全漏洞的攻防對抗技術”，講很多現(xiàn)實的東西，出現(xiàn)問題的案例，同時談到了現(xiàn)在最流行的威脅攻擊的方式。

更多干貨、更多分享，盡在安全架構專場！安全架構專場，喜歡您來，喜歡您再來！

【主持人】10月份的QCon已經(jīng)組織了，邀請了谷歌、Facebook工程師過來，歡迎關注，今天上午首先帶來的演講是Pinterest工程師Marty Weiner和Evrhet Milam，大家歡迎！

#p#

【Marty Weiner】大家好！我是Marty Weiner，Pinterest一年之內(nèi)游覽量達到非常驚人的數(shù)字，去年是比較年輕的公司，快速的增長，不知道用什么樣的技術講講戰(zhàn)略故事，有很多的選擇。Pinterest網(wǎng)上的貼圖板讓我們組織分享帶來靈感的圖片，現(xiàn)在看到的是我自己Pinterest的主頁，有一些畫板，可以貼圖。結合了圖形和照片，非常特別，不管在什么地方找到圖形，比如說一個產(chǎn)品很喜歡，追溯到哪里買的。為什么用戶覺得很特別，可以關注他們的畫板，關注的時候如果貼一張圖，也可以獲得這張圖。他們貼圖我們也會收到。

如果進入數(shù)據(jù)庫的模式，現(xiàn)在看到的是數(shù)據(jù)的結構，有一個用戶有畫板，可以貼圖，其他的用戶自己有自己的畫板，另外還有其他一些關系的方法，可以轉貼，表示喜歡他的貼圖。2011年5月剛剛推出這個網(wǎng)站，很多意義上來說，可以看到我們做了一些設計的功能，那個時候找RockSpace來托管，一個工程師就夠了，網(wǎng)站開發(fā)我們也不知道開發(fā)到哪個階段，保持靈活，不大量投資。2001年1月，我們的創(chuàng)始人說現(xiàn)在還是處于一個隱身模式，大家沒有聽過我們的名字。這時稍稍有一點知名度，我們用了Amazon，他們給我們做托管。接下來的的9個月已經(jīng)忘了睡覺是什么滋味了，加強建設，網(wǎng)站發(fā)展太快，每天翻倍，每天有各種失誤，我們要保障很多問題，很快問題一發(fā)不可收拾。

我們不想看這里有多少的東西，可以感受一下這里有多少的技術、多少復雜性，把PPT所示的技術結合在一起，都有自己微妙的工作方式，每天帶來各種頭疼、各種麻煩，有三名工程師處理惡夢，因為擴張?zhí)?，肯定有問題。我們第一個經(jīng)驗教訓是這個系統(tǒng)會有問題的，所以盡量保持簡單。

對未來的架構來說，一定要保障我們的架構，我們不想用一些太復雜的技術和方法，希望能夠讓過程變得簡單，比較容易去修改或者維修。

2012年的時候，我們架構不斷的演變，這時基本上已經(jīng)成形了，大量的簡化，用了66個MySQL的數(shù)據(jù)庫，這時已經(jīng)成形了，從這個模式上進行增長，不會有太多的問題。我們有MySQL和Memcache，有6名工程師，也做了分片的服務器。幾個月之后，比較接近今天的現(xiàn)狀，我們增加了一些設備，但是目前來說架構已經(jīng)從1月份以來成型固定了，有25名工程師。重點是擴大我們的團隊。

Amazon很好用，有很多周邊有很多工具幫助管理公司，不想管理也可以做緩存，幫助你做數(shù)據(jù)庫管理。也許在以后我們也可以讓Amazon來幫我們做周邊的管理。更重要的一點是如果要再做一此第三個原因用Amazon，因為幾秒鐘之內(nèi)生成一個實力，發(fā)展很快不知道用什么東西，5秒鐘形成一個新的實力。缺點是選擇比較少，可能就幾個設備，就這些選擇，比如說26G，那時買不了X60或者更快的選擇。但是選擇不多也是好處，不需要太多的動心，不需要挑亂眼。

MySQL也是系統(tǒng)的基石，一致的為我們帶來很好的表現(xiàn)，26年的歷史了，非常成熟，非常多人知道，很喜歡，工程師有自己的經(jīng)驗，我自己也做MySQL，我也經(jīng)常使用也做管理，很多人是這方面的專家，我也為MySQL編過碼，幾乎很少有大量數(shù)據(jù)缺失，這是硬件問題不是軟件問題，反應時間可以隨著請求率進行增長。有一定的技術到一定的量響應時間是掉下來了。但是MySQL可以隨著線性擴張的，對明天有所預見，而且社區(qū)非?；钴S，搜MySQL肯定有很多東西幫忙，很多公司給支持，而且MySQL是免費的。當然，作為一個小的網(wǎng)頁公司，當初的資金有限，用MySQL資金是一個解決條件。

Memcache非常成熟，功能表現(xiàn)非常好，而且很多人喜歡，也知道怎么用，很少有失效和崩潰的時候，而且失效模式非常少。因為比較簡單，沒有什么可以出錯的地方，還有一點非常好，免費，免費誰不喜歡呢？

Redis是新的公司，有自己的一些小玩意，有自己的復制和持續(xù)性，而且結構非常好，想進行分類、進行散列都有這個功能。很多功能都可以用得上，而且這還是比較新的公司，但是很多人都非常喜歡它。我在社區(qū)里面聽過很多人表示好評，也進行大量的使用。我們聽了好評聲去使用，表現(xiàn)非常好，有一定的失效模式，比MySQL稍微多一點，但至少還是可以的。另外，還是免費。

到底用集群還是分片，我們肯定要調(diào)整架構的，網(wǎng)站發(fā)展有太多的技術可以進行全自動化的調(diào)整。很多人說買了這個設備可以自動的進行分配，如果這個盒子壞了，另外一個盒子能夠備用。我們到底是不是真的想要集群呢？后來用分片，發(fā)現(xiàn)分片手動性強一點，集群和分片是非常多的選擇，對于集群來說，是自動化的數(shù)據(jù)，數(shù)據(jù)可以遷移的，可以重新分配裝載容量。另外一端是分片，是用手工進行數(shù)據(jù)的。換句話說，必須要用編碼，一定不是自動化的，這是一個決定。數(shù)據(jù)進入某個分片以后，基本上不再移動了。同時數(shù)據(jù)進行分解，數(shù)據(jù)一半放這個片，一半放那個片，每一片有更多的容量分配數(shù)據(jù)。而且結點之間不了解，不會互相溝通的。

所以，用集群有什么樣的好處，我列出了一些例子，比如說像集群的技術。比如說Cassandra、MemBase等可以自動擴展，非常容易設置，5分鐘就可以設置了?？梢钥臻g分配來，數(shù)據(jù)有非常高的可用性，均衡而且沒有單一的失效點。

如果一切美夢成真的話，什么事都不用干了，但是會有什么事出錯呢？如果什么都好的話為什么不用集群呢？做了幾年之后還是非常復雜的，而且比較復雜、歷史也不長，社區(qū)支持也比較少。沒有太多人推動這個技術，尋找?guī)椭鐓^(qū)對你的幫助非常有限，現(xiàn)在有這個知識的工程師為數(shù)不多。比如說我了解的Clustering的工程師不多。

有時候會覺得非常害怕，原來從0.8到0.3有一點步驟要做，做了又不一定會成功，運氣好做好，運氣不好突然會失效，我覺得比較不幸的是影響到我們好幾次的。首先看我們集群，所有東西都是綠色的，大家很開心，但是突然服務器不行了，一般來說找一個替代的服務器換上去，把所有的東西分到新的服務器。出現(xiàn)什么問題呢？看到里面的服務器每個都使用同樣的算法來計算，之前也是前期溝通的，希望服務器有問題和漏洞的話，所有的服務器都有問題，項目溝通的漏洞也會轉移到其他的服務器上。

你寫的一條比較復雜的代碼影響到所有的節(jié)點，出現(xiàn)的問題首先包括數(shù)據(jù)在均衡會失效。很多個盒子，把東西分到不同的盒子里，發(fā)現(xiàn)鏡頭80%停下來，只能取消。另外，所有的節(jié)點都有數(shù)據(jù)的損壞，托管層有漏洞的話會影響下面的成績。每個漏洞導致每個服務器出現(xiàn)數(shù)據(jù)損壞。另外，無法有效治愈的錯誤的平衡。不同的服務器加了90%的數(shù)據(jù)，剩下1%不到，怎么辦呢？可能需要一個技術手動進行分布。另外數(shù)據(jù)授權的失靈，其中有一個盒子可以說是主本，做一個副本，大概做了80%的時候副本才能決定到底數(shù)據(jù)從哪來的。副本拿80%的時候，其他覺得80%的副本是主服務器，把信息再拉進來，導致主服務器出現(xiàn)偏移，從而無法進行正確的傳輸。這些技術發(fā)展的時間比較短，現(xiàn)在有些問題讓人比較害怕。為什么要做分片的，分片是手動操作的，把數(shù)據(jù)庫分開來增加容量，可以在空間上進行分布，高可用性進行負載均衡。我們放置數(shù)據(jù)的算法非常簡單，寫下來之后有一天在進行測試，非常小的算法。我們用很簡單的機制來生成ID，下面有請我的搭檔Evrhet Milam講一講什么時候該做分片，怎么做分片。

【Evrhet Milam】首先，要做分片的話，板式設計、模式設計更加困難，要放對地方才行，等穩(wěn)定了才能分辨，等太久，轉移數(shù)據(jù)更困難。所以要選擇一個合適的時機，把你的數(shù)據(jù)從一個模式轉到另外一個模式。另外，在做分片的時候，設計靠得住的，就像我們有的用戶以及圖板、貼圖等。這就是我們網(wǎng)站的設計，網(wǎng)站設計先確定下來，還要確定后端的架構怎么樣。

下面所有的連接和復雜的查詢要取消掉?，F(xiàn)在很多連接非常麻煩，分片是獨立開的數(shù)據(jù)庫，加上復雜的查詢不行。加上緩存會好很多。讓分片發(fā)揮系統(tǒng)的功效。我們的數(shù)據(jù)庫、系統(tǒng)中有很多不同的貼圖，貼圖放到數(shù)據(jù)庫里面，讓不同的分片發(fā)揮功效。另外，如果你的網(wǎng)站不斷發(fā)展、不斷增長的話，最好用分片的技術。有些人網(wǎng)站到了一定技術，不用分片，如果量不斷增加，用分片比較好。

這是不斷遷移不斷發(fā)展的過程。

先是有一個服務器，有外件、有很多的連接，比如說有一個用戶通過連接和貼圖連接在一起，把數(shù)據(jù)進行非正規(guī)化做得更快一點。很多數(shù)據(jù)重復的，我們也做了很多的高速緩存。我們還有讀取的倉庫，再把數(shù)據(jù)分片，分成不同功能范圍的分片。比如說有一個分片里面專門放用戶信息，有些是專門放貼圖的，還有專門放客戶用戶的評論的。

我們當時比較早的采用分片來應對我們的數(shù)據(jù)，如果做得稍微遲一點的話，分片就比較困難了，畢竟有很多外件牽涉到其中。我們做了最后一個跨越，通過ID進行數(shù)據(jù)庫的分片。不同的數(shù)據(jù)庫能夠更好以一種水平的，而非垂直的方式把數(shù)據(jù)進行分類，放到不同的分片里。

如果做分片，會發(fā)現(xiàn)原來有這么多的連接必須要拿走，不能放在里面去了。當然，做分片無法實現(xiàn)數(shù)據(jù)交易。不用分片方式可以實現(xiàn)其中的交易，現(xiàn)在做分片不可能了。另外，確保一些獨特的約束，比如說有一些特殊的數(shù)據(jù)庫，用戶的信息、電子郵件等。必須要有特別的系統(tǒng)確保不同的分片、不同的運輸。更換擺設的話要很長時間，要做非常多的工作才行。

另外，報告。原來選擇一個搜索把數(shù)據(jù)找出來，現(xiàn)在有上千個數(shù)據(jù)庫，寫一些腳本反復執(zhí)行找到查詢的結果。下面看一看我們怎么分片的。

現(xiàn)在看到的這張圖，所有的數(shù)據(jù)庫都放在這里，我們一開始有八個物理服務，每個上面都有512個數(shù)據(jù)庫，都是DB0001和00513、3072數(shù)據(jù)量都一樣，里面ID分開不同的數(shù)據(jù)，包括用戶數(shù)據(jù)、貼圖的數(shù)據(jù)。另外，多主庫的應用。每一個服務器都有它的主庫，有很高的可用性，非常的強大。不同的會崩潰，如果有問題的話，把里面導出來傳輸其他的服務器就可以了。

我們有八個服務器，但是服務器上面有太多的用戶信息了，數(shù)據(jù)負載太大怎么辦？有512個數(shù)據(jù)庫，可以把數(shù)據(jù)分開放到數(shù)據(jù)庫里面。比如說DB0001放到其他的服務器上。我們做同樣的工作，分開來放進去就可以了。

下面看怎么改變ID的，對我們ID的分片非常重要的，我們的對象有獨特的ID，64位的，根據(jù)不同的類型進行分片、進行分離。比如說剛才講的數(shù)據(jù)庫有不同的編號，有它的類別，要么是圖板、要么貼圖、要么評論、要么用戶。是不同類型，類型也是能夠給他專業(yè)性?？磾?shù)據(jù)看有沒有把東西放混了，把用戶的數(shù)據(jù)放到評論的數(shù)據(jù)里面了。

分片的ID到底放在哪個數(shù)據(jù)庫里，現(xiàn)在用的表里面我們屬于哪個位置的。本地ID看這個表里面具體的放置信息有什么作用，是關于評論還是用戶信息的。我們看看有簡單的映射，整個管理數(shù)據(jù)庫，還有反向的圖。我們的系統(tǒng)代碼可以有效的找到相關的過濾信息。如果想找用戶信息，就看一看到底分片的ID在哪里。找到后在分片的ID里面具體找到1057，再在1057里面找到具體需要的類別，找用戶。這樣的分片使到我們工作非常的簡單。從這樣ID的結構，新的用戶就是隨機分布在不同的分片里面，希望能夠根據(jù)不同類型的信息放到不同的分片里面。至少在本地你把用戶需要的東西和需求連接在一起會比較簡單。

我們可以使用自動增量放在本地ID上，系統(tǒng)里面每個分片就是根據(jù)ID在里面存儲信息的具體情況。如果建立好ID能有6萬個不同的分片?，F(xiàn)在只用了4096個。所以現(xiàn)在還有很多的ID空間可以使用，而且可以能夠以水平的方式進行不斷擴張。

在數(shù)據(jù)庫中，有一些比較簡單的模式或者板式，每個角色都有它的ID，通過映射對應到圖表里面，進行序列化。有索引表和映射表，用戶喜歡哪些圖板，建了哪些圖。就像傳統(tǒng)的系統(tǒng)一樣，很快找到表的有效信息。重點是這些映射從一個完整的ID到另一個ID產(chǎn)生映射。對于系統(tǒng)來說，喜歡某個貼圖或者喜歡某一個用戶的貼圖，整個ID都是完整的，把所有的連接在一起，當然時間戳也非常有價值，分類的時候確保ID是獨一無二的。我們的查詢都是組件查找和索引的查找。如果數(shù)據(jù)庫過于擁擠可以進行分移，但是不會移動分片上的數(shù)據(jù)。所有的分片上都會裝在所有的映射表。這樣的話不需要進行范式的更改。因為不需要擔心有任何的改變，比如說增加一些新的索引的話，就可以使用索引來形成新的映射表。所有的分片上都有映射表。比如說我們網(wǎng)站是怎樣運作的，看某個用戶的主頁，想提取用戶的數(shù)據(jù)，渲染用戶主頁，抽取畫板和貼圖，從此來渲染。很多一兩次查找進行搜索就可以了。而且因為這些非常容易，可以在本地進行連接。很多工作是重復性的，可以進行大量高速緩存。一些很簡單的MySQL的操作，在高速緩存中提取就可以了。而且我們還可以去抵消一些操作。

如果是提取150個貼圖，可以根據(jù)這些操作取消一些對沖和抵消的操作。另外，還要編寫腳本，這些數(shù)據(jù)需要進行清理，數(shù)據(jù)庫設置的時候有不同的格式，我們需要把這些不同的格式進行整理才能放入分片里面。我們用的Pyres，這個工具比較容易，可以簡單進行數(shù)據(jù)調(diào)整。我們有5億的貼圖，16億的關注者，我們做一些腳本，不斷測試，把這么多的數(shù)據(jù)進行分片。另外，考慮數(shù)據(jù)怎么產(chǎn)生，用簡單的腳本來進行所有分片的過濾。

從這點往后，MySQL將會成為主流，而且也會成為正確的選擇，集群會慢慢成熟。目前來說，這個技術還是分配在幾個不同的公司當中，我們的公司比較關注于自動的分片。MySQL上面進行自動的分片，我們覺得這個是可行的。另外，集群將在以后會大有作為，但是不是現(xiàn)在?，F(xiàn)在集群技術目前來說，對數(shù)據(jù)來說還是有各種問題的，還是要等個五到十年才能硬化。原來有一個單片的系統(tǒng)，我們開始進行分片的系統(tǒng)，轉為一個基于服務的架構。有幾個不同的原因，因為規(guī)模不斷擴大的時候，會有越來越多連接上限，不斷達到連接上限。還需要把所有的盒子連接在一起，連接的上限也是一個很大的問題。比如說100多個ATI要連上緩存的服務器，使到服務器癱瘓，而且功能要進行隔離和分離，比如說把某些服務進行分區(qū)。當然，這也是我們繼續(xù)做的方向，幫助我們清理系統(tǒng)。同時，安全的隔離也是很重要的，因為安全性很有方法。因為隔離之后有安全性了。如果在一個單片或者非常復雜的環(huán)境中很難跟蹤的，最重要在未來不斷擴大團隊的人數(shù)，現(xiàn)在有很多的工程師，隨著用戶的增加、人力也要增加。除了提供基于服務的架構，確保架構簡單。現(xiàn)在不斷招人，現(xiàn)在的工程師招人絕對是簡單易用的，隔離開來區(qū)別對待，這樣工程師不用面對整套的大攤子，工程師上手非常容易的。

最后一個跟大家分享的經(jīng)驗，要保持樂趣。

工作當中有很多壓力，每天晚上熬夜加班肯定不好玩，如果網(wǎng)站運行非常順暢，帶來大量的滿足。一定要讓工作保持樂趣，而且讓這一切能夠井井有條。  

【Marty Weiner】我們5點10分有另外的講座，比較深入講一下怎么分片的。如果大家想了解怎么緩存、怎么分片具體的內(nèi)容，大家可以在下午來到分會場?，F(xiàn)在還沒有問題？

【提問】講個非常精彩，有幾個問題，您可以選擇是不是回答。在設計當中有哪些設計功能？第二個問題，擴展性是你現(xiàn)在容量的16倍，因為開放了4000多個ID，總量6萬多個空間，只開放到4000多個，擴展空間有16倍，是不是要重新設計架構呢？第三，有沒有考慮要設計自己的存儲架構？會不會用一些開源的解決方案。因為有一些編寫代碼不是特別好用，用別人編寫的代碼可能有問題，未來會不會考慮自己的一些編程，編寫自己的。

【Marty Weiner】第一個沒太聽清楚，先回答第二個和第三個。第二個問題是擴展16倍，我們有4096個分片是分布在8個數(shù)據(jù)庫，也就是說，8個數(shù)據(jù)庫都可以能夠在進行擴張。所以，我們可以每一個數(shù)據(jù)庫都可以擴展512倍。我們的擴展實際上可以進行幾千倍的擴展性。第三個問題，怎么編寫自己的數(shù)據(jù)庫和存儲的數(shù)據(jù)庫，我們也在考慮這個問題，如果一個地方出了問題，是不是用自己的方法解決呢？首先我們要組建我們的團隊，有這樣的人力才這樣做。因為要寫自己的信息、基礎設施。我們用的公司也非常好，可以把不同的日志放在不同的地方。自己考慮編寫一些編碼，或者優(yōu)化一些編碼，加入了一些結構。第一個問題？

【提問】現(xiàn)在的設計當中，會不會有新的功能進行調(diào)整的架構呢？如果有一些新的功能，但是現(xiàn)在架構不支持這個功能會不會調(diào)整呢？

【Marty Weiner】我們有幾種想法，只是要增加一些緩存、增加一些功能問題就不大了，因為分片有一個好處，很靈活，我們用分片的時候也有幾個是熱點，這時可以考慮一下剛好分到分片上，問題得到解決。

【提問】我們流量有大幅度的增長，如果有自動的擴展就簡單了。但實際上我們用一些腳本進行數(shù)據(jù)的遷移。很快電腦節(jié)點就超載了，要考慮其他的問題。其實我們有很多的自動擴展，不光是數(shù)據(jù)庫。系統(tǒng)層面上有自動擴展的功能。如果負載增長的太快，網(wǎng)站在ATI的盒子可以自動伸縮，這是網(wǎng)站級別、系統(tǒng)級別的自動擴展能力。

【Evrhet Milam】數(shù)據(jù)庫還是比較穩(wěn)定一致的，兩到四個星期就要把數(shù)據(jù)庫進行一次分割，這是比較穩(wěn)定的。對我們來說也很容易去觀察、跟蹤。比如說我們應用多了，ATI多了，復雜性強了，我們就選擇用自己的系統(tǒng)進行自動的擴展。不知道有沒有回答你的問題。

【Marty Weiner】我們的網(wǎng)站也會做一個擴展。

【提問】選擇架構不僅要看是不是免費的，在中國選擇合適的架構，要看優(yōu)先級怎樣才行。

【Marty Weiner】免費不是最重要的，甲骨文如果做好的話，肯定會選擇甲骨文，跟MySQL差不多，甲骨文要費用，MySQL不用費用，肯定用MySQL。我們選擇免費的軟件，是因為在這樣的條件下，必須要選擇在預算之內(nèi)開源的軟件，而且發(fā)揮不錯的效用。

【主持人】接下來用熱烈的掌聲感謝兩位工程師，休息十分鐘，十點帶來第二個主題演講！

#p#

【主持人】接下來是ChinaNetCloud的創(chuàng)始人Steve Mushero，為大家介紹網(wǎng)絡架構疑難雜癥解析。

【Steve Mushero】大家上午好！我是Steve Mushero，接下來講一講互聯(lián)網(wǎng)出現(xiàn)問題的應對以及一些有意思的事情，互聯(lián)網(wǎng)的結構以及與客戶打交道遇到的問題，現(xiàn)在的工作和以前的工作，戰(zhàn)略戰(zhàn)術實踐以及怎么更好的解決問題和吸取的教訓。

我在上海管理ChinaNetCloud，在中國已經(jīng)待了七年了，我原來在硅谷，在系統(tǒng)基礎架構設施開發(fā)等方面有很多經(jīng)驗。當年我和各位一樣負責建造開發(fā)系統(tǒng)。大家剛才聽了Pinterest的演講，他講的內(nèi)容我舉雙手贊成，對中國客戶講是非常有用、非常不錯的信息。換個角度來看，看整個中國互聯(lián)網(wǎng)的架構，ChinaNetCloud08年由硅谷的技術人員在上海成立，我們管理中國互聯(lián)網(wǎng)及游戲的服務系統(tǒng)，有性能數(shù)據(jù)庫、系統(tǒng)數(shù)據(jù)庫、服務器數(shù)據(jù)庫，有上千個服務器、上百個客戶，說實話林子大了什么鳥都見過。包括服務器系統(tǒng)、電商、體育系統(tǒng)、金融系統(tǒng)、IPTV，看到所有的這些相關的問題。

我以前在土豆網(wǎng)做過CTO，對中國的互聯(lián)網(wǎng)提供一些游戲、視頻以及基礎架構有非常豐富的經(jīng)驗。中國是世界上最大的互聯(lián)網(wǎng)群體。雖然說量很大，用戶數(shù)量是美國的四倍，但是問題會多很多。尤其在提供高交付性的用戶體驗非常困難。比如說電子商務、網(wǎng)上交易以及在游戲方面。為什么會出現(xiàn)這些問題呢？有非常先進的ipad、手機應用，需要不同的基礎架構。有些好，有些做的差一些。在中國這方面的運作比較困難一點，最重要的是提供性能、服務，是我們利潤所在。在美國也是一樣，如果更快的下載，網(wǎng)絡上傳速度越快，賺的更多，這一塊中國做得不怎樣，極待提高。

中國互聯(lián)網(wǎng)群體超過5億的用戶，每年增加一到兩千萬，可以說互聯(lián)網(wǎng)遍布世界各地。但是看用戶分布在哪里，有年輕人有老人，中國互聯(lián)網(wǎng)發(fā)展很先進的，在家一二兆，在辦公室五到十兆，在美國帶寬都比不上中國。從基礎設施講，有區(qū)域問題、網(wǎng)絡堵塞問題，帶來很多的麻煩。

我們確實很快，但是另外一方面發(fā)展路走得不是特別順。到底遇到什么樣的問題？

在中國分成不同區(qū)，有中國電信、中國網(wǎng)通，北方主要是網(wǎng)通，遼寧省、河南省、山東省網(wǎng)通為主，南方用中國電信，21個省市自治區(qū)，像浙江、廣東等。這個問題是分離的問題。另外，中國移動的GPS，中國聯(lián)通iphone和賽爾網(wǎng)絡等。很多客戶不理解為什么中國的網(wǎng)絡格局如此分裂，進入中國市場就是一個問題。如果西部的話，成都、新疆甚至用不同的IP。去年移動買了鐵通、電信買了CDMA業(yè)務，外國的公司越來越搞不清楚互聯(lián)網(wǎng)的格局了。

有什么問題？非常差的連接性，很多人在網(wǎng)上看視頻，喜歡用BT下載、迅雷下載，占用很多帶寬，對我們游戲來講，復雜度太高了。在中國不同的區(qū)域之內(nèi)，甚至在區(qū)域之間。像深圳、廣州、東莞，不同的區(qū)域之間的聯(lián)系成了大問題。每一個ISP是區(qū)域性的，比如說中國電信分布每個省市自治區(qū)的子公司，但是這些可以說沒有交集的。因此向全國性的服務太困難了，要買數(shù)據(jù)中心、買帶寬。知道帶寬從哪來的。到中國電信買沒問題，但是要知道從哪個中國電信買的。在某個地方可能很便宜，在西安很便宜，可能在長沙就很貴。在昆明買的話，服務能不能用到長沙、北京呢？所以要了解哪個ISP買，到底能不能聯(lián)系。

瓶頸是區(qū)域之內(nèi)、區(qū)域之間南方和北方有連接的問題。在廣東深圳有一些服務器，但是提供到北京很難了，但是南方提供到北京天津，必須有好的策略。很多公司不管這個。在深圳廣東有一些服務器，這里的帶寬便宜，提供這里的客戶就行了。但是有野心、有抱負，在全國范圍內(nèi)開展用戶，來自于廈門、福州、北京、上海、天津的用戶有效的使用這個服務器才行。

另外，移動互聯(lián)的問題。原來GPRS玩簡單的游戲沒問題，現(xiàn)在iphone來了，iphone是聯(lián)通和移動的連接就有些問題了?；蛘哒f可以用wifi，移動互聯(lián)網(wǎng)上發(fā)現(xiàn)移動網(wǎng)絡公司不想買帶寬，如果是聯(lián)通的話，找一個運營商買帶寬才行。現(xiàn)在不想買。當然有些情況出現(xiàn)改變，有些用移動IDC，但是提供服務太糟了，所以有一些瓶頸需要克服。一些問題解決不會帶來太多的錢，就不管的。

很多系統(tǒng)使用代理、賽爾網(wǎng)，服務器在北京很偏的地方，放一個服務器，每個月付很少的錢就行了，才不管這些東西。在很多地方都有BGP，在中國不是很常見。五年前BGP幾乎不可用，但是現(xiàn)在的BGP，中國五個地方在用了，但是才五個地方。相對價格會高一點，所以很多人不愿意用?？赡軙枚嘀鼐€路。在天津可以用，網(wǎng)通用電信或者中國移動幾條線共用。BGP現(xiàn)在還是慢慢受人的青睞。但是有很多客戶不太清楚BGP，只會找中國電線，會帶來一些問題。從全球的角度講，和世界各地進行互聯(lián)的角度講，中國這方面的連接做的非常差。有很強的聯(lián)系。另外，光線通道非常繁忙，很多東西根本傳不過來。有些時候上美國的網(wǎng)站行，后來突然發(fā)現(xiàn)未來的一小時，甚至一天、一個禮拜、一個月服務器用不了，如何上美國的網(wǎng)站?？赡軙幸恍├獾那闆r，但是真的使用海外的服務器，確實非常麻煩，必須要找到海外相對比較好的供應商才行。

有很多客戶、電商，要求越來越高，學生非常時尚、消費，但是很難接觸，學生使用的賽爾網(wǎng)，比如說網(wǎng)游肯定不可能和賽爾網(wǎng)連接在一起。像一些大的品牌，像諾基亞，可以通過手機信息傳輸給學生。

移動也是很大的問題，大家都跟移動有關。有三大運營商，中國電信、移動、聯(lián)通。都是分開來的，有些用智能手機，但是用一類，另一類的客戶只做奢侈品，只用iphone，別的看都不看，是另外一群人，分割是一個問題，把服務放在移動IDC上是可以。但是今天只針對移動的話，60%都用wifi，離開了這個房間就沒有wifi了，必須用中國電信、中國移動了。所以三通必須配才可以，我覺得三通非常常見的。包括北京上海越來越多。這個行業(yè)來自不同的行業(yè)有自己的挑戰(zhàn)，包括電子商務如何響應時間、可靠性、速度，快速得到服務很重要。稍候會講到廣告，廣告關系到表現(xiàn)。

游戲有不同的響應時間，有一個多用戶的分區(qū)，以及有大數(shù)據(jù)的下載。BGP已經(jīng)談到了，如果能夠付得起錢就用。如果買BGP必須要理解買的是什么，不是所有的BGP都一樣，有兩線、三線、八線BGP，八線BGP非常少。必須要知道買的是什么，而且非常貴，中國的價差最便宜到最貴可能相差十倍。兩通到八通，在哪里買。在北京買八通要貴十倍，必須要考慮花得起多高的價錢。帶寬是你最重要的考慮。買BGP的話，不一定往往是有效的，有的時候看到帶寬的限制，買了100G后來發(fā)現(xiàn)不是100G，5G和10G，有些有想不到驚嚇。數(shù)據(jù)中心每天都有問題。部署架構的時候，每天會碰到新的問題。在哪里選擇數(shù)據(jù)中心，這些很重要。包括移動資金都很重要。而且?guī)捵兓芏嗟?。很多時候有些帶寬很好，但是表現(xiàn)非常差。

我們的顧客有一半在數(shù)據(jù)中心受到攻擊。選擇什么樣的數(shù)據(jù)中心呢？是不是信任他們管理的服務呢？服務也是大的問題，擴展也是大的問題，比如說有十個服務器，兩個服務器。本來有兩個服務器，突然之間一下子全部堵住了，再打電話加服務器，沒了。必須要考慮一下，一旦火了怎么擴展，會帶來架構的問題。再找一個數(shù)據(jù)中心，兩三天內(nèi)增加數(shù)據(jù)中心非常復雜的。這是數(shù)據(jù)中心的問題。服務也是很大的麻煩。

這么多的問題該怎么解決？我從運營的角度談一下，而不是從互聯(lián)網(wǎng)的架構角度。我們覺得這個建議很簡單的，但是我們的顧客往往不太理解該怎么做。當一個新的顧客第一問題就是問，你在什么地方？用戶在哪里？電子商務游戲的占點，可能突然發(fā)現(xiàn)用的移動中心根本就不搭的，所以地點非常重要，選了一個地點要搬就不容易了，看單點還是多點。作為一個架構師兩三個點，但是公司要去做兩三個數(shù)據(jù)中心的布點，在中國是非常不容易的。

當然，我知道有些游戲可能有不同的分區(qū)，有不同的故障恢復的站點。剛才講到一定要挑好的地點，盡量保持簡單。選一個地點一定要發(fā)展之后占點多了在有新的站點。我們的選擇是花得起錢的最好的站點。不一定找一個三級城市挑一個三級的IDC。我看很多人找不到地方，是哪個叔叔舅舅認識什么人，找一個三級的數(shù)據(jù)中心。

有多少錢都要避免三級城市，避免三級的IDC，現(xiàn)在考慮到怎么樣應對移動的應用，考慮到怎么樣擴展，而且我們要考慮到云。云往往有一些新的因素。在中國對于云來說比較早的，云的選擇要考慮，目前來說不太現(xiàn)實。

選擇IDC的地點之后，看買什么，買能花得起錢的。不光是帶寬，還要考慮連接性。認真對待業(yè)務要看數(shù)據(jù)中心會不會受到攻擊，數(shù)據(jù)中心有沒有保護，如果公司火了之后，很多人會幫助你，有沒有提醒防護。所以，一定要考慮在哪里花錢。同時，要獲得好的服務，很多IDC的服務真的不怎樣。很多數(shù)據(jù)公司不接受你的到訪，要體現(xiàn)預約。要去數(shù)據(jù)中心的話，要提前預約，打電話就可以來。突然跟北方連接不上了，打電話打不通，幫不上忙。

另外，連接性和帶寬，還是那句話，只要花得起錢，就買最好的。要保持簡單，但是要買你能夠花得起錢最好的。在你的資金范圍內(nèi)，買最好的數(shù)據(jù)中心、最好的硬件、最好的帶寬。可能是幾千塊一個月，要考慮錢花在什么地方，要考慮對用戶的地點。單線、多線，有移動要考慮wifi。從績效來說，很多用戶說基本工夫沒做到位。比如說網(wǎng)上的架構、網(wǎng)上的編碼。但是很多顧客很基本的主頁就有20兆，主頁上的照片太大了。所以你覺得要做到完美，但實際上并不完美，所以一定要考慮到，有快速的表現(xiàn)。所以一定要以終端用戶為中心，考慮怎么樣讓它滿意。要考慮怎么樣小心化、快速化，用什么樣的圖形。

有些東西做得很漂亮，但是太漂亮做得太大了。而且應該遵循一下最佳實踐，進行測試。有很多網(wǎng)站、書籍幫助你進行這樣的測試，很多人忘了做測試，可以很清晰通過測試得到報告，有什么樣的問題。這種測試服務是很有用的，會帶來終端用戶體驗巨大的差別。

有可能的話用AJAX，很多人可能在用AJAX，每頁是動態(tài)的渲染，每天閱讀幾百個頁面，是動態(tài)的，有大量的服務器，用AJAX系統(tǒng)，這種系統(tǒng)可以做出很大的轉變了。首先把這個網(wǎng)頁搞好之后，AJAX是真正幫助你的第二步，可以幫助你更好的上傳。在中國很有用的，真正幫助提升用戶體驗。如果不能用AJAX，還是要考慮一下怎么用緩存。盡量一個頁面是電商的頁面，可能五分鐘、十五分鐘，一個小時才能夠渲染出來的畫面。高速緩存確實真正能夠提高表現(xiàn)。如果很大流量，上網(wǎng)買東西的話，速度一定要快。所以AJAX的緩存是很有用的，而且要考慮其他的對象。

最新的趨勢是有更多的Push和Async，我們是推送給顧客的方法，特別是一些動態(tài)的游戲，顧客可以下載一些靜態(tài)的數(shù)據(jù)，可以把動態(tài)的數(shù)據(jù)推送給他們，這個體驗是很好的，我們靜態(tài)的數(shù)據(jù)都已經(jīng)緩存下來很固定了，推送給用戶的體驗是非常流暢非常好的。聽起來很簡單，架構、編碼、資料庫都有很大的工夫要做，但是最終的效果是很好的。比如說頁面是靜態(tài)頁面，動態(tài)推送給客戶。但是需要時間理解掌握。每個用戶PCB連接到你的網(wǎng)站。在香港有300萬個同步用戶，應該來說不是很多，但是同時300萬都連上網(wǎng)站沒有多少人做到了，實際上要考慮你的拓展性。所以這個系統(tǒng)要考慮到擴展，每個服務器接待多少用戶?？梢宰龅降脑挘梢缘玫椒浅Ａ钊梭@訝的效果和滿意的用戶體驗。這是最終極追求，進行高響應的界面。剛剛進入中國，沒有多少人用，但是非常期待的。

我們講了最佳實踐，講了（英文）網(wǎng)站，可以找一些基本的問題，很多都可以做。我們看太遺憾了，網(wǎng)頁非常慢，自己應該做檢查，不通過檢查CDI做得再好都不能解決主頁只有5兆的事實。

我是CDN很大的粉絲，在中國CDN很有用的，可以帶來兩大好處：第一，提升用戶的體驗，有一個緩存。第二，靜態(tài)用戶、終端用戶體驗快速流暢，而且可以降低帶的價格，如果帶寬的價格降下來，就可以買一些高質(zhì)量的帶寬了。

比如說錢不是很多，把錢有效的拿出來，到八通的BGP，是中國最好的，大概一兆是800塊錢，可以把其他部分降下來，用到BGP上面，性能非常高，花的總錢數(shù)沒有多多少?；烁噱X在視頻和圖片上，不可能花錢來應對帶寬的要求。所以要看到全局里面看怎么區(qū)分我們帶寬。一方視頻可以多一點，簡單圖片少一點，分配使用成本。

稍候我會講到云端計算，講云也用了CDN，很多人沒有意識到云計算的時候，用CDN。監(jiān)控也非常的重要，重要性不言而喻，因為在運營過程中我們會監(jiān)控。我們要監(jiān)控200到300個服務器，要有安全的情況。另外，非常重要的一點，有錢要監(jiān)控服務器之外的情況，中國最好多游戲網(wǎng)站、最好的電商，看看做得怎么樣。比如說我在深圳有服務器，在成都做得怎么樣？昆明做得怎么樣？武漢做得怎么樣？可以跳出自己的框框，按照CDN和不同的運營商了解整個市場的情況。當然，有些做起來是比較貴的，比如說電商公司在中國各地賣我的產(chǎn)品，肯定想知道我的網(wǎng)站對于成都那些客戶來講  網(wǎng)站響應速度怎么樣，產(chǎn)品賣不賣得出去等，如果不去了解，永遠不不知道他們的想法怎樣。這樣的服務雖然花點錢，但是可以了解到客戶對你的網(wǎng)站和服務怎么看的。

我們也非常喜歡云計算，ChinaNetCloud提供云計算很多年，是市場先行者，現(xiàn)在跟阿里云等開展合作，最終希望達到AWS的水平，向中國提供。當然還有上海的世紀互聯(lián)也很有前景，尤其是阿里云?？梢噪S便加服務器，使用不同的服務，存儲非常簡單，甚至可以使用云來為服務器存儲一些相關的服務。在美國沒有人在服務器里面存圖片，都存到云端。在中國也可以考慮這個方法。如果沒有存儲，不知道怎么分享相應的資產(chǎn)，可以了解一下其他人是怎么做的，直接放到云端就行了，而且成本很低，在中國原來做不了，今年有機會。希望大家考慮一下云端存儲、云端服務器，基礎設施等。我們認為未來會非常流行，希望越來越多的公司上云。這也是很好的消息，目前只能說限制在中國大陸之內(nèi)的。

另外，使用云計算的時候，要知道你的目標怎樣，像阿里云一樣成為AWS還是有其他的目標。如果只是一個服務器，用起來比較簡單，PHP就夠了。如果更大的1到21個服務器，帶來什么問題。列表告訴大家什么最重要，帶寬等小問題都會產(chǎn)生舉足輕重的影響。阿里云做得也還不錯。如果用云計算、云服務的話，千萬不要因為小的問題給你嚇了一跳。當然，如果用公共IP的話，還要為此付費等。這些都要搞清楚。我會把我們評估的標準、關于中國的云計算的相關評判標準，正式公布，大家就可以了解到了。

我想在座很多都希望不僅僅在國內(nèi)金融服務，還希望走出過門?？梢愿鷣嗰R遜、rackspace合作。有些客戶既要滿足國內(nèi)需求還要滿足國外的需求。很多又要搞中國的系統(tǒng)，又要搞美國的系統(tǒng)，很困難。很多把服務器放在香港，在香港放服務器，給中國大陸的客戶提供服務，再給美國客戶提供服務。如果是一個小公司、小系統(tǒng)放在香港沒問題。但是，如果是一個大公司，有合適的架構同步所有的信息。確保美國信息和中國信息是同步的，比如說總部信息和子公司信息一樣。這里很難說你用一個簡單的系統(tǒng)來支持美國、中國的市場。中國的服務器支持美國市場、日本市場的話，很困難的。

在香港沒有Amazon，在東京用Amazon，可以更好的接觸客戶。這個問題看起來還沒有起色。

中國的互聯(lián)網(wǎng)是很大的產(chǎn)業(yè)，很多的事態(tài)發(fā)展，變化很快。雖然電信業(yè)的巨頭買了另外一個公司，行業(yè)格局出現(xiàn)變化，BGP、CDN都可以改變行業(yè)的格局，必須有更好的經(jīng)驗監(jiān)控行業(yè)，另外選IDC位置地點非常重要。在中國看性能怎么樣，關鍵因素是IDC放在哪里，怎么更好的提供服務。像架構編寫等都可以影響到CDN使用的成效，還要監(jiān)控服務器的作用性能。確保在市場產(chǎn)生足夠的影響，而且在中國賺到錢。在中國只要做得快，客戶滿意就開心了。我就講到這里！

【主持人】謝謝Steve，剛才講了中國網(wǎng)絡服務，云計算服務哪些難處，我有一個問題是關于亞馬遜云服務的，我覺得亞馬遜在中國沒有數(shù)據(jù)中心吧！有沒有一些中國公司使用亞馬遜云計算的成功案例，可以針對中國用戶和國際用戶。

【Steve Mushero】亞馬遜目前在中國沒有公開的服務中心，最近在日本，未來會在香港設一個，可能也會在中國大陸有，目前來講還沒有。我不太清楚有哪些大的公司使用亞馬遜的云服務。就算中國用的話，只是一小部分，很難擴展，不可能復制出來做出更大的成功案例?，F(xiàn)在阿里云和亞馬遜的云服務是可以借用的，在中國用阿里云就可以了。

【提問】找數(shù)據(jù)中心和買房一樣，地點、位置最重要的。在中國做網(wǎng)站成功的話，還面對一個問題是政府的限制。

【Steve Mushero】不好意思能不能再重復一下。

【提問】中國的網(wǎng)站，國外的服務器用中國的網(wǎng)站。

【Steve Mushero】對我來講，在中國打開美國的網(wǎng)站蠻快，在美國打開中國的非常慢，可能有一些限制，路由的優(yōu)先級不一樣。中國很多人喜歡看美國、歐洲的網(wǎng)站，相對講有這樣的流量促進，所以快一點。美國歐洲沒人看中國網(wǎng)站，自然打開慢。另外，防火墻是不是會影響到這個呢？出去容易進來來？不知道是不是這個。之前沒有具體了解過，有時候在香港放一個東西。香港帶寬也會受限，效果也不是很好，謝謝！

【主持人】大家用熱烈的掌聲感謝Steve。休息十分鐘，11點帶來第三個主題演講！

#p#

【主持人】接下來有請Coding the Architecture創(chuàng)始人Simon Brown為我們帶來“郁悶的架構師”。

【Simon Brown】大家上午好！首先，講一下軟件架構師的認知是什么意思？如果你是一個架構師，往往有人覺得做大型前端設計、懂UML就是架構師。

我不是一個很有力的架構師，不會畫出大量的架構圖解，我的工作不是做畫大量的圖。其實有很多的熱門詞匯來描述軟件架構師的角色。最近聽過一些熱門詞，比如說架構師是“業(yè)務技術戰(zhàn)略家”，業(yè)務、技術、戰(zhàn)略家三個詞我懂，放一塊我不懂了。我有一次開會，有人問我，怎么樣把MongoDB放在當中，他們高層告訴我MongoDB是什么。有很多的熱門詞，熱門詞有必要的，用術語、用熱門詞。往往太多了，就忘了軟件開發(fā)基本的知識了，我們離軟件學問越來越遠。所以我是一個軟件程序員，是架構師，是團隊一樣。也喜歡編寫代碼，大家舉手有誰喜歡編代碼的。挺多的。

我們考慮架構師是什么地位。我入行的時候是一個工程師，是一個軟件程序員，慢慢晉升到架構、團隊領導的工作。我有兩個很有意思的時期，在UML的時候，我最早開始做架構的工作，主要是畫UML的設計圖。6個月寫UML的文檔，對我來說我覺得是一種浪費。

我在一個大型的管理咨詢公司服務，他們招我進來做軟件架構師，每天也編寫代碼，他們不理解，讓做軟件工程師為什么要編寫代碼呢？在大型企業(yè)往往是事業(yè)的階梯，你是一個高級程序員、架構師，慢慢升上去，離開了這個隊伍，進入了管理團隊，這是很令人遺憾的。大部分的技術人員，最好在這個團隊里還是發(fā)揮作用的。在團隊里面，很多時候英國一些公司，因為技術源做得好進入了管理層，公司反而失去了動力。

我有一個網(wǎng)站叫Coding the Architecture，覺得架構離不開這個編碼范疇的。很多人說軟件架構師是一個名片上的職位、頭銜，拿到這個頭銜工資高一點。但是這是一個角色，是慢慢發(fā)展才能進入的角色。

大家進入Linked討論的話，說是一個高級程序員晉升到架構師，說我該干什么，有些人進入到架構師反而不知所措。

誰想做到敏捷？有些人喜歡敏捷，敏捷是未來大的理想。軟件開發(fā)做到敏捷，是很酷。但是，我覺得我們是不是忘了一些什么？特別是軟件架構的時候是不是忘了什么？

我們講一下敏捷這個詞，敏捷有很多相關的熱門詞：自動測試、精簡、瘦，這些都相關，而他們都是很好。其他表現(xiàn)、擴展性、安全、團隊的共同目標，很多人忘了這些其他的重點。

很多人把敏捷強加在很多的名詞前面。我看到很多都會把什么詞前面都加一個敏捷，說賣什么東西就賣敏捷的什么東西，聽起來很酷。到底什么是一個敏捷的架構師呢？敏捷的架構師是不是不用UML的架構師呢？這種概念有些時候沒有什么意義，但是聽起來很酷吧。

Hi，大家好！我是一個敏捷的架構師，聽起來很棒！

這是敏捷的架構嗎？在我培訓過程中，有人畫圖的時候用即時貼進行畫圖，這就敏捷了嗎？架構在敏捷的方式當中，架構在什么位置呢？用不同的Skills時間框。按照項目的過程在不同的階段進行不同的設計，這是不是也是一種敏捷呢？

很多人認為只是做了一個架構，希望最好的結果。很多人覺得敏捷是一個借口，做了敏捷看效果好不好。

很多人跟我說，我們不需要軟件架構，因為我們做的是測試驅(qū)動開發(fā)。TDD就是一種測試驅(qū)動開發(fā)，但是跟軟件架構不是一會事，TDD是大的代碼，從基層的角度講，架構從高層角度。

最后負責時刻，這個詞我不太喜歡，很多人作為一種借口，遲遲不做決定，這就是敏捷，最后負責的時候做決定，往往最后的負責時刻成為不負責時刻。很多的敏捷書籍，要自我組織的團隊是一個扁平式的組織，沒有組長，大家通力合作，這個聽起來很好，因為扁平式的合作更加快捷，但是有些時候這種團隊不行，但是沒有人告訴你有些自我組織的團隊，他們可能有幾個有經(jīng)驗的人，比如說有高級，如果把高級和低級放在一起自我組織不行了。有時候有些人說，你為什么對敏捷有這么大的意見呢？其實我喜歡敏捷，并不是要抨擊敏捷，有些人覺得敏捷太多讓我們覺得很酷的東西，但是忘了一些最基本的工夫。

我覺得我們應該要回顧一下，回顧也是敏捷的熱門詞。我覺得我們忘的東西比學的更多。在軟件行業(yè)來說，學的不如忘的多。有多少人在項目當中還在用UML的？數(shù)量很少。在歐洲的比例也差不多，如果五年、十年前問這個問題，每個人都舉手。今天用這個問題很少人舉手。不是有什么取代它，而是很多人忘了它。

15年前出了一本書《顏色編碼》，用顏色編碼的UML的工作方式，這個很好，很多人忘了。因為用顏色可以清楚的做一些圖解，還有CLC，類-責任-協(xié)作，很好的方式，可以做分析儲存的分配，找一些人做了一塊，找了一個用力，進行分解。滿足用力的特點，跟每個類分配一些責任，同時找到不同工作中協(xié)作的過程。這是軟件系統(tǒng)進行分解很好的方法。用團隊分解，現(xiàn)在很少人用這個方法了。

邊界、控制器和實體，這是系統(tǒng)結構很好的方法，面向服務的架構方法。同樣還有基于組件的開發(fā)、面向模式的軟件架構。整本書都會講面向模式的軟件架構，這種書出版很久了，雖然是一本老書，里面的內(nèi)容在今天來說跟當時出版同樣有意義，但很多人沒有讀這本書了。

Rational統(tǒng)一過程，是一種增量式很直觀的過程方法。敏捷也是增量式的過程方法。Rational的統(tǒng)一過程是圍繞架構做一個核心，以這個核心做各種活動，讓架構不斷的演變。

剛才跟大家突出強調(diào)了一些過去的方法，這些方法很不錯的，不是讓大家回去按照這個做，我們要實際一點考慮，看看老的工作里面有哪些經(jīng)驗教訓和訣竅給我們用。覺得可用的話，可以在具體的工作里面可用一下。

這些經(jīng)典的東西誰在教你？沒有人教你，因為經(jīng)典的東西看上去不酷。我們書架里面有書，有看板、有經(jīng)義、有程序設計等?，F(xiàn)在人不講了，覺得沒有意思了。

很多人是做軟件架構師的，實際上沒有搞清楚做軟件架構師是干什么。我在倫敦工作的時候，招日招軟件架構師，面談看簡歷情況。這時有一個企業(yè)的架構師，描述他的工作，做得工作就是大企業(yè)里面做一個軟件架構師，給自己加上一個實際上根本沒有負責的頭銜，讓人聽起來感覺很不舒服。

經(jīng)常發(fā)生這樣的情況，人們發(fā)現(xiàn)軟件開發(fā)像接力賽一樣，實際上解決方案的架構師會問一些情況，或者要求之后，會做一些架構把它以文件的形式記錄下來，非常厚的文件，文件交給團隊就跑掉了。

團隊拿到文件之后，要負責把架構真正付諸于實施，我不喜歡這種方式，這個人做了架構跑掉了，團隊不知道怎么做出來的，內(nèi)容團隊有問題的話，不可能問原來設計的人。我給它起了一個名字，AaaS，讀音是屁股的意思，把架構服務交給團隊不對的。就像接力賽一樣，一個棒給下一個運動員就跑掉了，其實不行的。

項目的成功不僅僅是關注與實施，很多人認為實施好就行了，并不是這樣的。

現(xiàn)在看到的圖里面有非常多的圖表，人們非常愚蠢的期待結果，做了價格，不知道能不能行通就丟給別人。有一次有人讓我們來看一個項目，當時架構里面就一個軟件架構師，做技術指導工作的。我看架構的時候發(fā)現(xiàn)了軟件系統(tǒng)里面的問題、難處，其中有安全的問題，還有功能根本用不上，另外做了負載測試結果不好，文件的記載也不怎么樣。這個項目不小，是戰(zhàn)略平臺的第一步，要先做了價格，未來幾個月、幾年把服務加在上面。

    對我來講，一個軟件架構師，要杜絕PPT上列的這些問題。我覺得做文件記載非常重要，但是現(xiàn)在講所謂的敏捷的軟件架構設計，很多人不記錄文件，敏捷的人不會把文件記錄下來，根本不增值、只做增值的事情。當然厚厚一疊文件給別人也不行。我們需要提供文件，而且精簡，不用太多，搞清楚問題就行了。

在英國以及在歐洲，我發(fā)現(xiàn)有些人根本不了解干什么，尤其是大團隊里面，大家對決策不清楚，剛才Pinterest講到團隊擴展，團隊擴展會帶來一些問題，大的團隊在一片混亂中工作，不知道自己在構建什么，而且不知道怎么樣構建，根本沒有藍圖，大家都是隨心所欲，根本沒有指導性的目標。出現(xiàn)這種情況的話，在這樣一個混亂的系統(tǒng)里面，最關鍵的是把它停下來，在系統(tǒng)里面工作非常慢，無法擴展，沒有任何安全感，感覺編碼像一灘爛泥一樣做不好。我希望編碼非常清楚、有好的結構和次序做出什么。要打破混亂，有好的愿景，讓寫代碼的時候知道方向，按照這個方向來走。原來哪些人做項目有很大的文件，就是讓大家分享他的想法。但是如果這么多的文件，會太長沒人看。既然沒人讀你的文件，初衷沒有得到實現(xiàn)，大家也是失去了方向。

現(xiàn)在我們做敏捷了，有些文件可能在白板上畫一些東西，但是別人不知道畫什么，就像無稽之談一樣，沒有共享的愿景，別人畫的東西搞不清楚。

給大家舉一個例子，來自于有一次我看到的系統(tǒng)的圖示，我覺得完全沒有意義，根本不知道這里面硬件還有軟件以及不同的節(jié)點發(fā)揮什么作用。這個比較典型，一片混亂搞不清楚做什么。所以我們必須要把我們所工作的方式可視化。我們看敏捷、看板、故事強。用易貼紙在墻上，就知道流程是什么樣的。我們不可能系統(tǒng)用圖的方式來做。還是要考慮用UML來畫出來。

以上是我演講的第一部分，作為軟件架構師對行業(yè)感到的挫敗感。

我們希望團隊成員共享愿景，知道發(fā)展方向怎樣，很多時候在公司里面會請一個軟件架構師，會成為這個架構師的頭頭。開發(fā)人員接受架構師的指令，團隊就是這樣工作的。我們感覺軟件架構師在象牙塔里面使令，在開發(fā)團隊做的事情沒有任何交集。軟件程序員不會理會架構師的建議，覺得建議是一派胡言，用不上，要避免這種情況。

怎么做呢？

我們請一個軟件架構師，把他當成領導安排工作，希望與團隊合作，能夠提供指導，提供相應的輔助性的工作。要把軟件架構師和軟件程序員放在一起，縮小差距，慢慢實現(xiàn)共鳴，這樣的話非常有意思了。在一個結構里面大家可能都是軟件架構師，這是一個非常樂觀的情況。不讓他們都成架構師的話，縮小差距，慢慢也會實現(xiàn)工作中的互聯(lián)互通。

我們要請一個軟件架構師選什么樣的人？

T型的人，首先要有深度，T下面的一豎，有扎實的技術功底，至少懂基礎的語言來做。打交道知道技術怎么回事才知道技術。T下面的一橫，要知道不同的方式，知道不同的結構，解決代碼問題、擴展問題，要看不同的系統(tǒng)怎么做出來。Pinterest兩位發(fā)言人講得非常有意思，可以從那里學出來。架構的詞英文到底來自于什么意思？最原始的意思是建筑師。原來建筑師拿一些石頭、磚頭蓋房子。架構師也是一樣，我們也是蓋東西，成為這方面的大師、專家，成為通才化的專才，是軟件架構師應該有的角色。有專業(yè)的專才同時有不同的領域。

有一位英國的先生jasongorman加入了軟件的運動，在微博里面寫，我現(xiàn)在不寫代碼了，覺得行業(yè)里面資深的人有奇怪的想法，已經(jīng)很資深，不寫代碼了，會不會雇一個不會編碼的架構師？

現(xiàn)在看到的是從比較高端的角度界定一下軟件架構師做一些什么東西，保證了解要求、組織的約束到核心的技術、設計軟件、評估軟件設計，確保用得上至少信心滿滿說肯定用起來。編碼，軟件架構師核心的工作。軟件架構師不是做一件事情就固定不動了，遇到新的要求就要不斷的演進，根據(jù)不同的需求滿足不同的變化。質(zhì)量保證也非常重要。教練和指導，這是之前講過的，找一個架構師與團隊協(xié)作，提供輔導的機會帶領前進。

軟件程序員看一些代碼、測試、軟件的編制，架構師不太一樣，架構師要后退一步看看全局。所以這個時候并不只是看代碼級別的內(nèi)容，為什么呢？想象一下有一項要求，做一個軟件架構來解這個要求，怎么做？要把要求進行分解，從功能性和非功能性分解。所以，可能在環(huán)境當中有一些局限性，在工作大部分的情況下，技術選型有限制許可證和軟件等都有一些局限性。不知道架構有哪些局限性，而且有一些原則要進行。有些要在整個軟件開發(fā)當中，從始到終遵守一致的原則。解決問題有不同的方案。從編程語言到選擇技術案例。找到一個最好的方法，找到最好的選擇。不同的要求，不同的局限扔到一個盒子里，找出最合理的一項。至于在軟件編成的過程中，敏捷可以看到很多時候大家不用UML的工具，我也會用UML的工具，用它來做一些圖解，需要一些正規(guī)的流程圖，可以用它來做流程圖。但是在設計軟件的時候可能就不會做這么正規(guī)的流程圖，可能會用白板、易貼紙等。如果三四個人擠在我的電腦前用UML工具，就很麻煩，但是可以在大的白板前面一起合作就很簡單了。

我很喜歡畫畫，很多人不喜歡畫畫，不用UML，我是怎么畫畫的？基本上按常理出牌，畫一個高層的概念，把它分解，在分解筐子里進行考慮，分解數(shù)據(jù)服務、數(shù)據(jù)庫、架構等。在每個服務器又把服務器進行分解。更多的細節(jié)可以按不同的類來分解。所以這叫做C4的方法，是非常有效的草圖法，可以很簡單非常精益的做出非常好的草圖。

為什么說架構師是一個總的建筑師呢？如果是你會不會把系統(tǒng)進行編碼？是的話還好，如果據(jù)的編碼不合胃口就麻煩了。如果架構師不懂背后的編碼，會問出這個不合理的問題。

文件很麻煩，有時候會做厚厚的技術文檔，很快過時。從另外一個角度來看，從精益角度來看文檔說明。我們把它看成旅行手冊，如果看任何的旅行指南，會有地圖告訴你怎么走，這就是我們的代碼基礎了。有這個草圖就是我們的地圖了。我們看一下景點，哪些地方不可錯過要看一番，要看有歷史文化的景點。比如說這個地方怎么慢慢演變到今天的局面的，使用的信息，怎么建立和配置我們的系統(tǒng)。所以我們說精益想敏捷要減少浪費、增加價值。關鍵是要言簡意賅把要說的東西說出來，而且要增加價值。如果畫出一些類的圖解。本身看代碼就能知道，本身也能夠理解，他們是程序員，看代碼就看得懂了。所以要描述一些代碼沒有的東西。通過示意圖像地圖一樣，幫助程序員或者別人通過你這個找出文檔當中所要的東西。

這是不是大型的程序設計呢？其實并不是的。如果你看十年前，我們會有一些非常糟糕的方法。另一方面，我們有敏捷的方法，比如說極端的編成，Scrum等，這是演變性的價格設計方法。但不幸的是，有些人覺得兩者都不做是最好的，左邊前期什么都做好，另外一個極端什么都不做最好的。實際上我們不一定要走極端，可以兩者取其中。比如說像RUP統(tǒng)一過程，這是兩者之間的做法。是輕量級的，同時也是增量型的，對架構不放過。我的答案是剛好夠用。做的前端設計是剛好夠用，符合你的項目，而且是合理的，這是非常好的項目，這是一個好的指引，但是并沒有告訴你，多少才算是夠用，這就是我們回答重要的問題了，多少才是夠用呢？

Scott Ambler是在IBM工作的人，倡導敏捷包，有一個網(wǎng)站倡導一句話可以概括了，你的架構應該建立在要求上，要輕裝上陣。輕裝上陣是一個敏捷要剛剛夠用，同時要用實實在在的經(jīng)驗和實驗來證明你的架構。

什么叫做實實在在的實驗呢？用一個圓形和概念證明的方法，做一個薄薄的切片，把軟件切出薄片測試軟件的功能、擴展性。你怎么知道應該做哪一種的概念原形證明呢。必須要知道，哪些部分在架構上是有重要意義的。架構當中哪些是重要的，進行這些測試。我們圍繞著核心架構有很多的其他內(nèi)容，我們必須要把核心的架構搞對。這就回到我們說一定要把主要的風險排除在外，消除我們的風險。

有些時候發(fā)生了風險就會有不利的效果，當然要在軟件的項目當中避免這種風險發(fā)生。當然，風險可以量化的，只要把它在一個概率和影響的舉證就可以進行量化了。如果是非常低概率的風險以及非常小影響的風險，只要知道就行了，不需要做什么。如果有一個風險是高概率、很可能發(fā)生的風險，而且影響破壞很大，這種情況下，高影響，整個系統(tǒng)架構要重換。整個風險因素就要提早進行考慮。所以很多不同的風險優(yōu)先次序不一樣。我發(fā)現(xiàn)一個問題，軟件團隊不太善于列出風險，覺得很無聊，把風險給寫下來，這個可以解決。在我的培訓當中，網(wǎng)站里面有一個內(nèi)容，有一個風險的腦力風暴。讓他們?nèi)プR別風險，會畫一些草圖，讓他們就這個架構草圖放在墻上，然后把團隊、程序員、測試員，所有的人員坐在一塊，讓它看架構草圖。你們覺得系統(tǒng)有什么風險？哪里有風險？升級性、擴展性、技術的選型還是可用性？每個人有自己的想法，把這個想法匯總在草圖上，這樣的話可以視覺化的通過貼紙的形式看到大家的想法。所以風險也可以是主觀性的。

當然，我們找到風險之后，必須要處理、緩解風險，不是找到風險就完了。我們舉一個例子，什么叫風險。我在丹麥去年開了一次會議，他們說，我們對敏捷項目的一個回顧，Linda Rising會有不斷的回顧，發(fā)現(xiàn)什么問題的時候，會把問題寫在一個卡片上，粘在墻上，不同顏色的卡片代表不同的感受，有些是快樂的卡片，有些是挑戰(zhàn)困惑的卡片。紅色的卡片是憤怒的卡片。當他們覺得問題是非常憤怒就寫一張紅卡片。Linda Rising把所有的卡片鋪在地上，一邊是起點，一邊是終點。在項目的終點時，用技術用得實在很惱火，但是應該在項目開始提出來，而不是終點找到痛點。

我今天講得是軟件架構師的過程和角色不是一回事。軟件架構師的角色根據(jù)不同的團隊各有不同，角色不一樣，有個人寫了一本書《從混亂到自組團隊》，列出不同風格的團隊，有的團隊是混亂型的，有的是自我組織型的。不同團隊有不同的領導力，在混亂團隊當中有非常嚴明的領導把混亂加以控制，但是在自組團隊當中每個人都可以是領導，當然中間有不同的階段。這就是軟件架構師的角色，這個角色在團隊當中跟不同人之間的關系不一樣。軟件架構師的過程又不一樣。一方面前期設計，另一個極端做了之后也不管，看最后的效果如何。如果想把這兩個極端用圖描繪出來的話，剛剛夠用的架構剛好處在中間。并沒有大型的前期設計，沒有什么都不管，講的是中庸之道。架構有哪些結構的重要要素，在前端設計要關注的。這時前端要識別主要的風險、消除風險。但是要有共同的愿景，讓團隊圍繞這個愿景合作。在自組團隊每個人可以做領導。

敏捷軟件開發(fā)的項目是不是需要軟件架構師呢？我的答案是肯定的。你的項目就是敏捷或者不同的結構，但是架構是不可回避的。就算敏捷的項目也可能是很復雜，也可能有高安全性、高擴展性、高性能的要求，這些都是希望從架構師的角度解決的。

或者我們可以把這個問題反過來問，敏捷性怎么影響到軟件架構行業(yè)的？很多公司做大型的前期設計，設計上帶來系統(tǒng)分析、帶來癱瘓，想得特別多，敏捷性搭不上的。有什么建議呢？如果團隊處于混亂之中，沒有共同的愿景，回到一開始，重新界定一下到底軟件架構師做什么的，至少團隊中有一個人是技術的領導者，他來確定方向。你規(guī)劃出他到底做一些什么東西。比如說八個盒子，每個框里面到底哪些工作是怎么做的。另外，軟件架構師中一些手工活，別老用電腦來做，一些草圖用手里畫，畫的比較簡單一點，貼在墻上，要想敏捷行動要快，行動快的話和別人很好的溝通，很好構圖的方式就是畫草圖。我們要做的軟件系統(tǒng)是發(fā)揮作用的，能夠工作的、能夠擴展的，能夠不斷的升級的。

作為一個軟件架構師，實際上就是一個技術方面的領導者，要非常積極主動，帶動團隊而且以身作則。如果看到一個問題，直接上去解決就行，其他人就會效仿你，看到問題也會解決。

我們要為未來做好準備，未來有其他的軟件架構師，要提供管理、培訓，確保未來成功出師，能夠培養(yǎng)出來。不管做什么，只要適合你就行。因為我們面對不同方案、不同技術，要做的是選擇一個用起來最舒服，發(fā)揮最大效用的，所有的團隊都一樣。像敏捷性是熱門詞匯，很吸引人。但是敏捷對于你來說沒有四海而皆準的方法幫你解決問題。

我就講到這里，謝謝各位！

【主持人】由于時間關系，只提一個問題。

【提問】謝謝！剛才在您的幻燈片里面，我想起來以前聽說過雅虎的軟件架構師跟雅虎的CEO說，如果說我們要炒人的話，最先要炒的就是職位里面有架構師或者有所謂的項目管理人員、職業(yè)頭銜的人，你是怎么看的？

我是這么看的，不是把這些架構師炒掉，而是架構師要挑合適的人才行，有非常扎實的技術功底，而且也能夠做不同的事情。因為架構師選對人才能有好的領導。

【主持人】掌聲感謝Simon Brown！上午到此結束！