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

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

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

　　InfoQ：作為互聯網的創業者，在同行業中有哪些站點的架構會引起你的注意，讓你覺得值得欽佩？

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

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

　　InfoQ：是的，架構本身也是動態發展而來的。人本身有其自身的缺陷，很難設計出來一種面面俱到，一勞永逸的架構。就架構決策而言，應該是架構師在當時環境所能做出的最好決策了。隨著時間的發展，周圍的環境也會發生變化，這時就需要他來根據環境進行調整。

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

　　InfoQ：那么做架構決策時，就有點像權衡各方面的因素，從而使架構達到一個比較好的狀態？

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

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

　　InfoQ：的確，每種工具或架構有其本身適應的環境或者說是前提條件。假設你當前應用的環境跟這個前提或環境有沖突時，就會造成你剛才所說的那種在應用上非常痛苦的一面。

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

　　InfoQ：這些優秀的架構給你的工作帶來的怎樣的影響？

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

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

　　InfoQ：前面你曾提到相比起架構本身，你對于導致當前架構成型背后的人和故事更感興趣。能詳細談談嗎？

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

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

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

　　InfoQ：剛才說了那么多其他人的故事，現在是不是可以說一下你們自己的故事？談談Trunk.ly經歷了幾個階段，每個階段都有哪些，未來它準備朝什么方向發展？

　　Alex：做創業公司是有兩個階段的。第一個階段是摸索階段，在這個階段，我還不清楚我的商業模式是否行得通，不知道今天的用戶是否就是給我帶來收益的那些用戶。這個階段是非常重要的，英文叫做“product/market fit”，在之前的所有架構都不是為了架構本身，也不是為了站點的Scale，而是為了能讓我盡快的去做實驗，更快地驗證我的假設。

　　InfoQ：更像一個原型？

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

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

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

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

　　InfoQ：對于未來的互聯網架構師，作為過來人，你有什么經驗之談是值得他們注意和避免的？

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

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

　　Alex：不客氣。

it知識庫：Trunk.ly CTO董洵談架構，轉載需保留來源！

鄭重聲明：本文版權歸原作者所有，轉載文章僅為傳播更多信息之目的，如作者信息標記有誤，請第一時間聯系我們修改或刪除，多謝。