InfoQ：你好，Alex。能向我們的讀者介紹一下你自己和目前正在從事的工作嗎？

　　Alex：大家好，我是董洵，目前是Trunk.ly網(wǎng)站的CTO，它是一個專門提供社會化書簽服務(wù)的站點。由于目前公司的主要員工只有兩人，因此，即便我是公司的CTO，我仍然會每天花很多時候編寫代碼。就網(wǎng)站后端來講，目前主要做的是搜索；前端則進(jìn)行一些站點UI的設(shè)計和開發(fā)。就像大多數(shù)創(chuàng)業(yè)公司一樣，我們非常關(guān)注我們的功能特點、站點流量，而且會經(jīng)常跟投資人打交道。至于架構(gòu)師這個頭銜，其實談不上，只不過做架構(gòu)是我們平常工作的一部分吧。在這之前，也曾經(jīng)用過.NET之類的技術(shù)做過企業(yè)項目。

　　【編者注：如果想進(jìn)一步了解Alex，讀者可以訪問他的個人站點以及《程序員》雜志對他的訪談。關(guān)于Trunk.ly域名的含義，@36氪上的這篇文章中有這樣一段描述：我問 @alexdong 為什么用 trunk.ly 這個域名，他說：“是個一語雙關(guān). 在航海時代，每個周游世界的人隨身要帶一個箱子,這個箱子就叫trunk。現(xiàn)在英聯(lián)邦國家仍然叫后備箱trunk。我們就是一個鏈接的百寶箱。”】

　　InfoQ：作為互聯(lián)網(wǎng)的創(chuàng)業(yè)者，在同行業(yè)中有哪些站點的架構(gòu)會引起你的注意，讓你覺得值得欽佩？

　　Alex：這一點怎么說呢，像Google。就我個人講，我會花些時間（雖然我也沒有太多的空閑時間）去讀Google Research上發(fā)表的這些論文。像一些大的互聯(lián)網(wǎng)公司，比方說Google、Yahoo和Amazon都有自己的research部門，他們經(jīng)常會把自己解決某個問題的經(jīng)驗寫成論文發(fā)表出來。對于一些架構(gòu)上的實際問題，比方說Timeline，這些公司會做一些科研實驗，比較各種實現(xiàn)方式的優(yōu)劣，最終把這些內(nèi)容總結(jié)成文。我會比較多的看這些論文，從中了解這些公司如何解決架構(gòu)中的某個問題，以及這些問題都有哪些解決方案，以及每種解決方案的好壞。從網(wǎng)站的架構(gòu)來說，我會比較關(guān)注這些內(nèi)容。除此之外，還有一些東西的架構(gòu)我也會比較關(guān)注，這也是我個人比較感興趣的方面。比如說MongoDB、Linux或者是HyperTable，像這些新型的數(shù)據(jù)庫、應(yīng)用服務(wù)器等，我也花了不少時間去研究了解它們的架構(gòu)是如何演進(jìn)的。

　　就欽佩這個詞來講，可能有點不太準(zhǔn)確。在我看來，它更多的是一種靜態(tài)的感覺。比方說，當(dāng)你看到大概有5年或10年歷史的一個架構(gòu)，第一眼看上去可能會覺得“了不起，想得真是很全面。”，這時你會產(chǎn)生出一種欽佩的感覺。但對我來講，像MongoDB，在它還是1.0的時候，我就在自己的系統(tǒng)中用它們。更多的時候，我看到了它發(fā)展的軌跡。在這種情況下，說欽佩可能不太合適。更多的一種感覺是他們做的這些事情很有意思，很有特點。這也是為什么我會在郵件中提到，相比起架構(gòu)本身，我會更關(guān)注架構(gòu)背后的人，覺得他們更有意思。通過這些，你可以看到，同樣一個問題，由不同的人來解決，最后的解決方案會特別的不一樣，而且對應(yīng)于它的社區(qū)，你會發(fā)現(xiàn)用這些解決方案的人也特別的不一樣。所以這些事情是最令我感興趣的。

　　InfoQ：是的，架構(gòu)本身也是動態(tài)發(fā)展而來的。人本身有其自身的缺陷，很難設(shè)計出來一種面面俱到，一勞永逸的架構(gòu)。就架構(gòu)決策而言，應(yīng)該是架構(gòu)師在當(dāng)時環(huán)境所能做出的最好決策了。隨著時間的發(fā)展，周圍的環(huán)境也會發(fā)生變化，這時就需要他來根據(jù)環(huán)境進(jìn)行調(diào)整。

　　Alex：沒錯，這也是我覺得一位好的架構(gòu)師，他真正的價值不在于從第一天開始就拿出一個藍(lán)圖，它有多漂亮、多干凈。我認(rèn)為好的架構(gòu)師首先應(yīng)該是知識面比較寬廣，需要清楚有哪些選擇，每個選擇在解決當(dāng)前問題的同時還會帶來哪些影響，也就是每種解決方案好的一面和壞的一面。其次，當(dāng)遇到架構(gòu)上的問題時，能夠通盤的考慮，發(fā)現(xiàn)問題的本質(zhì)，進(jìn)而提出自己的解決辦法。比如像Linus，他實現(xiàn)的Git其實已經(jīng)融合了他對于分布式開放源代碼項目的管理以及協(xié)作方式的思考和理念。

　　InfoQ：那么做架構(gòu)決策時，就有點像權(quán)衡各方面的因素，從而使架構(gòu)達(dá)到一個比較好的狀態(tài)？

　　Alex：說達(dá)到一個比較好的狀態(tài)可能有點欠妥。我可以舉一個反面的例子。我之所以說它反面，并不是說這個抉擇或決定本身不好，而是說它有不可忽視或是很致命的缺點。像Python、Ruby和V8 Engine它們都使用了GIL（Global Interpreter Lock），它的問題在于若是我用Python寫一個計算密集型的多線程程序，它的性能可能會比不使用多線程還要差。這就是它的運(yùn)行環(huán)境或者說編程語言本身設(shè)計理念中埋下的引子。像Python之所以用GIL，是因為Van Rossum一開始最主要的設(shè)計目標(biāo)是要非常容易的寫C Extension，即寫一個C模塊，在Python中可以很容易的去調(diào)用它。有了這個鎖之后，使得寫C模塊變得非常的容易。假如沒有這種鎖，要想實現(xiàn)從C調(diào)用Python或是從Python調(diào)用C，就沒法做。在我看來，這是Python為了實現(xiàn)這種設(shè)計目標(biāo)而不得不做出的極大犧牲。而這一點，就目前看來，其實還是非常致命的，對我們自己應(yīng)用的影響也很大。

　　我舉這個例子的原因在于，權(quán)衡這個詞在很多時候看上去很優(yōu)美，沒有負(fù)面感覺。可就對我個人來說，很多架構(gòu)的決定，包括我現(xiàn)在用的很多軟件，權(quán)衡這個詞實際上有著很大的負(fù)面感覺，或者說你接受它【架構(gòu)決策】時不得不承受很大的痛苦。而且很多時候是現(xiàn)實情況下不得不接受，或者說是一種對現(xiàn)實的妥協(xié)。因為，就當(dāng)前情況而言，面對各式各樣的約束條件，已經(jīng)沒有其他更好的選擇了。假設(shè)我有充足的時間和資源，我可能會要求做得更好。

　　InfoQ：的確，每種工具或架構(gòu)有其本身適應(yīng)的環(huán)境或者說是前提條件。假設(shè)你當(dāng)前應(yīng)用的環(huán)境跟這個前提或環(huán)境有沖突時，就會造成你剛才所說的那種在應(yīng)用上非常痛苦的一面。

　　Alex：你說得非常的準(zhǔn)確，就是這種感覺。每個架構(gòu)決策就會使架構(gòu)僵硬一點，將你推向某個極端或某條路。當(dāng)然，實在不行的時候，我就會必須將某些東西扔掉。我們做Trunk.ly也是沿路扔了不少東西，而且每次也都是在實在沒有辦法不得不這樣做的情況下采取的這項行動。

　　InfoQ：這些優(yōu)秀的架構(gòu)給你的工作帶來的怎樣的影響？

　　Alex：對于這個問題，我想通過《設(shè)計模式》來談一談。我讀這本書大約是在8、9年前的事情了，當(dāng)時的第一感覺是，這些模式設(shè)計得真是不錯，真的很好。由于當(dāng)時我用C++/C#的機(jī)會比較多，在之后的幾年里，我都盡量地去使用它們。可后來我認(rèn)識到，這些模式其實是只是一種規(guī)則。我覺得最理想的，作為架構(gòu)師，你在讀這些規(guī)則或者是在用這些規(guī)則的時候，要知道這些規(guī)則之后的規(guī)則是什么。然后將這些背后的規(guī)則去用到自己的工作中，而不是單單生搬硬套，為用而用。

　　也就是說，我希望架構(gòu)師能夠理解這些規(guī)則之所以呈現(xiàn)在這個樣子的原因。一名優(yōu)秀的架構(gòu)師，當(dāng)然是要多看別人設(shè)計的架構(gòu)，但是在看的同時，需要了解到使其架構(gòu)成型的現(xiàn)實的限制和現(xiàn)實的原因。除去你看到的架構(gòu)本身，你需要看到一種動態(tài)的架構(gòu)，知道其背后的推理和它的思維。這樣，等遇到問題時，就可以應(yīng)用這些思維方式，而不是簡單的應(yīng)用架構(gòu)。以Trunk.ly的后臺搜索引擎的存儲為例，到目前為止總共經(jīng)歷了4次大的變更，從最初的MySQL，到Sphinx，到Lucene和Solar，再到目前的HyperTable。每次修改都是因為我們知道我們遇到了哪些問題，又因為知道業(yè)界都有哪些解決方案，每個解決方案的優(yōu)缺點是什么，最后有針對性的進(jìn)行抉擇和行動。我舉這個例子想說明，正是因為我關(guān)注業(yè)界目前的動態(tài)，以及每種解決方案的優(yōu)缺點，這樣，當(dāng)我遇到問題時，我就能想得起來去用它們。而作為架構(gòu)師，是需要通過這種方式去建立起自己的工具箱，而不是單單讓自己的手中就握著個錘子。

　　InfoQ：前面你曾提到相比起架構(gòu)本身，你對于導(dǎo)致當(dāng)前架構(gòu)成型背后的人和故事更感興趣。能詳細(xì)談?wù)剢幔?/strong>

　　Alex：我覺得這是件挺有意思的事情。當(dāng)你做架構(gòu)做到某一天，就會遇到所謂“治理（Governance）”的挑戰(zhàn)。尤其對于開源軟件，在這樣一種松散的組織結(jié)構(gòu)，誰也不能將自己的設(shè)計理念強(qiáng)迫別人接受的條件下，要保證設(shè)計目標(biāo)的達(dá)成、版本、特性不斷地推陳出新，這時所面臨的挑戰(zhàn)和協(xié)調(diào)的藝術(shù)，要遠(yuǎn)比企業(yè)內(nèi)實現(xiàn)同樣目的要難得多。大部分的開源軟件，到最后都會有一個所謂的“善意的獨裁者（benevolence dictator）”，他們來決定特別艱難的決定該如何做。但是，不同的人做“獨裁”決定的時候會特別的不一樣。

　　像Linux社區(qū)，這個“獨裁者”會要求你在郵件中把自己的設(shè)計理念講得特別清楚，然后他會通過郵件來進(jìn)行討論。但像Python就不一樣，它一開始就確定了一些理念。作為社區(qū)，如果你要貢獻(xiàn)源代碼就必須承認(rèn)它們，否則就不會被接受。還有一些開源軟件則采用了“不同意就fork”的道路，假設(shè)一兩年之后，他們覺得這些fork不錯，這些fork還有可能會重新被接受。比如Python社區(qū)就有幾個著名的fork，如pypy，它是用Python來寫Python，現(xiàn)在的性能也越來越好了。

　　通過看這些開源社區(qū)的意見領(lǐng)袖如何用“非強(qiáng)制”的手段來保證架構(gòu)的一致性，消除意見分歧，我覺得是一件特有意思的事情。這就類似在現(xiàn)場看一個直播，對我來講這比起架構(gòu)本身成為什么樣子要有意思得多。而且在這個過程中，你也可以了解這些軟件解決方案誕生的全過程，大家對于問題/特性應(yīng)用場景的討論和投票，給你帶來一種參與感，這是特別過癮的一件事情。

　　InfoQ：剛才說了那么多其他人的故事，現(xiàn)在是不是可以說一下你們自己的故事？談?wù)凾runk.ly經(jīng)歷了幾個階段，每個階段都有哪些，未來它準(zhǔn)備朝什么方向發(fā)展？

　　Alex：做創(chuàng)業(yè)公司是有兩個階段的。第一個階段是摸索階段，在這個階段，我還不清楚我的商業(yè)模式是否行得通，不知道今天的用戶是否就是給我?guī)硎找娴哪切┯脩簟＿@個階段是非常重要的，英文叫做“product/market fit”，在之前的所有架構(gòu)都不是為了架構(gòu)本身，也不是為了站點的Scale，而是為了能讓我盡快的去做實驗，更快地驗證我的假設(shè)。

　　InfoQ：更像一個原型？

　　Alex：是的，但它不是那種可拋棄的原型，因為我沒有這個奢侈去把它拋棄重頭再來。我們在去年12月份Trunk.ly上線的時候，我們對其的定位是一個書簽服務(wù)，但它是一種透明的書簽服務(wù)。跟傳統(tǒng)的delicious不一樣的是，你不需要顯式地給它去打標(biāo)簽，它會自動收集你在Facebook、Twitter和Delicious上共享的鏈接，把它們弄進(jìn)去進(jìn)行全文檢索。這樣，當(dāng)你想找以前的鏈接時，你可以通過我們的搜索引擎去找到它。所以，在第一階段時，為了滿足這個商業(yè)目標(biāo)，我們就拿Django和MySQL快速地把它給實現(xiàn)了。后來數(shù)據(jù)庫就有點頂不住了，于是就換成了MongoDB，同時有一部分功能就采用了異步的方式實現(xiàn)。

　　接下來，我們發(fā)現(xiàn)之前的商業(yè)目標(biāo)雖然不錯，但是這個市場的價值并不是特別的大。然后，通過日志和分析用戶的行為特征，我們發(fā)現(xiàn)有些用戶經(jīng)常會去看別人共享了哪些鏈接，所以我們很快就增加一個Timeline的功能，這樣你在一個地方就能看到你關(guān)注的人每天都共享了哪些鏈接，這樣用戶就不用跑到每個人那里去看了。這個時候，關(guān)于網(wǎng)站的商業(yè)目標(biāo)和定位就有了一點點的變化。這個時候，我前面說的那些網(wǎng)站的論文提供了一些幫助。而且，這個時候大概每周都有百分之二三十的用戶增長，比起原來要快多了。而且，很多人會邀請他的朋友來注冊Trunk.ly。你要是在Twitter上搜索trunkly，你會看到每天有四五十條這樣的信息，這就是我們的第二個階段。

　　第三個階段就是我們發(fā)現(xiàn)這個市場還是不夠大。因為，要想把Trunk.ly做成一個讓人們每天都來的地方，這樣做的市場開銷特別大，而且不是每個人都有這樣的需要。所以，我們開始著手做Social Search。與Google這樣把所有人的鏈接都搜索出來不同，我們的這個功能允許你搜你朋友的鏈接，這樣搜出來的結(jié)果相比起前者來講要更準(zhǔn)確，而且跟你的相關(guān)性更強(qiáng)。我自己在測試這個功能的時候，也經(jīng)常因此而“走神”，開始訪問起那些鏈接的內(nèi)容來。

　　在這個功能完成上線之后，我們還準(zhǔn)備做的一件事情是“Topic”，即允許用戶自己來建立自己的主題頁面和鏈接。我們相信，從廣告和利潤分成來說，這對我們是一個非常大的市場。從我剛才說的這些內(nèi)容，你可以看出Trunk.ly的整個發(fā)展過程。我們目前還處在“product/market fit”之前，我想如果一旦證明我們設(shè)想的商業(yè)模式是正確的話，可能架構(gòu)還要再變，到時候可能就會更Scalable一些，而且架構(gòu)挑戰(zhàn)也就不一樣了。

　　InfoQ：對于未來的互聯(lián)網(wǎng)架構(gòu)師，作為過來人，你有什么經(jīng)驗之談是值得他們注意和避免的？

　　Alex：我想我上面講的內(nèi)容應(yīng)該已經(jīng)是我的經(jīng)驗之談了。如果非要總結(jié)的話，那就是，視野放寬一點，不要手里拿著榔頭就滿眼盡看到釘子；另一點就是好的架構(gòu)都需要一個過程，多關(guān)注一下架構(gòu)背后的事情。這就是我能想到的經(jīng)驗之談，也不是什么非常了不起的道理。

　　InfoQ：非常感謝你能抽空接受我的采訪，謝謝！

　　Alex：不客氣。