大规模视频网站的计费与流量管理
本次分享将会就大规模视频网站的计费与流量管理这个话题，从操作层面细细进行讲解和分析，为系统工程师们揭示平日里我们没有关心的另一些内容。同时也希望本次分享能揭示行业中的一些“潜规则”，让互联网行业的流量与带宽管理更为开放与简洁。
本次演讲视频录制于QCon杭州2011。
技术访谈
该内容已经被标记书签！
标记书签错误，请重试！
与Ola Bini一起探讨JRuby
受访人 Ola Bini 采访人 Fernandez 翻译：贾晓楠 发布于 2008年4月17日 长度 00:14:38
概要
Ola Bini谈论了JRuby，一种用Java写的，运行在JVM上的Ruby实现。除此之外，Ola还表达了他对Ruby社区的欣赏，并分享了他对Ruby 社区与Java社区的不同之处的看法。他还简要的讨论了关于Ruby的未来的看法，特别是它有潜力融合一些来自Lisp的强大功能。
个人简介
Ola Bini效力于ThoughtWorks，最近写了“JRuby on Rails实践”一书，并由Apress出版。他对人工智能、Lisp、Ruby，以及不同语言之前模糊的界限非常感兴趣。Ola的博客在http://ola-bini.blogspot.com/
Ola Bini谈论了JRuby，一种用Java写的，运行在JVM上的Ruby实现。除此之外，Ola还表达了他对Ruby社区的欣赏，并分享了他对Ruby 社区与Java社区的不同之处的看法。他还简要的讨论了关于Ruby的未来的看法，特别是它有潜力融合一些来自Lisp的强大功能。
个人简介
Ola Bini效力于ThoughtWorks，最近写了“JRuby on Rails实践”一书，并由Apress出版。他对人工智能、Lisp、Ruby，以及不同语言之前模糊的界限非常感兴趣。Ola的博客在http://ola-bini.blogspot.com/
我叫Ola Bini，来自瑞典，在ThoughtWorks工作。我是JRuby的核心开发者之一。也是“JRuby on Rails实践”的作者，这本书在上个月由Apress出版了。
这本书对JRuby and Rails做了实践性的介绍。它是基于项目的，也就是说你不会读到所有的理论，而会看到很多实用的例子来介绍JRuby的集成、如何使用JRuby和 Rails，以及怎样在Rails中结合Java环境中的企业级的东西；做一些东西，比如XML，但不使用Ruby的XML库，还有与企业级应用EJB的互动，诸如此类。
我都做些什么呢，通常在团队中我主要负责扩展部分，因为JRuby需要用C扩展来重新实现所有的计算部分；这是整个实现中相当大的一部分。而这就是我所做的大量工作的一部分。一年半到两年之前，我开始重新实现Ruby的YAML库，从那时开始我一直在做很多东西。我是负责ActiveRecord JDBC的成员之一，这个组件让Rails可以使用JDBS驱动。我参与了这个实现的所有部分，而这才是关键。最近我也致力于正则表达式引擎，和其他人一样，我主要在修正各种错误。
这里的问题是Java的正则表达式引擎是一个很好的引擎，但是它不符合Ruby的工作方式。而我们需要让这个实现具有完全的兼容性，不论你能想出什么办法来呈现错误。我们最开始发现的一个真正问题来自于负责转换多数据的Rails正则表达式。它在Java中崩溃了，因为它使用了采用递归算法的Java正则表达式引擎来对付大量的特殊正则表达式，结果把堆栈给挤爆了。因此我们决定寻找另一种方案，我们使用了JRegex一段时间。当我们发现它时，它已经停止更新了。它具备我们需要的所有特性，它比Java正则表达式引擎要快，最重要是的，它本身不是递归的。因此我们很喜欢它，并修正了它的一些错误，用它作为我们主要的正则表达式引擎，用在1.0发行版以及1.01、1.02和1.1 beta 发行版中。它是个好的引擎，但我们也开始遇到一些它还不够适用的地方。在那些情况下，我们指结果上，会有一些特殊的情况，引擎无法找到结果……一个典型的例子是：比如你有一个很长的字符串，还有一个正则表达式来进行回溯查找，而正则表达式的一部分是常量串。如果在长字符串中找不到这个串，MRI就会在那之前停下来，它不会试图回溯地查找整个字符串，因为不管怎样，正则表达式都不可能匹配。而JRegex不是这么做的，因此在某些情况下，有的正则表达式会把我们的引擎搞崩溃。
是的。我们很喜欢它，并把它放进了我们的存档。我们一直在加入、取消并发布各种更新，但由于我们已经做了很多东西了，并且我们在引擎中加入的其他一些东西都是专门针对JRuby的，因此我们曾被迫去掉一些不太符合Ruby引擎的特性。
Oniguruma 是MRI和Ruby 1.9采用的下一代的正则表达式引擎。它是完全国际化的，基本上能够支持所有你能想到的多字节字符和编码。它还支持一些真正高级的特性，比如名称组、向前找、向后找之类，能使得递归正则表达式变得很容易。它有一些非常好的特性。同时它也比现有的正则表达式引擎大得多。
我们正在计划并致力于重新设计我们的实现，来兼容1.8和1.9。我们主要看中典型的1.9特性。例如，1.9的case声明接受文本参数并在行间使用它，而不去调用具有更好表现的triple等式。但这相对于Ruby 1.8来说是一个很大的变化。我们要做的就是接受所有这些变化，差不多给每一个都加上标志，然后你就可以选择要使用1.9的哪部分了。作为让正则表达式兼容1.9的一部分工作，我们有一个团队成员致力于把Oniguruma移植到Java上。这是个有意思的工作，是个很庞大的移植，至今还没有完成，让我们拭目以待。它可能会是我们未来的主要正则表达式引擎。因此我们要做的就是当我们运行在1.8兼容模式时，我们就仅使用1.8这部分，这样就能得到和1.8 一样的功能了，希望这样也能解决性能的问题，也为正则表达式提供扩展性，就像MRI那样工作。
所以你是在一个独特的位置上，由于你在JRuby中的地位，你涉及的领域涵盖Java和Ruby两个阵营，同时也为ThoughtWorks工作。因此你接触了很多企业级应用的开发，并且你看到了挑战和对JRuby的接纳，但你又比我们其他人具有更强的理解力，我是说，对于JRuby将来的应用情况来看。你同意吗？
没错。从我开始以来到现在这段时间很有意思。很明显JRuby很适合企业级应用。在其他许多情况下，人们并不真的需要运行在Java上的能力，但企业级应用需要。很多时候，比如我们有很大的投资银行，他们不允许任何东西进入系统。你不能在他们的主框架和计算机中心里运行任何东西，如果它们不是Java的话。
在那种情况下，即使告诉他们它究竟是怎样工作的，它工作得很好，因为它运行在Java上，也是徒劳。但是在很少的情况下，有一次，我的一个同事Josh Graham跟我说了几天前他工作的情况。他为我们做一些JRuby的工作。有一个我们的客户，他大概是说他告诉那个客户：“这只是个Java项目。这些静态的文本文件只不过是配置信息而已。”我不一定同意那种小小的欺骗，但它的确起了作用。他们允许我们用更好更快的方法交付更多的功能，并且给客户带来转机。这对双方都有好处。
我想这不大可能。在某些阵营中，Java平台并不适用。例如一些典型的小规模脚本，你需要迅速执行，很短时间内就结束。在这种情况下，JRuby的启动时间是个问题，因为你需要先启动一个JVM，然后再启动JRuby，这都需要花不少时间。对此我们有一些解决方案。最近我们加入了一种叫做“nailgun”的机制，它在一些情况下能大幅改进启动性能。所以有很多方法。但是在许多情况下并不需要这么做。另一方面，如果JRuby真的变得非常快的话，在许多基准测试中，我们都已经比1.9要快了。但在其他基准测试中，例如典型的Rails基准测试，我们大多数情况下只快一点，但没有比正规的Ruby实现快太多。所以我认为如果我们能够扭转形势，相比Rails对这一类大型应用程序能大幅提高性能的话，则非常有助于JRuby的应用。可惜Ruby社区并不那么在意性能，而更在意把东西用尽可能最好的方式做出来。
这个问题真的很难。我只知道我非常热爱Ruby社区。毫无疑问Ruby社区是我曾参与的最好的社区，它非常棒，但是不好和Java开发者社区进行对比。他们属于完全不同的世界。我认识的Java应用开发者主要都是在企业级领域。我觉得大多数Ruby开发者都更有激情。这种激情和自豪感在Ruby社区和 Java社区中是不同的。我的个人感觉是，我发现Ruby开发者都很着迷于他们所做的事情，而且都为此而骄傲。而对于Java开发者来说，就算有人的确对社区做了很大的贡献，他们更偏向于认为那是他们工作的一部分。即使他们有激情，也和Ruby开发者不大一样。
我现在就做得很开心。JRuby的确很重要，但并非要终结所有的编程环境。而且我真的希望能看到Lisp能全力回归，那样我也很乐意投入其中。我现在的确没有时间做所有喜欢做的事情，但我知道我想做什么。而且我认为把一种语言比如Ruby融合到Java这样的平台上，并且再融合进一些Lisp的强大功能是非常有意思的事。要是我将来有时间的话，我会很乐意坐下来把不同语言的特性全部混在一起，建立起Ruby曾建立的东西，并把Ruby带入下一代语言，要比现在的Ruby还好。我现在不知道那会是什么样子的，但我知道一定会比Ruby要好。等着看看Ruby 2.0是什么样子的吧，那一定很有意思，很好玩，但我还是觉得肯定会有更好的。
Ola Bini的书将由图灵出版。
发表人
刘江 图灵
发表于
-
欢迎大家到图灵论坛参与beta评审：
groups.google.com/group/turingbook
1 条回复
关注此讨论 回复