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 中文站用户讨论组中与我们的编辑和其他读者朋友交流。
活动推荐:
2023年9月3-5日,「QCon全球软件开发大会·北京站」 将在北京•富力万丽酒店举办。此次大会以「启航·AIGC软件工程变革」为主题,策划了大前端融合提效、大模型应用落地、面向 AI 的存储、AIGC 浪潮下的研发效能提升、LLMOps、异构算力、微服务架构治理、业务安全技术、构建未来软件的编程语言、FinOps 等近30个精彩专题。咨询购票可联系票务经理 18514549229(微信同手机号)。
评论