大规模视频网站的计费与流量管理
本次分享将会就大规模视频网站的计费与流量管理这个话题，从操作层面细细进行讲解和分析，为系统工程师们揭示平日里我们没有关心的另一些内容。同时也希望本次分享能揭示行业中的一些“潜规则”，让互联网行业的流量与带宽管理更为开放与简洁。
本次演讲视频录制于QCon杭州2011。
技术访谈
该内容已经被标记书签！
标记书签错误，请重试！
Rod Johnson谈Spring、OSGi、Tomcat及企业级Java的未来
受访人 Rod Johnson 采访人 Ryan Slobojan 发布于 2009年3月27日 长度 00:24:52
概要
Rod Johnson谈到了Spring Portfolio、Oracle对BEA及Sun对MySQL的收购、Java EE 6、Tomcat和Spring、Spring动态模块、企业级Java的未来、OSGi为应用开发者带来的好处、对Covalent的收购以及 Spring 3.0。Johnson还提到了SpringSource应用平台——它会在该访谈制作好的一个月后发布。
个人简介
Rod是Java和J2EE开发方面的权威人士。他是畅销书作者、极具经验的咨询师以及开源的开发者，同时他还是深受欢迎的演讲者。Rod是Spring 框架的创建者，该框架源自已出版的Expert One-on-One J2EE Design and Development一书的代码。Rod将与Juergen Hoeller一起继续领导Spring的开发。
Rod Johnson谈到了Spring Portfolio、Oracle对BEA及Sun对MySQL的收购、Java EE 6、Tomcat和Spring、Spring动态模块、企业级Java的未来、OSGi为应用开发者带来的好处、对Covalent的收购以及 Spring 3.0。Johnson还提到了SpringSource应用平台——它会在该访谈制作好的一个月后发布。
个人简介
Rod是Java和J2EE开发方面的权威人士。他是畅销书作者、极具经验的咨询师以及开源的开发者，同时他还是深受欢迎的演讲者。Rod是Spring 框架的创建者，该框架源自已出版的Expert One-on-One J2EE Design and Development一书的代码。Rod将与Juergen Hoeller一起继续领导Spring的开发。
是的，我们向Spring portfolio增加了大量新功能，包括Spring Security2.0。这是Acegi Security针对Spring的演变，很明显它将成为Spring portfolio的核心组成部分，同时该变化使得Acegi Security更易于使用。Acegi Security的一个历史遗留问题就是它虽然很强大，但不那么容易使用。我们对Spring的座右铭就是“简单而强大”，并且我认为现在已经做到了这一点：通过Spring 2的命名空间大幅简化配置并使得Spring Security简单好用。即将发布的还有Spring Web Flow 2.0。围绕着易用性我们对Spring Web Flow进行了大量的增强，同时也增加了JSF和AJAX相关的一些功能。因此我们敢说，对于使用JSF的用户，Spring Web Flow是他们最自然的框架选择。接下来的一两个月中，我们还会发布多种SpringSource产品，包括SpringSource工具套件，这是一个 Eclipse增值包，为我们的付费客户提供了很多新特性。另外我们还会发布SpringSource应用管理套件，这是一个管理和操作监控产品，可以在生产阶段提供关于Spring应用的详细深入的信息。同时还会提供针对Oracle数据库的SpringSource高级包，它提供了与Oracle RAC、Oracle AQ及Oracle其他产品的增值连接。
这个问题很有意思。我认为Oracle对BEA的收购不会对开源产生太大影响，因为很显然这两个公司都不是开源公司。我们与BEA和Oracle都保持着很好的关系，因此我们认为大家还可以继续使用Spring和WebLogic，尤其是两者合用，没什么好担心的。关于开源，我猜BEA要比Oracle使用了更多的开源软件，比如他在WebLogic 10核心中使用了Spring。另一方面，Oracle也越来越多地使用开源软件，因此我希望他能将这个趋势更进一步。我想这对JCP会有一些重要的暗示，因为现在的应用服务器市场越来越呈现出两强相争的局面。如果你看一下传统的服务器市场就会发现这已经完全被IBM和Oracle统治了（在 Oracle获得了大量的WebLogic客户后）。同时，BEA所面临的挑战，尤其是来自于JBoss的挑战自从Red Hat收购了JBoss后看起来已经在减弱了。因此，我认为这会产生一些有意思的副作用。本质上，成熟的Java EE服务器市场在很大程度上将会出现两强相争的局面。这会促使更多的人寻求轻量级的解决方案如Tomcat。关于Sun对MySQL的收购，我觉得这对 Java是件好事。显然这会帮助Sun推动其开源的承诺，我也很期望通过这件事会使JCP变得更加开放、更像一个开源过程。
我觉得这事迟早都会发生。从个人角度来说，我觉得Java EE 6首先需要回答这个问题：它能否按计划发布、能否保证Java EE的相关性。我认为Java EE规范塑造市场的时代已经过去了。Java EE 6中的很多东西都是非常积极的。其中之一就是profiles了。很明显人们很重视JCP标准，这些标准要比其他一些标准更具价值，同时用户也希望拥有标准化和一致的子集。因此我认为profiles是个非常好的想法，可扩展性的目标也是个好主意，Java EE的部分作用在于开创一个供创新生长的大舞台而不是交付企业级Java所需的全部东西。当然，SpringSource也对Java EE 6做出了巨大的贡献。我是Java EE 6专家组成员，我尤其看好profiles的前景。看看Tomcat的统计数据吧——我在几个月前的博客中已经提到了这一点——我认为Tomcat差不多占据了统治地位。毫无疑问，Tomcat已经成为应用服务器市场上的老大了。它遥遥领先于WebSphere，而在大多数调查中WebSphere都处于第二位。因此我觉得Java EE已经在特定的方向上取得了长足的进步，至少从Java EE 6看是这样的，很多人都会说“嘿，这就是我们想要的一个子集”。
当然是了。Spring Dynamic Modules是个非常重要的项目，因为我们相信Spring与OSGi的组合是Java中间件的未来。毫无疑问，OSGi已经做好了重塑服务器端的准备，其采取的方式与获得极大成功的Eclipse插件架构如出一辙。不过，虽然OSGi赐予了我们非常棒的动态模块化解决方案，可以解决版本标定、热部署等诸多问题，但是它并没有提供组件模型、也没有企业服务，而且还不会赐给企业级开发者所需的经验。你只要在企业服务中将OSGi和Spring组件模型放到一起，你就得到了既易于使用且功能强大的一个东西。因此我们将Spring Dynamic Modules看作是Spring portfolio策略的重要组成部分。
我还有一个问题。过去几年中我们看到了企业级技术的很多问题，POJO要比EJB更流行。现在J2EE 6中又出现了profiles，那么我想知道你对未来的看法。Tomcat和Spring会成为企业级服务器的主流么？重量级、复杂、功能完全的J2EE 服务器还有生存空间么？
这个问题问的好。我认为Spring和Tomcat会成为主流的企业级Java平台。我们已经委托研究分析机构做过一些调研，尽管我不能说出具体的数字，但基本上这些调研结果都表明Sprng和Tomcat要比WebSphere、WebLogic等更加流行，很明显市场已经发生了一些变化。还有很多数据也都证明了这个事实。
我的意思是不要光听我说，你可以看看工作列表，相对于EJB来说，更多的工作需要Spring。我并不认为J2EE或Java EE平台已死，profiles可以保持其长青。坦率地说，我觉得功能完全的应用服务器已死，但这是件好事。然而并不是说WebSphere和 WebLogic这样的产品就没有市场价值了。
这些产品还有些价值，但我觉得人们可能以不同的方式利用这个价值。大家都不想要过于庞大的东西了——他们想要可选择的东西。事实上你可以看看那些供应商所采取的方式，比如BEA的MSA（Micro Services Architecture），他们都使用了OSGi。
实际上他们正在不断更新产品以使其更加模块化。很明显Java EE应用服务器是由委员会设计的，它并没有真正解决应该解决的问题，世界也在不断变化着，这使得规范的相关性相比之前变得更加弱了。就拿SOA来说吧，随着SOA的出现，越来越少的应用会采取那种大而全的架构了。就Java EE具体的组件技术来说，我认为其中一些技术还是有着光明的未来的，而其他一些则不然。Servlet API就有着光明的未来且相关性很好，因为它还是非常基础的。
很多技术或是API比如JMS和JTA定义了基本的中间件契约，我认为他们还会继续发挥重要的作用。JPA很有可能会成功。相对于EJB，我更看好 JPA。我的意思是EJB是个很差劲的技术。我实在是不明白Sun和其他一些供应商为什么还要维护EJB。我认为EJB已经是穷途末路了。因此很多大的组织比如银行已经放弃了EJB。我觉得有两种选择：其一是彻底放弃EJB，其二是不再让其向后兼容了，这样的话一切都要重头开始，很显然这更可行，因为丢掉了一个大包袱。
我的意思是不要光听我说，你可以看看工作列表，相对于EJB来说，更多的工作需要Spring。我并不认为J2EE或Java EE平台已死，profiles可以保持其长青。坦率地说，我觉得功能完全的应用服务器已死，但这是件好事。然而并不是说WebSphere和 WebLogic这样的产品就没有市场价值了。
这些产品还有些价值，但我觉得人们可能以不同的方式利用这个价值。大家都不想要过于庞大的东西了——他们想要可选择的东西。事实上你可以看看那些供应商所采取的方式，比如BEA的MSA（Micro Services Architecture），他们都使用了OSGi。
实际上他们正在不断更新产品以使其更加模块化。很明显Java EE应用服务器是由委员会设计的，它并没有真正解决应该解决的问题，世界也在不断变化着，这使得规范的相关性相比之前变得更加弱了。就拿SOA来说吧，随着SOA的出现，越来越少的应用会采取那种大而全的架构了。就Java EE具体的组件技术来说，我认为其中一些技术还是有着光明的未来的，而其他一些则不然。Servlet API就有着光明的未来且相关性很好，因为它还是非常基础的。
很多技术或是API比如JMS和JTA定义了基本的中间件契约，我认为他们还会继续发挥重要的作用。JPA很有可能会成功。相对于EJB，我更看好 JPA。我的意思是EJB是个很差劲的技术。我实在是不明白Sun和其他一些供应商为什么还要维护EJB。我认为EJB已经是穷途末路了。因此很多大的组织比如银行已经放弃了EJB。我觉得有两种选择：其一是彻底放弃EJB，其二是不再让其向后兼容了，这样的话一切都要重头开始，很显然这更可行，因为丢掉了一个大包袱。
其实对于应用开发者来说，这机会与服务器的基础设施一样。其中一个好处就是模块化并且只运行想要的东西而不是整个重量级的平台，凭借OSGi，你可以在运行中只启动需要的bundle。这样计算机的运行速度就会更快。如果你只想加载所需的东西，OSGI非常胜任。
主要的一个好处是可以得到更加模块化的中间件平台，只加载所需的组件完成特定的目标。这意味着在一年到两年的时间内，我们会看到能做任何事情的功能完全的企业级平台，而启动速度要比现在快得多。我认为版本标定和热部署这些特性是非常重要的，因为企业级Java中的版本冲突问题变得越来越严重了。
我相信很多人有过这样的经历：不同项目中的类使用了不同的开源库。就拿Hibernate 3来说吧，第一次用其做查询时就将导致WebLogic 8.1或9服务器停止，我说的停止是指控制台打印出这样的消息“CharScanner; panic”。原因在于WebLogic和Hibernate都使用了ANTLR，但他们所用的ANTLR版本是不一样的。随着很多商业应用服务器也越来越多的开始使用开源产品，这些问题变得更糟了。
基本上Java EE对其的解决方案就是“哦，我们还没有遇到过这个问题，请使用供应商给你的东西吧”。因此出现了很多小技巧来改变类的加载顺序，这些技巧无法移植，并不是真正的解决之道，只是权宜之计罢了。看看OSGi吧，它真正的解决了这个问题。其解决方式是标准化的，可以在不同的环境下移植。它是可预测的方案。
凭借OSGi，我们还可以并发运行相同应用、同一个类的不同版本，还可以实现商业应用组件的精细化重新部署。我想其真正的优势在于提高无故障运行时间。你无需停下应用以替换账单系统中的某些类，在运行时替换就可以了。我们还需解决很多问题以简化其使用方式。因此如果现在就使用Spring、Spring Dynamic Modules及OSGi，你会发现还是有点复杂的。
慢慢的我们会看到更多的集成产品，他们会将这些特性放到单独的解决方案中。但技术方案是确定的，OSGi会解决像版本标定和可维护性等问题，而目前 Java EE并没有提供好的解决方案。未来我们会看到隔离的好处，比如AspectJ的加载时编织和OSGi的集成。一旦根据bundle定义好了部署模型（独立于任何特定的环境如Java EE服务器），你就可以用加载时编织实现很多有趣的事情了，比如自动的策略增强。这为我们提供了无限的可能。
主要的一个好处是可以得到更加模块化的中间件平台，只加载所需的组件完成特定的目标。这意味着在一年到两年的时间内，我们会看到能做任何事情的功能完全的企业级平台，而启动速度要比现在快得多。我认为版本标定和热部署这些特性是非常重要的，因为企业级Java中的版本冲突问题变得越来越严重了。
我相信很多人有过这样的经历：不同项目中的类使用了不同的开源库。就拿Hibernate 3来说吧，第一次用其做查询时就将导致WebLogic 8.1或9服务器停止，我说的停止是指控制台打印出这样的消息“CharScanner; panic”。原因在于WebLogic和Hibernate都使用了ANTLR，但他们所用的ANTLR版本是不一样的。随着很多商业应用服务器也越来越多的开始使用开源产品，这些问题变得更糟了。
基本上Java EE对其的解决方案就是“哦，我们还没有遇到过这个问题，请使用供应商给你的东西吧”。因此出现了很多小技巧来改变类的加载顺序，这些技巧无法移植，并不是真正的解决之道，只是权宜之计罢了。看看OSGi吧，它真正的解决了这个问题。其解决方式是标准化的，可以在不同的环境下移植。它是可预测的方案。
凭借OSGi，我们还可以并发运行相同应用、同一个类的不同版本，还可以实现商业应用组件的精细化重新部署。我想其真正的优势在于提高无故障运行时间。你无需停下应用以替换账单系统中的某些类，在运行时替换就可以了。我们还需解决很多问题以简化其使用方式。因此如果现在就使用Spring、Spring Dynamic Modules及OSGi，你会发现还是有点复杂的。
慢慢的我们会看到更多的集成产品，他们会将这些特性放到单独的解决方案中。但技术方案是确定的，OSGi会解决像版本标定和可维护性等问题，而目前 Java EE并没有提供好的解决方案。未来我们会看到隔离的好处，比如AspectJ的加载时编织和OSGi的集成。一旦根据bundle定义好了部署模型（独立于任何特定的环境如Java EE服务器），你就可以用加载时编织实现很多有趣的事情了，比如自动的策略增强。这为我们提供了无限的可能。
我们做了一笔好买卖，因为在进行收购时，Sun也宣布用十亿美元收购LAMP中的M——MySQL，而我们只用不到十亿美元就收购了LAMP中的A—— Apache！这么说有点没礼貌，没人能独享Apache项目，我的意思是我们完全理解Apache社区。对Covalent的收购折射出很多因素：首先，就像任何成功的收购一样，这是由客户驱动的。我们已经与Covalent的客户进行过讨论，他们希望得到Covalent对Tomcat和 Apache Web Server的支持，还希望得到SpringSource对Spring的支持。显然我们需要进行一些合作了。
对于那些不熟悉Covalent的人我得做些解释，Covalent是Tomcat和Apache Web Server支持和服务的主要提供者。Spring与Tomcat的组合事实上已经成为企业级Java最流行的平台，我们两家合并可以为这两者提供更高质量的服务。我们这两个公司的利益有很多共同点。我一直坚信只有积极参与到开源项目中并贡献知识产权，你才能为开源项目提供高质量的支持。Covalent 也和我有一样的想法。
一些Covalent工程师包括大多数积极的Tomcat提交者也都有这种想法，其中还有Bill Rowe，他编写了大量的Apache 2代码，同时也参与到Apache的开发中。因为有共同的看法和这么多相互尊重的人，所以这次收购是自然而然的事情。最后这是我们在成为企业级Java开源领域中领头羊的自然一步，同时这也是一个机会，能为企业级Java事实上的标准提供支持。
对于那些不熟悉Covalent的人我得做些解释，Covalent是Tomcat和Apache Web Server支持和服务的主要提供者。Spring与Tomcat的组合事实上已经成为企业级Java最流行的平台，我们两家合并可以为这两者提供更高质量的服务。我们这两个公司的利益有很多共同点。我一直坚信只有积极参与到开源项目中并贡献知识产权，你才能为开源项目提供高质量的支持。Covalent 也和我有一样的想法。
一些Covalent工程师包括大多数积极的Tomcat提交者也都有这种想法，其中还有Bill Rowe，他编写了大量的Apache 2代码，同时也参与到Apache的开发中。因为有共同的看法和这么多相互尊重的人，所以这次收购是自然而然的事情。最后这是我们在成为企业级Java开源领域中领头羊的自然一步，同时这也是一个机会，能为企业级Java事实上的标准提供支持。
Spring Framework 3.0将会继续对2.5版中Spring MVC所引入的特性提供增强。从最终用户的角度来看，2.5版最大的改变就是对注解的使用，这样我们就可以跨越Spring IoC容器和Spring MVC使用注解了。在Spring 3.0中，我们会进一步促进MVC和Web Flow之间的编程模的融合。我们希望提供一个单一的编程模型，它既可以使用在Web MVC经典的请求——响应导航上，也能用在Spring Web Flow提供的直接导航上。我们还打算支持REST，比如处理Spring MVC RESTful URL，同时不再支持Java 5之前的版本。我们已经拥有了对Java 5和Java 6的扩展支持，所以其影响范围很小，但我们可以更轻松的维护纯Java 5+所编写的代码了。
最近新加入的就是Spring Integration，这是在十二月份的Spring Experience上宣布的。它为构建在Spring组件模型上的企业集成提供了模型。它还提供了一种创新的编程模型，该模型大量使用注解来简化模式的处理，如聚合、转换和路由等。最近还不打算向Spring portfolio中添加新的项目，但你已经看到过几个月将要发布很多项目，我们在Spring portfolio上还是非常积极的。当然了，SpringSource还会继续发布新的产品，到JavaOne举办之时，我们将会演示很多重要的新产品。
视频没法看啊
发表人
tang jun
发表于
Re: 视频没法看啊
发表人
吴磊 super
发表于
有点卖瓜之嫌
发表人
gz husthxd
发表于
Re: 有点卖瓜之嫌
发表人
bin liu
发表于
Re: 有点卖瓜之嫌
发表人
gz husthxd
发表于
Re: 有点卖瓜之嫌
发表人
曹 云飞
发表于
JEE还剩下什么
发表人
Zhong Jove
发表于
-
视频没法看啊，老是停顿!难道你们能想到将视频放上来，却不会去想一想用户能不能看的到呢？一直关注这里，但是每次视频都看不了，INFOQ怎么不想办法解决一下，还有infoq访问速度也很慢，真是令人失望啊!
-
呵呵，摒弃Weblogic、Websphere等重量级的container，使用Tomcat，至少在目前来看还是虚无缥缈的。
-
基本同意Rod说的, JSP/Servlet, JMS, JTA, JPA, JAAS这些还是不错的标准或中间层, 剩下的EJB什么的就一边凉快去吧
-
新安装了IE8正式版，可以看视频了
-
人家说的是Tomcat更流行。“然而并不是说WebSphere和 WebLogic这样的产品就没有市场价值了。”
事实上也是如此，tomcat足够应付大部分的企业级应用了。 -
tomcat足够应付大部分的企业级应用了
-- 不敢苟同，大多数的网报都不敢用Tomcat作为Server，说“tomcat足够应付大部分的企业级应用了”是痴人说梦话。 -
不敢用是否能说明tomcat就不行？有的互联网级应用直接用tomcat的
7 条回复
关注此讨论 回复