重构 TekPub——从 ASP.NET MVC 框架迁移到 Ruby on Rails

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

译者简介：池建强，12 年软件从业经验，先后在洪恩软件和用友集团任职。目前在用友集团瑞友科技 IT 应用研究院任副院长，负责公司基础应用平台的研发和整个公司的技术管理。主要关注领域：企业应用软件平台研发、领域驱动设计，OSGi，动态语言应用、云计算、移动互联等相关技术。

感谢霍太稳对本文的审校。

给InfoQ 中文站投稿或者参与内容翻译工作，请邮件至 editors@cn.infoq.com 。也欢迎大家加入到 InfoQ 中文站用户讨论组中与我们的编辑和其他读者朋友交流。