为什么不能通过像Facebook这样的网站添加服务器来扩展Twitter?

Jas*_*son 51 ruby twitter scala ruby-on-rails

我一直在寻找解释为什么Twitter必须将部分中间件从Rails迁移到Scala的原因.是什么阻止了他们扩展Facebook的方式,通过添加服务器作为其用户群扩展.更具体地说,Ruby/Rails技术阻止了Twitter团队采用这种方法?

vir*_*yes 57

并不是说Rails不能扩展,而是在Ruby(或任何解释语言)中对"实时"数据的请求不能扩展,因为它们在CPU和内存利用率方面比编译语言对应物要贵得多. .

现在,Twitter是一种不同类型的服务,一种具有相同庞大的用户群,但服务的数据变化较少,Rails可能是一种可行的选择,通过缓存; 即完全避免对Rails堆栈的实时请求并卸载到前端服务器和/或内存数据库缓存.关于这个主题的优秀文章:

Basecamp Next如何变得非常快

然而,Twitter并没有放弃Rails单独扩展问题,他们做了转换因为Scala作为一种语言,提供了一些关于应用程序状态的内置保证,解释语言无法提供:如果编译,浪费时间等错误肥胖的错别字,不正确的方法调用,不正确的类型声明等根本就不存在.

对于Twitter TDD还不够.Dijkstra在Scala编程中的一句话说明了这一点:"测试只能证明存在错误,而不是存在错误".随着应用程序的增长,他们越来越难以追踪错误.神奇的神秘之旅正在成为一种超越表现的障碍,所以他们做出了转变.从各方面来说,取得了巨大的成功,Twitter对于Scala来说Facebook对PHP来说是什么(尽管Facebook使用他们自己的超快C++预处理器,所以作弊有点;-))

总而言之,Twitter为性能和可靠性做出了改变.当然,Rails往往是创新的最前沿,因此99%的非Twitter级别的被贩运应用程序可以通过解释性语言得到很好的解释(尽管我现在已经完全处于编译语言的一面) ,Scala太好了!)

  • 让我先说我真的很喜欢Scala,尽管我还是一个Ruby人.关于Dijkstra算法和静态类型的感知优势,我有套用丰富希基,谁说什么生产力软件的所有错误的共同点是,他们得到了过去的类型检查和单元测试.BTW:Facebook的HipHop是用C++编写的,而不是C. (2认同)
  • @MichaelKohl嗯,Rich Hickey很方便地没有提到所有带bug的程序有一个共同点:它们没有被证明是正确的.当然,由于他的城堡是基于所有程序都有错误的前提,所以它不适合他的演示,现在呢? (2认同)

小智 11

没有平台可以无限扩展,同时仍处理随时变化的复杂数据集.语言和基础设施很重要,但是如何构建站点以及数据访问模式更重要.

如果您曾经玩过像运输大亨或定居者这样的游戏,您必须在这些游戏中运输资源,那么随着使用量的增加,您将了解如何在升级基础架构时保持最佳状态.

像Facebook和Twitter这样的扩展平台是一项永无止境的任务.您拥有越来越多的用户,并且正在推动您添加更多功能.这是一个升级一位的持续过程,这会对另一位产生更大的压力.

向服务器投掷问题并不总是答案,有时可能会导致更多问题.


Dan*_*man 9

http://highscalability.com/scaling-twitter-making-twitter-10000-percent-faster链接到一组关于变化的帖子,包括随着时间的推移所采取的步骤的体面历史.

简短的版本是Ruby和Rails没有提供服务所需的性能和可靠性.鉴于规模,这并不奇怪; 大多数COTS解决方案在规模超大的情况下并不令人满意.

高可伸缩性涵盖了很多关于高端架构的问题,对于其他站点,因此也有助于回答该领域中更广泛的问题.


sos*_*orn 5

他们可能会在这个问题上抛出更多的硬件,但这比编写更高效的代码要便宜得多.像许多高级框架一样,Ruby on Rails在许多方面都很出色,但高性能并不是其中之一.编译语言总是比解释语言更快.

  • 如果你比较用新语言重写一个有点实际的应用程序的成本和今天可笑的低硬件价格,我会小心地假设"简单地"编写更高效的代码总是更便宜. (4认同)
  • 在这种特殊情况下,如果你阅读了访谈,很明显地说这是一个语言表现问题. (2认同)