大规模视频网站的计费与流量管理
本次分享将会就大规模视频网站的计费与流量管理这个话题，从操作层面细细进行讲解和分析，为系统工程师们揭示平日里我们没有关心的另一些内容。同时也希望本次分享能揭示行业中的一些“潜规则”，让互联网行业的流量与带宽管理更为开放与简洁。
本次演讲视频录制于QCon杭州2011。
技术访谈
该内容已经被标记书签！
标记书签错误，请重试！
录制于：
与林昊一起探讨OSGi
受访人 林昊 采访人 Jason Lai（赖翥翔） 发布于 2008年7月31日 长度 00:21:58
概要
在今年5月份的网侠大会上，InfoQ中文站有幸与国内OSGi的先锋林昊（BlueDavy）在一起探讨了OSGi的相关话题，包括它的优势、复杂度以及Java下的实现等等。
个人简介
林昊，三年前接触OSGi，目睹了OSGi从最初的不够受关注到现在几乎成为了各大应用平台厂商的必选，同时也得到了Sun的官方认可，而自己也随着对于OSGi的应用经验的增长，编写了《OSGi实战》、《OSGi进阶》两篇Opendoc，这两篇是目前OSGi领域中仅有的中文文档资料，国内不少公司、IT从业人士因为这两篇文档进入了OSGi领域，在去年通过和OSGi官方联盟交涉后拿到了官方联盟的授权，建立了OSGi官方认可的全球第6个User Group。
在今年5月份的网侠大会上，InfoQ中文站有幸与国内OSGi的先锋林昊（BlueDavy）在一起探讨了OSGi的相关话题，包括它的优势、复杂度以及Java下的实现等等。
个人简介
林昊，三年前接触OSGi，目睹了OSGi从最初的不够受关注到现在几乎成为了各大应用平台厂商的必选，同时也得到了Sun的官方认可，而自己也随着对于OSGi的应用经验的增长，编写了《OSGi实战》、《OSGi进阶》两篇Opendoc，这两篇是目前OSGi领域中仅有的中文文档资料，国内不少公司、IT从业人士因为这两篇文档进入了OSGi领域，在去年通过和OSGi官方联盟交涉后拿到了官方联盟的授权，建立了OSGi官方认可的全球第6个User Group。
大家好，我是林昊，网名BlueDavy。现在在淘宝工作。之前先后写了一些OSGi的中文宣传材料，包括OSGi实战、OSGi进阶——这两篇OpenDoc，主要是结合我自己的经验来推广OSGi在中国的应用，我大概也了解到，经过这两篇OpenDoc，中国也有一些公司开始考虑采用OSGi了，这是一件很好的事情。目前，我们主要是在筹办OSGi的中文官方站，这个是得到了OSGi官方认可的，全球第六个国家级别的User Group性质的站点。目前这个站我们还在进行之中，可能近期会全面对外公布，大概是这些。
好。 OSGI是一门存在了很长时间的一门技术。那么但是在近年来，在Java社区这里边，关于它的探讨、实现，然后以及应用已经越来越火热了，尤其在最近宣布的Spring Source Application Server里边更是以OSGI作为他的核心技术。作为国内在OSGI方面的先驱者，你还能不能跟不熟悉OSGI的这些读者介绍一下OSGI到底是什么吗？
是这样的，近来我们可以看到，几乎所有现在的应用服务器都已经宣称基于OSGi或者run on OSGI或者兼容OSGI， 像Spring的话，之前大概花了一两年的时间做Spring DM，但Spring之前一直都是基于他自己的IOC容器的，如果全面迁移到Spring DM的话可能还需要一段时间，但最近推出的Spring Source Application Platform是一个全新的东西，他基本上就已经开始全面采用Spring DM了，这个和以前的Spring的兼容方式是有点不同的。OSGI简单来讲，就像OSGI官方站上的一句话来描述话，OSGI是一个为Java提供的动态模块化的系统，这是一个他非常好的简称。
然而经过近两年的发展，OSGI已经逐渐在改变他的推广方式了，也就是说从以前的for Java开始不大提这个词，开始提他是全面的、统一的中间件。采用这个名词的话，其实可以看出OSGI的目的是想脱离语言的限制，否则以前的话都是for Java，for Java。从OSGi目前简单的介绍词中，我们可以看到OSGI最重要的就在两个方面，一个是动态化，一个是模块化。在Java体系中模块化一直以来都是比较弱的一点，而OSGI在这方面突出的表现，让它吸引到了现在几乎所有的大公司的关注，在模块化，以及动态化方面呢， OSGI都是从规范角度来做，已经提供了支持，在没有OSGi的情况下通常我们都是自己想各种各样的办法来实现，但毕竟不是官方级的规范，现在OSGI的发展已经影响到了整个业界，包括Sun，经过这么久的斗争还是开始慢慢接受了OSGI，这也是一个很明显的体现。
然而经过近两年的发展，OSGI已经逐渐在改变他的推广方式了，也就是说从以前的for Java开始不大提这个词，开始提他是全面的、统一的中间件。采用这个名词的话，其实可以看出OSGI的目的是想脱离语言的限制，否则以前的话都是for Java，for Java。从OSGi目前简单的介绍词中，我们可以看到OSGI最重要的就在两个方面，一个是动态化，一个是模块化。在Java体系中模块化一直以来都是比较弱的一点，而OSGI在这方面突出的表现，让它吸引到了现在几乎所有的大公司的关注，在模块化，以及动态化方面呢， OSGI都是从规范角度来做，已经提供了支持，在没有OSGi的情况下通常我们都是自己想各种各样的办法来实现，但毕竟不是官方级的规范，现在OSGI的发展已经影响到了整个业界，包括Sun，经过这么久的斗争还是开始慢慢接受了OSGI，这也是一个很明显的体现。
相信SOA现在已经是整个业界的焦点话题了。因为现在很多人都开始用OSGI，或者说学习OSGI，可能很多人都会想，OSGI和SOA是不是有结合点？因为OSGI在R4以后，也就是说从他发行的第四个版本的规范来看，OSGI在R4中引入了面向服务的组建模型，而这个可以说几乎是整个SOA体系中，第一个明确提出的一个实现级的规范。但是由于OSGI是SingleVM的，也就是说他只是在单VM中的规范，这样的话可能跟SOA有些不同，像SOA通常都是分布式领域的，这样来看的话OSGi可能是有点欠缺的。不过目前OSGI也在这方面不断的做出努力，包括在今年年底，OSGI将会推出RFC 119，那这个规范的话，其实就是OSGI用于分布式领域的规范。
我们最近从OSGI联盟了解到的一些消息，OSGI和现在SCA的结合可能会变得更加紧密，相信在Java领域规范中可能会将采用OSGI列入规范。
来看OSGI对SOA体系的支持的话，其实主要仍然是他的面向服务的组件模型。在这方面呢，OSGI在面向服务组件模型中明确定义了服务到底是个什么东西。那这个的话，其实在SOA体系中以前可能没有告诉你，你写一个服务，到底应该是什么样的。然后你的组件之间应该怎么样来交互等等，这一系列在OSGI中都定义的非常清楚，OSGI可能现在用于来做SOA的实现还不是很齐全，毕竟它缺少分布式领域里的一些规范，但是OSGI在整个服务模型上的思想是值得我们参考的。
我们最近从OSGI联盟了解到的一些消息，OSGI和现在SCA的结合可能会变得更加紧密，相信在Java领域规范中可能会将采用OSGI列入规范。
来看OSGI对SOA体系的支持的话，其实主要仍然是他的面向服务的组件模型。在这方面呢，OSGI在面向服务组件模型中明确定义了服务到底是个什么东西。那这个的话，其实在SOA体系中以前可能没有告诉你，你写一个服务，到底应该是什么样的。然后你的组件之间应该怎么样来交互等等，这一系列在OSGI中都定义的非常清楚，OSGI可能现在用于来做SOA的实现还不是很齐全，毕竟它缺少分布式领域里的一些规范，但是OSGI在整个服务模型上的思想是值得我们参考的。
Apache Tomcat开发团队和JSR 277的邮件组中都有人质疑过，OSGI是否违背了KISS原则，那么Peter Kriens在博客中对这个观点也进行反驳，请问你对OSGI的重量级以及它的复杂度持有什么观点呢？
这一点其实是这样的，对于了解OSGi规范的人而言，都可以看得出OSGI一直以来都是轻量级的，而且他也是比较简单的，并不是很复杂。因为这个从OSGI的起源可以看得出。OSGI最早的时候是为Smart Home来提供服务的，也就是说他是为家居网关这一块来制定规范的。那在这一块的规范中，他是不可能做得很复杂的，所以OSGI他本身的规范在复杂度这方面应该不会是很大问题的。但OSGI R4的实现Eclipse Equinox，看起来是比较重量级的，如果我们去下这个包的话，大概会在几兆以上，相对来讲，这个看起来会让人觉得OSGI的实现是比较复杂和比较重量级的。如果你再去看更聪明的Spring DM，那就更大了。这些东西可能会让别人产生一定的错觉，这个问题Peter在官方的BLOG上也曾经提到的，他对于Spring目前在OSGI上面的一些做法并不是相当认同。他认为Spring目前已经把OSGI引入一个复杂化的路线，所以这一点Peter也是持否认的观点的，我们其实可以看得出，OSGI的实现像Felix的话，大概在100K左右，从这个数量级我们可以看得出，他本身是个相当小的东西。
目前现在Java中真正实现OSGI规范的应该是有三个，最出名的当然是Eclipse Equinox，Spring DM的话，他应该是采用Equinox来做扩展实现的，Felix基本上是自己完全重新实现的一套。其实还有一个可能不是很出名的，是 Newton ，但是Newton的话，是一个SCA的实现，所以我们可能不能完全以OSGI的规范的实现来评判它，不过他是基于OSGI来实现SCA的，所以要算的话他也可以算一个。在这三者当中的话，Equinox名声比较大一点。Equinox毕竟是OSGI第一个官方认可的实现，也是第一个通过了官方验证的实现，他的使用也已经得到了验证。因为Equinox毕竟是 Eclipse的核心，而且现在Equinox已经提升到了 Eclipse 的Top Level的Project，而这一点可以看得出 Eclipse 其实对这个的重视已经越来越高了，之后他可能也会改名成 Eclipse Core Runtime，成为Eclipse的运行核心。
Equinox整体来讲他的实现是比较完整的，而且他投入的力量也比较大，这基本上是非常值得期待的，可以一直跟随着他。Equinox在OSGI的发展上其实是起到了很大的作用的，包括我们可以看到Equinox之前他起动了一个Server side的沙箱，那这个的话，对OSGI的发展起到了很明显的推动作用，因为我们目前可以看到现在最新的RFC应该是 66，在66里面其实已经开始提到吸取了现在Equinox在Server side上的一些做法，我想对于了解OSGI的同学而言，应该知道OSGI的Http Services是只支持 servlet以前的老版本。新版本像2.3以上的servlet规范中的像filter，这些都是没法支持的，在RFC 66中则会开始逐步支持这些东西了， Equinox另外一个最大的贡献可能是在扩展方面，因为他引用了Eclipse做的非常成功的扩展点，扩展点现在几乎已经成为了OSGI的非事实性的规范，也就是其实目前OSGI所有的实现中都会提供，因为扩展点对模块的可扩展性方面提供了很大的帮助。以前的话，在OSGI官方规范中是没有这一点的。然后我们可以来看Felix，Felix的话，其实他是Apache后期开始做的，也就是说它比Equinox晚挺多的。Felix的话，我们可以看他基本上是一个非常轻量级的OSGI实现，目前很多采用OSGI的人都开始逐步才用Felix，可能是因为大家觉得Equinox太重量级了。
Felix除了轻量级以外，还有一个比较突出的特色，是他把之前Peter一直想做得OBR这一块，就是OSGI的bundle仓库这一块做得非常非常好了，而这一块对于OSGI其实是非常重要的，Bundle仓库这一块大概会在OSGI的R5列入规范，所以Felix在这一块的作用应该是很明显的，我相信OSGI R5的规范会参考他来做。然后 Newton的话，Newton本身 是基于OSGI实现的，它带来的最大作用也许是他让所有人认可了OSGI是能够应用于分布式服务领域的，这对于OSGI进军分布式领域是有一定的好处的，也许RFC 119会在Newton的基础上做一定的参考来做规范了。
Equinox整体来讲他的实现是比较完整的，而且他投入的力量也比较大，这基本上是非常值得期待的，可以一直跟随着他。Equinox在OSGI的发展上其实是起到了很大的作用的，包括我们可以看到Equinox之前他起动了一个Server side的沙箱，那这个的话，对OSGI的发展起到了很明显的推动作用，因为我们目前可以看到现在最新的RFC应该是 66，在66里面其实已经开始提到吸取了现在Equinox在Server side上的一些做法，我想对于了解OSGI的同学而言，应该知道OSGI的Http Services是只支持 servlet以前的老版本。新版本像2.3以上的servlet规范中的像filter，这些都是没法支持的，在RFC 66中则会开始逐步支持这些东西了， Equinox另外一个最大的贡献可能是在扩展方面，因为他引用了Eclipse做的非常成功的扩展点，扩展点现在几乎已经成为了OSGI的非事实性的规范，也就是其实目前OSGI所有的实现中都会提供，因为扩展点对模块的可扩展性方面提供了很大的帮助。以前的话，在OSGI官方规范中是没有这一点的。然后我们可以来看Felix，Felix的话，其实他是Apache后期开始做的，也就是说它比Equinox晚挺多的。Felix的话，我们可以看他基本上是一个非常轻量级的OSGI实现，目前很多采用OSGI的人都开始逐步才用Felix，可能是因为大家觉得Equinox太重量级了。
Felix除了轻量级以外，还有一个比较突出的特色，是他把之前Peter一直想做得OBR这一块，就是OSGI的bundle仓库这一块做得非常非常好了，而这一块对于OSGI其实是非常重要的，Bundle仓库这一块大概会在OSGI的R5列入规范，所以Felix在这一块的作用应该是很明显的，我相信OSGI R5的规范会参考他来做。然后 Newton的话，Newton本身 是基于OSGI实现的，它带来的最大作用也许是他让所有人认可了OSGI是能够应用于分布式服务领域的，这对于OSGI进军分布式领域是有一定的好处的，也许RFC 119会在Newton的基础上做一定的参考来做规范了。
我想OSGI和JSR 277的争论在整个OSGI业界绝对是一场非常非常漫长的战争，几乎了解的人可能都知道，JSR 277很早就成立了。一直以来，其实最早的时候，277的规范组的成员是没有列入Peter的，而其实大部分人都知道，Peter在模块化以及动态化方面的经验几乎在全世界都是顶尖级的。之前Peter自己也申请过要加入JSR 277，但被拒绝了。在今年Javaone第二天的大会上Sun官方明确的宣布了在Java 7中将会支持OSGI。这一点虽然没有比他说采用OSGI让人激动，因为他毕竟只是兼容而已。但是从这一点可以看到，Sun已经做了比较大的让步了，因为之前其实他从来没有考虑过，他一定是要自己完全做一套的，而我们从Sun在JavaOne上的第二天的一些讲演中可以看出，Sun自己目前也在非常强调模块化这一方面的工作，包括他自己在JavaEE 6以及Java 7上都是明确的说，最重要的一点的，就是说在他的规范中最需要重视的就是模块化的规范这一点，这也说明Sun对JSR 277是非常非常重视的。不过也正因为他对这一块非常非常重视，所以可能很难接纳一个已有的模块化的标准，否则Sun可能在这一块会难以立足。不过我们可以看得出，在JavaOne宣布了以后。Peter在自己的官方博客上透露了一个消息，JSR 277 Leader已经邀请Peter加入JSR 277专家组，那这个的话，可能也证明了JSR 277专家组是认为需要Peter这样的顶尖专家的，不过Peter自己仍然在考虑之中。因为Sun毕竟已经制订了一系列的东西，这也意味着他可能不会完全采用OSGI，这个对Peter来说可能是有点疑问的。
其实OSGI他本身的规范程度上应该来讲，他在模块化以及动态化还有可扩展性方面都已经有了一定的规范了。包括像模块化的话，是他一直以来的特色，然后动态化方面应该也是支持的一直都比较好，只是在可扩展性方面的话，因为OSGI以前只是借助DS，就是它的R4中的 Declarative Services 来做这方面的支持，那相对来讲比Equinox的扩展点的话，应该是有一定的弱势的。
不过目前的话OSGI应该也会逐步考虑，就是说在他的R5中可能会考虑Equinox扩展点怎么样嵌进去，来提升他在扩展性这一方面的支持。虽然OSGI从规范中支持了这些（模块化、动态化和可扩展），包括框架的实现上也是可以支持模块化这些特性的，但是我们最关键的仍然还是怎么样去使用OSGI了。因为如果你使用OSGI的时候，不遵循他的这些原则的话，其实最后设计出来的系统仍然是你以前的非模块化，非动态化的系统。
不过目前的话OSGI应该也会逐步考虑，就是说在他的R5中可能会考虑Equinox扩展点怎么样嵌进去，来提升他在扩展性这一方面的支持。虽然OSGI从规范中支持了这些（模块化、动态化和可扩展），包括框架的实现上也是可以支持模块化这些特性的，但是我们最关键的仍然还是怎么样去使用OSGI了。因为如果你使用OSGI的时候，不遵循他的这些原则的话，其实最后设计出来的系统仍然是你以前的非模块化，非动态化的系统。
之前呢，其实在国内的社区中应该是没有，就是没有OSGI的集中讨论场所的，包括我们知道可能在JavaEye上面会有OSGI的圈子，但是并不是专栏性质的，或者说不是这种社区，极大的一个集中式的社区性质的。然后OSGI之前的社区更多是在Equinox上面，之前我们在Equinox的maillist上面可能会有一些讨论。然后在中国方面的话，其实一直以来都没有做这方面的工作，不过OSGI中文官方站筹划已经很久了，但是因为要官方认可的话，需要跟官方做一些交互，还有一些协议方面的，因为要得到他们的授权，这个商标必须是拿到允许才能使用的。所以我们跟官方交涉了一段时间，最近应该也是在今年年初的时候，才拿到了OSGI的授权。在拿到授权之后呢，我们现在已经在开始建设我们的OSGI中文官方站了。在OSGI中文社区里面我们已经做了一定的推广，就是已经告诉了大家这个站是怎么样访问，然后大家可以怎么样加入这里来为OSGi做贡献，就是说为整个OSGI的推广做贡献。因为其实在目前，我们OSGI官方站大概的做法主要是翻译官方站的一些东西，包括官方站的一些新闻，这样大家可以了解到整个OSGI业界的最新的发展动向。然后另外的话，我们会翻译一些OSGI官方上的一些精品的BLOG。那这些BLOG其实会给大家有很高的指导意义。
另外一方面我们可能会加强包括OSGI中国方面自己的一些原创性质的文章。因为其实以前是很少有原创性质的一些文章的。那这些方面的话，可能在近两年应该会好一些。因为随着OSGI在国内慢慢开始得到应用，大家都会开始在这一块有一定的经验了。在有了经验之后，我们希望有更多人能写出关于OSGI方面深入文章。这对于推广，包括你自己对OSGI的一些想法，我们也会把一些写得比较好的OSGI的原创文章翻译成英文，然后推荐给OSGI官方联盟。这样的话，对于整个OSGI发展也会有一定的好处。
在中文官方站上，我们可能也会成立一个开源的社区，这里面可能会包括论坛等，另外一方面就是提供一些基于OSGI的开源项目，这些应该是会对推广OSGI起到一定的作用。
另外一方面我们可能会加强包括OSGI中国方面自己的一些原创性质的文章。因为其实以前是很少有原创性质的一些文章的。那这些方面的话，可能在近两年应该会好一些。因为随着OSGI在国内慢慢开始得到应用，大家都会开始在这一块有一定的经验了。在有了经验之后，我们希望有更多人能写出关于OSGI方面深入文章。这对于推广，包括你自己对OSGI的一些想法，我们也会把一些写得比较好的OSGI的原创文章翻译成英文，然后推荐给OSGI官方联盟。这样的话，对于整个OSGI发展也会有一定的好处。
在中文官方站上，我们可能也会成立一个开源的社区，这里面可能会包括论坛等，另外一方面就是提供一些基于OSGI的开源项目，这些应该是会对推广OSGI起到一定的作用。
RE：与林昊一起探讨OSGi
发表人
莫 展鹏
发表于
多谢林昊 :)
发表人
David Fenng
发表于
新名词恐吓，有啥意义
发表人
发表于
Re: 新名词恐吓，有啥意义
发表人
谷 钰
发表于
Re: 新名词恐吓，有啥意义
发表人
谷 钰
发表于
Re: 新名词恐吓，有啥意义
发表人
小刀 凉粉
发表于
Re: 新名词恐吓，有啥意义
发表人
霍 泰稳
发表于
Re: 新名词恐吓，有啥意义
发表人
胡 傲果
发表于
建议以后采访，给采访者一个镜头好不好。
发表人
Sun Mellon
发表于
-
很好的访问，现在我对于OSGi的发展趋势有一个比较清晰的了解了
-
学习一下. 尽管总听到这个词，但并非都知道怎么回事
-
1.说话中英文混合,好像不说英文就没技术含量了。
2.全文中多次搞些新名词,能说明什么呢,有能耐把这些技术用到实际的应用中啊。
3.业界的跳梁小丑。 -
OSGi的确已经等到了大家的认可，目前在我们的实际项目中，就是用ＯＳＧｉ标准实现Ｆｅｌｉｘ，在Ｗｅｂ应用程序中实现动态加载新功能和新模块，并且在ｔｏｍｃａｔ４．１，ｔｏｍｃａｔ５．５，ｊｂｏｓｓ４．２，ｗｅｂｓｐｈｅｒｅｒ６．１ Ｗｅｂｓｐｈｅｒｅ５．０下测试通过：）
-
值得一提的是，它能从真正意义上实现动态加载ｃｌａｓｓ，不ＥＯＳ中提到的以ｘｍｌ格式动态加载组件更有意义：）
-
谷钰，能否请你谈一谈实践中的经验呢？
-
我对谷钰在实际项目中应用OSGi的经验也很感兴趣，是不是可以分享一下？除评论外，InfoQ中文站还欢迎投稿，editors[at]cn.infoq.com。
-
像我一样好奇心很强烈的人不少，只闻其声，不见其人，不舒服哦。
-
OSGI用在web应用程序中会不会很麻烦？
9 条回复
关注此讨论 回复