大规模视频网站的计费与流量管理
本次分享将会就大规模视频网站的计费与流量管理这个话题，从操作层面细细进行讲解和分析，为系统工程师们揭示平日里我们没有关心的另一些内容。同时也希望本次分享能揭示行业中的一些“潜规则”，让互联网行业的流量与带宽管理更为开放与简洁。
本次演讲视频录制于QCon杭州2011。
文章
该内容已经被标记书签！
标记书签错误，请重试！
我们为什么需要分布式OSGi
作者 Eric Newcomer 译者 徐涵 发布于 2009年4月27日
随着分布式OSGi项目即将抵达重大里程碑，现在应当是一个恰当的时机来回顾一下我们已经完成了哪些工作、还有哪些需要做的，并谈一谈我们为什么要进行这项工作。
相关厂商内容
为迎接即将发布的OSGi规范4.2版，我们在11月对设计文档初稿（按OSGi术语叫Requests for Comment，或简称RFCs）做了更新。这个月，我们在Apache CXF发布了该版本中一个重要的新设计——即RFC 119，分布式OSGi——的参考实现源码。
由于当前版本的OSGi规范已经在嵌入式领域取得成功，因此分布式OSGi（Distributed OSGi）项目被计划纳入OSGi的下个版本，并开始为企业级应用所采纳。比如，Eclipse插件就采用了OSGi框架；另外，所有应用服务器厂商以及众多ESB厂商也都接纳了OSGi。
OSGi联盟于2006年9月召开过一个公开研讨会，深入探讨了对企业版（若可能的话）的需求（Peter Kriens写了一篇非常好的描述此背景的文章）。当前版本的OSGi规范已经通过JSR 291成为了Java SE的一部分，对于我们参加了该研讨会的人来说，所面临的问题是，OSGi规范是否也应成为Java EE的替代方案，以及假如是的话那么需要满足哪些需求。众多关键需求中的一条是，OSGi服务能够调用运行于其他JVM之上的服务，并支持企业应用拓扑，从而提高可用率、可靠性及可伸缩性。（当前的OSGi规范只定义了在单个JVM里的服务调用行为。Peter的那篇研讨会总结文章里可以看到更多信息。）
2007年1月召开了首次企业专家组会议，工作由此正式开始。分布式OSGi始终是该议程里级别最高的需求之一。起初，我们常被批评为“重复已有工作”或“制造另一个CORBA”，不过这些都是由误解造成的。设计文档初稿（RFC 119）和参考实现代码将有助于解释清楚我们并非如此。我们只是扩展OSGi框架来配置现有的分布式计算软件系统。我们在RFC 119里采用“distribution software”（或简称DSW）这一术语来泛指任何能够进行远程服务调用的协议与数据格式系统。远程指的是另一个JVM或地址空间。
有人建议我们选择一种具体的DSW（distribution software），并将其标准化。此做法的一个好处是，我们可以利用针对特定协议的功能（比如可执行代码的序列化），不过这会缩小选择范围，并可能导致产生依赖。我们并没有那样做，而是定义了一个可用于任何分布式计算软件系统的通用配置机制。我们也试图不妨碍使用像“序列化可执行代码”这样的功能——也就是说，如果你愿意的话，仍然可以那样做，只不过那不是标准化的做法，因为它是针对单一类型的DSW（distribution software）的。
除了Apache CXF的参考实现，Eclipse ECF项目以及Paremus的Infinflow产品也有意实现分布式OSGi的设计，而且我们已经听说Eclipse Riena项目也在作此考虑。因此，但愿我们的分布式OSGi正走在正确的路线上。不过我们仍希望大家提供反馈，而且现在也还有时间来更改规范里的内容。分布式OSGi的设计还包括了发现服务（discovery service）以及用于配置多分布式软件系统组件的SCA元数据扩展。这两样东西目前尚未公开，不过应该快了。
为了说明我们目前处于什么阶段，对OSGi联盟的运作方式做一些了解是大有裨益的。OSGi的流程跟JCP（Java Community Process）颇为相似。实际上，OSGi规范刚开始就是以JSR 8出现的，而且它也基本反映了那个最初JSR工作的进展。OSGi流程是从请求提案文档（Request for Proposal，简称RFP）开始的，该文档对需求进行了详细描述。RFP得到批准后，一个或多个满足需求的请求评论文档（Requests for Comment，RFCs）将被创建起来。当一个RFC得到批准后，有关规范就会进行更新，以涵盖该项设计。RFP和RFC都是专家组的工作成果，尽管它们往往处于组里个别人或小部分人的带领下。
不过，OSGi联盟在规范方面的流程是独一无二的，因为文书写作都是交由Peter Kriens完成的。这点好极了，因为Peter Kriens从一开始就跟随OSGi的工作，他可以确保规范的质量与一致性。而且，这也消除了其他标准化组织在把文档书写工作交给其成员（通常代表与其他成员竞争的厂商）时经常碰到的政治问题。
当前版本的参考实现是为了验证RFC 119的设计，并使得该份RFC得以通过专家组投票。在规范阶段，我们期望在把该项设计整合进规范的过程中对它做进一步讨论，这也许会引起对参考实现的进一步变动。
OSGi专家组现在正着手于同Peter Kriens一起为R4.2版而努力，预计可于三月或四月发布初步版本，并在六月发布最终版本。关于即将发布的R4.2版的更多信息可以在OSGi Dev Con上得知。该技术大会将于3月23至26日在Santa Clara同EclipseCon联合召开。
R4.2版里的另一个主要部分是对核心框架的各种扩展，比如源自Spring的Blueprint Service服务模型（用于开发OSGi服务）以及各种映射到OSGi bundles的Java EE部件（JTA、JDBA、JPA、JNDI、JMX、JAAS和Web Apps）。Java EE映射并不如对核心的增强（如Spring/Blueprint或分布式OSGi）那么成熟，它们只是一个将随R4.2最终版一同发布的预览。
在过去的两年里，我们已经用初稿记录了分布式OSGi的需求与设计，并用参考实现代码进行了演示。OSGi规范R4.2企业版预计于2009年中发布，这是其中的一项重要特性。伴随着对OSGi核心框架的扩展、源于Spring的Blueprint服务组件模型以及关键Java EE技术的映射，即将发布R4.2版对OSGi规范和OSGi社区而言意味着前进中的重要一步。
阅读英文原文：Why Do We Need Distributed OSGi?。
给InfoQ中文站投稿或者参与内容翻译工作，请邮件至editors@cn.infoq.com。也欢迎大家加入到InfoQ中文站用户讨论组中与我们的编辑和其他读者朋友交流。
OSGI 我看好你哦
发表人
刘 恒涛
发表于
Re: OSGI 我看好你哦
发表人
xu huisheng
发表于
有了分布式OSGi，EJB还有用武之地么？
发表人
曹 云飞
发表于
期待
发表人
Black Nile
发表于
Re: 期待
发表人
chen honnom
发表于
5 条回复
关注此讨论 回复