TekPub是一個面向開發人員的站點，致力于為開發人員提供一系列主題的在線培訓，主題范圍非常廣泛，從微軟的O/R Mapping框架Microsoft Entity Framework，到如何使用Ruby on Rails技術編寫自己的日志引擎等內容都有涉及。該網站是由前微軟員工Rob Conery與Lounge的老板James Avery創立的。

　　TekPub是個很有趣的學習案例，公司開始時使用ASP.NET MVC框架，之后很快遷移到了Ruby on Rails上。InfoQ與Rob和James探討了這次遷移之旅。

　　InfoQ：和我們談談TekPub吧，對于哪些不熟悉你們的產品的讀者，TekPub意味著什么？

　　James Avery（簡稱JA）：TekPub為程序員提供了高質量的技術視頻演示。我們的目標是幫助一些人在幾個小時內學習一項新技術，主要方式就是觀看一些牛人的演講視頻。他們對演講的技術非常了解，演講內容不僅僅覆蓋基礎知識，還深入到了這些具體技術在真實項目中的應用。與其等幾個月才拿到一本很可能已經過時的書，還不如訂閱我們的產品立刻獲得新技術的提升。我們已經完成ASP.NET MVC 2的系列視頻，但目前還沒有與這個主題相關的書籍。

　　InfoQ: James Avery和Rob Conery有什么來頭？

　　JA：除了TekPub之外，我還搞了幾個科技創業公司。我運營了Lounge和Ruby Row廣告網絡，分別關注.NET和Ruby開發人員。我還幫助運營DotNetKicks公司，一個.NET開發人員的社區網站。我最新的關注點是Adzerk，這是我自己構建的Web服務器，用來有效的運行Lounge和Ruby Row，讓其他人來使用。從90年代中期我就開始使用Web，.NET發布后，我開始轉移到微軟的技術上。最近我一直再用.NET、Ruby on Rails和MongoDB等，還有任何讓我感興趣的技術。

　　Rob Conery（簡稱RC）：我自1991年以來一直從事軟件行業，做一些數據庫，CGI和HTML之類的開發。從1997年開始使用ASP，從那之后一直堅持使用微軟技術。2006年我開始為微軟工作，主要職責是幫助人們學習和使用新的ASP.NET MVC框架。2009年我離開了微軟開始做些不同的事情（更多的關注開源平臺），之后和James Avery一起創辦了Tekpub。

　　InfoQ：能介紹一下你們剛創業時TekPub的架構嗎？

　　JA：TekPub的第一個版本是基于Ruby on Rails構建的，當時Rob花費了整整一個周末的時間。之后我們仔細的進行了討論，最終決定放棄這個版本。由于我們都很了解ASP.NET MVC技術，所以決定用ASP.NET MVC來實現TekPub。我相信，當開始一項新業務時是沒有時間嘗試和學習新技術的。Rob和我過去都寫過Rails應用，但真正使用時，我們都覺得ASP.NET MVC比Rails好得多。于是我們放棄了Rails轉而使用ASP.NET MVC技術開發網站。后來我們取消該站點并重新構建它，因為它已經變得太復雜。在我們開始進行技術遷移時，TekPub的版本是3，主要技術是ASP.NET MVC，C#和MS SQL Server。

　　InfoQ：從網站使用者的角度你遇到了什么樣的挑戰？從網站管理者的角度呢？

　　RC：最初，或者說網站運營的第一天，我們就遇到了網絡帶寬的問題。我們在Twitter上宣布網站開張，這直接導致我們的ISP由于帶寬的需求被淘汰。他們毫不夸張的讓工程師“坐在開關上”來保證網站的正常運行，但最終網站還是停了。之后兩小時內我把我們所有免費的內容都放到了亞馬遜的S3上，這對我們幫助非常大。

還有，一小部分人不喜歡Silverlight，不愿意安裝它。我們在Reddit上投放了廣告，人們卻簡單的認為我們的網站是微軟資助的一個什么東西——這是和我們的目標背離的。對我們來說這是個大問題。

　　JA：ASP.NET MVC運行的很好，Windows架構也不錯。事實上我們在這個領域沒碰到什么麻煩。主要的挑戰來自于我們決定使用Silverlight播放流媒體。很多用戶不愿意安裝Silverlight，這給我們帶來很大的困擾。與Rob確認后，我們不得不遷移到Flash技術。遷移到Flash之后還沒有一個人抱怨過。我們希望HTML5很快面世。

　　InfoQ：架構如何應對用戶需求？

　　RC：我們從來沒有遇到底層框架的問題——它處理的很好。這并不是一個負載非常大的網站（在功能方面），所以我們從沒真正遇到那方面的問題

　　InfoQ：既然平臺運行的非常好，為什么要做架構的改變呢？

　　RC：成本。我們加入了微軟的BizSpark計劃，而且它的確給了我們一個很棒的起點，但是隨著項目的發展，我們發現，3年以后，從我們使用的數據庫到開發環境，每一件事情都需要付費。而且我們很可能需要為Silverlight（使用流媒體）提供一個分離的服務器，用來播放視頻，這樣就需要再支付一個使用許可的費用——此外，為了使視頻流平滑輸出，我們還需要買媒體編碼器。

　　對于大公司來說，這的確不算什么，但當我們坐下來看帳單時——噢，這可是個5位數啊。最終我們發現，根據我們現有的業務規模，是無法承擔這筆費用的。

　　不僅僅如此，James和我都清楚Rails非常好用。我們意識到可以把所有事情都推到云端，只需支付很低的價格就可以獲得很好的流媒體和吞吐量。

　　JA：正如Rob提到的，成本壓力是其中一個因素，BizSpark是很好，但卻像一個定時炸彈。我覺得比成本更重要的推動因素是每天我們希望使用什么技術。ASP.NET MVC和.NET技術在某些領域是有缺陷的，而這些領域的工作對我們非常重要。在.NET上做測試就并不讓人滿意，你不得不大費周章才能以正確的方式設計你的應用，處理測試，而且編寫測試本身也不像其他語言那么清晰和有用。另一個問題是部署，雖然有很多種方式可以處理，但確實不如Capistrano好用。

　　InfoQ：那么現在TekPub平臺是什么樣子的？

　　RC：我們遷移到Rails 2.3.5，使用了針對MongoDB的MongoMapper技術。我們做了一個報告設置，用MySQL來跟蹤反饋使用DataMapper的情況。我們還植入了New Relic RPM，來跟蹤我們的站點和健康情況——所有的這些，平均成本僅僅是我們使用BizSpark的1%。

　　JA：這解決了我們所有與使用許可有關的問題，我們每月需要為Amazon EC2平臺上的一個Ubuntu實例支付$80，這是保留實例后的費用。Rob和我都很喜歡這種技術，我們使用Cucumber做了大量測試，用Capistrano部署變得非常簡單容易。

　　InfoQ: 能給我們講講你們的技術架構細節嗎？

　　RC：使用Rails 2.3.5及其對應的MongoMapper/MongoDB，使用MySQL 5.2和O/R Mapping工具DataMapper。我們還用了New Relic RPM工具，非常棒。

　　JA：我們選擇使用Rails 2.3.5和Ruby 1.8.7，通過Passenger運行Rails應用。在數據庫方面，我們通過使用優秀的MongoMapper gem訪問MongoDB 1.3.4。我們還通過DataMapper實現MySQL 5.1的數據訪問。我們并不使用很多其他的Gem，只是用Pony發郵件，rpx_now訪問RPX做身份驗證。同時我倆還都是HAML的愛好者，所有的界面都是基于HAML實現的。

　　InfoQ：你們的EC2怎么配置的？

　　JA：所有的內容都是托管在云端，相當于一個比較小的服務器，也就是一個單獨的EC2實例（虛擬雙核，2個計算單元，7G內存）。在這個實例上運行著Ubuntu 9.1（karmic）和Apache。我希望未來有更多的資源，你知道，運行在EC2上，想增加資源是非常容易的。

　　InfoQ：為什么選擇Ruby on Rails？

　　RC：James和我都知道，插件的世界是非常吸引人的。例如New Relic，簡直是上帝送來的禮物。我不擔心服務器掛掉，而且我能看到所有代碼的“瓶頸點”。他們還能跟蹤最高發生頻率的問題，甚至會提出改進意見。

MongoMapper是一個令人難以置信的數據工具，而MongoDB本身的速度比閃電還快。Rails的平臺已經成熟到了這樣的地步，幾乎難以說服自己*不*使用它。

　　JA：我們遇到的所有問題（使用許可、測試和部署）都得到了很好的解決。我們還能使用一些變通的辦法，例如寫自己的部署框架等。隨之而來的是我們都很享受與Rails工作，我們喜歡Rails社區，還有很多工具和類庫可用。經過遷移之后最棒的地方就是，這一切讓我們變的非常高興。

　　InfoQ：相對很多傳統數據庫例如MySQL或者PostgreSQL，你們為什么選擇MongoDB？

　　RC：速度和擴展性。使用MongoDB非常簡單——不用擔心遷移，非常靈活。而且它不可思議的快——這一點對用戶帶來的感受是巨大的。

　　JA：事實上我們都用了，我們用MongoDB做那些它最擅長的（靈活存儲產品、用戶和訂單等信息），同樣我們也這么使用MySQL，我們用MySQL提供正在發生的持久事務日志。

　　InfoQ：完成了新的設計和重寫應用之后，最直接的好處是什么？

　　RC: 最直接的——第一件事就是人們發現網站變快了。他們還注意到一個“更嚴格”的設計，誠實的說，確實有些繁瑣，但它讓我們能更多的關注服務器端。

　　不僅僅如此——當出現問題時，我們可以在幾秒鐘之內消除它。這是由于基于Capistrano的部署是如此簡單。問題的修復、推出——僅需幾秒。

　　我們的測試套件使用的非常好——使用Cucumber做一些事情簡直是一種享受，但用ASP.NET MVC就會很困難。例如——使用ASP測試PayPal的支付接口時就會很麻煩。

　　基于Rails/Cucumber/Webrat，在這樣的框架下要做的就是填空并提交——然后確認所有事情都是按照計劃執行的。我想我們的用戶會看到很多功能在按照預期的方式運行——這確實很棒。

　　最直接的好處是我們想做一些變化時，可以快速完成，并且這種響應速度直接反應到了產品上。在原來基于ASP.NET MVC技術的網站上，我經常會寫些SQL腳本來處理一些復雜的支持需求，比如改變某人的OpenID，或合并帳戶什么的。但現在我只需花30-60分鐘的時間寫了幾行的Ruby腳本就能完成。

　　在重寫網站過程中另一個重大的改變之一是如何處理用戶的文件。過去我們從自己的服務器或運行在EC2上的Wowza媒體服務器上以流的方式處理文件。這兩種方案都可以，但是太貴了，而且在其他國家就運行的沒那么好了。這次我們開始重新設計亞馬遜服務，提供了從云端和云端流來處理私有內容的能力。現在我們的全部內容都是通過云端處理，并使用了安全簽名的URL，這就意味著世界上任何地方的用戶都可以進行高速下載。這也節省了我們的成本，因為我們只需支付使用帶寬的費用，不需要額外的設備或許可費用。

　　InfoQ: 在你們當前的實現中，TDD測試方法包含哪些內容，引入模擬對象了嗎？

　　JA：我們用Cucumber和Pickle實現測試驅動開發。這方面Rob應該比我更清楚。

　　RC：沒有進行模擬測試，都是BDD（行為驅動開發）。我痛恨那種拖拉的感覺，就像我需要做“代碼覆蓋率”一樣——事實上我們有個商業應用在運行，我更需要確認用戶獲得良好的體驗，這對我來說就是BDD。Cucumber扮演了一個真正的重要角色——就像Pickle和Factory Girl做的那樣——它與MongoMapper配合的好極了，對比我在微軟框架下做的和我現在能做的事情，這讓我高興的笑了好幾次。我幾乎完全在考慮業務——甚至沒有注意到測試方法這回事。

　　InfoQ: 你們現在的測試方法和以前在微軟使用的方法有什么不同？

　　RC：100%不同。測試微軟的東西是極其痛苦的，當時你很窮，還有三個月錢就花完了，在這種情況下，測試就是變成了一個很難判斷的的東西。不可否認——我為我們的第一次修改幾乎寫了一噸的垃圾。如果你沒有客戶，那么你的應用系統好不好用就無關緊要，我真正需要確定的是不出現那些不可預期的錯誤。所以我進行了一些測試，但并沒有得到想要的結果。我們對PayPal的東西進行了大量地測試，這是你必須要做的。當開始使用他們的API時，我在他們的沙箱環境中折騰了整整三天，還是會不斷的出問題。

　　另一邊呢——感覺是黑夜和白天的對比。現在我們覆蓋了所有的行為類型，我想James甚至抽時間寫了一些。

　　JA：對微軟產品的測試總是像打一場戰爭，主要是因為C#和靜態語言對測試的支持不是很好。在.NET上測試時你總是需要在各種循環中跳來跳去。話雖這么說，.NET的SpecFlow框架看上去還是很樂觀，但我對它能解決.NET的測試方面的所有問題持懷疑態度。

　　InfoQ: 在微軟框架上做測試會有多少困難？為什么會這樣？

　　RC：語言和工具造成的。假如微軟對這一點想的多一些，測試可能會更容易一些。使用RSpec進行測試，沒有其他語言比Ruby做得更好了——它讓測試變得非常容易。微軟可以利用DLR實現這些功能……但是他們沒有這么做。因為這不符合“.NET Story”，那么好吧，這是他們的商業決策，我們這次的遷移也是一樣。

　　InfoQ: 在這次全面的重新設計中，你們有什么經驗教訓嗎？

　　RC：沒什么——我想James和我都知道，我們到了需要調整和重寫的那個點。這是我的第三次創業，對James來說應該是第五次。開始時我們經過很長的時間討論采用什么技術。我們都同意我們要“跟隨你所知道的，并且去實現它”——于是我們就做了。

　　我們很幸運把握住了這個機會——然后我們進入了這樣一個狀態：“好吧，讓我們開始為之后的3-5年規劃，進入可控的增長模式”——這就是我們現在的狀態。我們不想做得很大，我們不想引入IT人員或一組開發人員。我們想自己做而且保持小的規模——重點放在了我們的創意上。

　　對于我們這樣的兩個家伙來說，Rails超級簡單，易于維護。我們有世界上最可靠的支撐（可自動擴展的亞馬遜EC2），我們對正在做的事情非常滿意，獲得了很多樂趣。

　　JA：我想大部分人看到這個故事，會認為我們應該從開始就使用Rails，事實上我很高興我們沒有那么做。開始創業時我想我們要相信自己的直覺，哪些是當時我們認為最好的，我們應該關心所有的業務問題，而不是使用什么工具。現在業務已經正常運轉，在這樣一個堅實的基礎之上，我們就有了很多美妙的時光，釋放內心的渴望做一些好玩的事情。平臺移植讓我們享受了很多樂趣。

　　InfoQ: 你們現在的架構有什么缺點嗎？如果今天開始重新做一遍的話，有什么改變嗎？

　　RC：從我的觀點來看沒什么——我愛現在的一切。對我來說這很不可思議——我在很長一段時間內曾是一名微軟員工，并被扣上了這樣一頂帽子……其實這對我們來說并不意味著什么。我非常喜歡硬件成本的可擴展性——我想在很長時間之內我們不再需要其他的硬件方案了。我們的服務器非常靈活，完全根據需求動態擴展。使用微軟技術你就沒法做到這些（據我所知），如果你想搞一臺獨立的機器，那你就需要支付一大筆款項。

　　JA：針對現有架構，我唯一想做的改變就是把MongoDB從我們的單一服務器上分離出來，同時運行兩個MongoDB對我們來說是有意義的，但現在這部分功能被廢棄了，對我們來說更有意義的事就是等MongoDB開發新的配對策略。但是考慮到額外的兩個虛擬機的成本，以及我們的業務在現有的單一服務器上運行良好，我們暫時還不準備這么做。

　　InfoQ: 感謝Rob和James抽時間接受我們的訪談。

　　關于TekPub的更多信息，請參考公司網站。

　　查看英文原文：Architecting TekPub - Moving from ASP.NET MVC to Ruby on Rails