我已经在Wikipedia和其他网站上阅读了有关OSGi的内容，但我没有真正看到大图。它说这是一个基于组件的平台，您可以在运行时重新加载模块。Eclipse插件框架也是到处都有的“实际示例”。

我的问题是：

1. OSGi的明确定义是什么？

2. 它可以解决哪些常见问题？

“常见问题”是指我们每天都会面对的问题，例如“ OSGi能使我们的工作更高效/有趣/简单吗？”

OSGi的组件系统为您提供什么好处？
好吧，这里有一个清单：

降低复杂性-使用OSGi技术进行开发意味着开发捆绑软件：OSGi组件。捆绑包是模块。他们从其他捆绑包中隐藏内部信息，并通过定义明确的服务进行通信。隐藏内部部件意味着以后有更大的自由更改。这不仅减少了错误的数量，而且还使捆绑包的开发更容易，因为正确大小的捆绑包通过定义良好的接口实现了一部分功能。有一个有趣的博客，描述了OSGi技术对其开发过程的影响。

重用 -OSGi组件模型使在应用程序中使用许多第三方组件变得非常容易。越来越多的开源项目为OSGi提供现成的JAR。但是，商业图书馆也可以作为现成的捆绑销售。

真实世界 -OSGi框架是动态的。它可以即时更新捆绑包，服务可以来去去。习惯于使用更传统的Java的开发人员将其视为非常有问题的功能，而没有看到其优势。但是，事实证明，现实世界是高度动态的，并且具有可以来去去的动态服务，使这些服务成为许多现实世界场景的完美匹配。例如，服务可以为网络中的设备建模。如果检测到设备，则注册服务。如果设备消失，则该服务未注册。与这种动态服务模型相匹配的现实世界场景数量惊人。因此，应用程序可以在自己的域中重用服务注册表的强大原语（使用表达性过滤器语言进行注册，获取，列出，以及等待服务出现和消失）。与专用解决方案相比，这不仅节省了编写代码的时间，而且还提供了全局可见性，调试工具和更多功能。在如此动态的环境中编写代码听起来像一场噩梦，但幸运的是，支持类和框架可以减轻大部分（即使不是全部）痛苦。

易于部署 -OSGi技术不仅是组件的标准。它还指定如何安装和管理组件。许多捆绑包已使用此API提供管理代理。该管理代理可以很简单，例如命令外壳，TR-69管理协议驱动程序，OMA DM协议驱动程序，Amazon EC2的云计算接口或IBM Tivoli管理系统。标准化的管理API使得将OSGi技术集成到现有和将来的系统中非常容易。

动态更新 -OSGi组件模型是动态模型。可以安装，启动，停止，更新和卸载捆绑软件，而无需关闭整个系统。许多Java开发人员都不相信这可以可靠地完成，因此最初在生产中就不会使用它。但是，在开发中使用此功能一段时间后，大多数人开始意识到它确实有效并且大大减少了部署时间。

自适应 -OSGi组件模型是从头开始设计的，以允许混合和匹配组件。这要求必须指定组件的依赖关系，并且要求组件生活在其可选依赖项并不总是可用的环境中。OSGi服务注册表是一个动态注册表，捆绑软件可以在其中注册，获取和监听服务。这种动态服务模型允许捆绑软件找出系统上可用的功能，并调整它们可以提供的功能。这使代码更灵活，更能适应更改。

透明度-捆绑包和服务是OSGi环境中的头等公民。管理API提供对包的内部状态以及如何将其连接到其他包的访问。例如，大多数框架都提供一个显示此内部状态的命令外壳。可以停止部分应用程序以调试特定问题，也可以引入诊断包。OSGi应用程序不必盯着数百万行的日志输出和漫长的重新启动时间，而通常可以使用实时命令外壳调试。

版本控制 -OSGi技术解决了JAR难题。JAR地狱是库A与库B; version = 2一起工作，而库C仅与B; version = 3一起工作的问题。在标准Java中，您很不走运。在OSGi环境中，所有捆绑软件均经过仔细的版本控制，只有可以协作的捆绑软件在同一类空间中连接在一起。这样，捆绑软件A和C都可以使用自己的库运行。尽管不建议设计带有版本控制问题的系统，但在某些情况下可以节省生命。

简单 -OSGi API非常简单。核心API仅是一个包，并且少于30个类/接口。该核心API足以编写捆绑包，安装捆绑包，启动，停止，更新和卸载它们，并包括所有侦听器和安全类。很少有API可以为这么少的API提供这么多的功能。

小型 -OSGi Release 4 Framework可以在大约300KB的JAR文件中实现。对于通过包含OSGi添加到应用程序中的功能而言，这是很小的开销。因此，OSGi可在各种设备上运行：从很小的设备到大型机，再到大型机。它仅要求运行一个最小的Java VM，并在其之上添加很少的内容。

快速 -OSGi框架的主要职责之一是从包中加载类。在传统的Java中，JAR完全可见，并放在线性列表中。搜索班级需要搜索此列表（通常很长，不少于150个）。相比之下，OSGi会预先绑定束，并为每个束确切知道哪个束提供了该类。缺少搜索是启动时的重要提速因素。

懒惰-软件方面的懒惰是好的，OSGi技术具有许多机制，可以仅在真正需要时才执行操作。例如，捆绑包可以急于启动，但也可以配置为仅在其他捆绑包正在使用它们时启动。可以注册服务，但只能在使用时创建。对规范进行了多次优化，以适应此类懒惰的情况，从而节省大量的运行时间成本。

安全 -Java在底部有一个非常强大的细粒度安全模型，但事实证明在实践中很难对其进行配置。结果是大多数安全的Java应用程序都运行在二进制选项中：没有安全性或功能非常有限。OSGi安全模型利用了细粒度的安全模型，但是通过让捆绑软件开发人员以易于审核的形式指定所请求的安全详细信息，而环境操作员仍然完全负责，从而提高了可用性（以及强化了原始模型）。总体而言，OSGi可能会提供最安全的应用程序环境之一，但缺少硬件保护的计算平台仍然可以使用。

非侵入式 -OSGi环境中的应用程序（捆绑包）留给自己使用。他们几乎可以使用VM的任何功能，而不受OSGi的限制。OSGi的最佳实践是编写普通的Java对象，因此，OSGi服务不需要特殊的接口，即使Java String对象也可以充当OSGi服务。这种策略使应用程序代码更容易移植到另一个环境。

随处可见-取决于情况。Java的最初目标是在任何地方运行。显然，不可能在所有地方都运行所有代码，因为Java VM的功能不同。手机中的VM可能不支持与运行银行应用程序的IBM大型机相同的库。有两个问题要注意。首先，OSGi API不应使用并非在所有环境中都可用的类。其次，如果捆绑包包含执行环境中不可用的代码，则捆绑包不应启动。这两个问题都已在OSGi规范中解决。

资料来源：www.osgi.org/Technology/WhyOSGi

我发现OSGi有以下好处：

• 每个插件都是一个版本化的工件，具有自己的类加载器。
• 每个插件都依赖于它所包含的特定jar以及其他特定版本的插件。
• 由于版本控制和隔离的类加载器，因此可以同时加载同一工件的不同版本。如果应用程序的一个组件依赖于插件的一个版本，而另一个依赖于另一版本，则可以同时加载它们。

这样，您可以将应用程序构造为一组按需加载的版本化插件工件。每个插件都是一个独立的组件。正如Maven可以帮助您构建自己的构建一样，它是可重复的并由创建它的一组特定版本的工件定义，OSGi可以帮助您在运行时进行构建。

我不太在乎OSGi模块的可热插拔性（至少目前是这样）。更多的是强制性的模块化。任何时候在类路径上都没有数百万个“公共”类可用，可以很好地避免循环依赖：您必须真正考虑您的公共接口-不仅要从Java语言构造“公共”的角度考虑，还要从您的库的角度考虑/ module：您想让其他人使用哪些组件（正是）？实现功能所需的（其他模块的）接口究竟是什么？

很好，它附带了热插拔功能，但是我宁愿重新启动我的常规应用程序，也不愿测试热插拔功能的所有组合...

• 类似地，您可以在不关闭汽车的情况下更换汽车的电动机。
• 您可以为客户定制复杂的系统。请参阅Eclipse的功能。
• 您可以重用整个组件。不仅仅是对象。
• 您使用稳定的平台来开发基于组件的应用程序。这样做的好处是巨大的。
• 您可以使用黑匣子概念构建组件。其他组件不需要了解隐藏的接口，只需看到已发布的接口即可。
• 您可以在同一系统中使用几个相等的组件，但可以在不同的发行版中使用它们，而不会损害应用程序。OSGi解决了Jar Hell问题。
• 使用OSGi，您可以开发思想来使用CBD构建系统

对于使用Java的每个人，都有很多好处（我现在仅提醒了这些）。

为清楚起见进行了编辑。OSGi页面给出了比我更好的简单答案

一个简单的答案：OSGi服务平台为协作的网络服务提供了一个标准化的，面向组件的计算环境。这种体系结构大大降低了构建，维护和部署应用程序的总体复杂性。OSGi服务平台提供了无需重新启动即可在各种网络的设备上动态更改组成的功能。

例如，在Eclipse IDE中，在一个单一的应用程序结构中，重新安装新插件并不重要。完全使用OSGi实现，您应该能够在运行时添加插件，获得新功能，而不必完全重启eclipse。

同样，每天使用少量应用程序也没什么大不了的。

但是，当您开始研究多计算机，分布式应用程序框架时，它便开始变得有趣起来。当关键系统必须具有100％的正常运行时间时，在运行时热交换组件或添加新功能的功能将很有用。当然，现在大多数情况下都具有执行此操作的功能，但是OSGi试图将所有内容捆绑到具有通用接口的漂亮的小型框架中。

OSGi是否可以解决常见问题，我不确定。我的意思是，可以，但是对于更简单的问题，开销可能不值得。但是，当您开始处理较大的联网应用程序时，需要考虑一下。

在OSGi上让我发疯的一些事情：

1）命令及其上下文加载器对其有很多怪癖，并且可能有些不同步（我们在合流内部使用felix）。与纯弹簧（无DM）相比，[main]几乎在所有同步过程中都运行着。

2）热加载后，类不相等。假设您在休眠状态下有一个tangosol缓存层。它由OSGi范围之外的Fork.class填充。您热加载一个新的jar，并且Fork不变。Class [Fork]！= Class [Fork]。对于相同的根本原因，它也出现在序列化过程中。

3）集群。

您可以解决这些问题，但这是一个主要的主要难题，并使您的体系结构看起来有缺陷。

以及那些宣传热插拔的人。OSGi的＃1客户端？日食。装入捆绑包后Eclipse会做什么？

重新启动。

我尚未成为OSGi的“粉丝”。

我一直在财富100强公司中使用企业应用程序。最近，我们使用的产品已“升级”为OSGi实现。

开始本地cba部署... [2/18/14 8：47：23：727 EST] 00000347 CheckForOasis

最终部署，并且“以下束将被停顿，然后重新启动” [2/18/14 9：38：33：108 EST] 00000143 AriesApplicat I CWSAI0054I：作为应用程序更新操作的一部分

51分钟...每次代码更改时...早期版本（非OSGi）将在不到5分钟的时间内部署到较旧的开发计算机上。

在具有16 gig ram和40个免费gig磁盘以及Intel i5-3437U 1.9 GHz CPU的计算机上

此次升级的“好处”是作为改进（生产）部署出售的，这项活动我们每年进行约4次，每年可能进行2-4次小补丁部署。每天增加15分钟（质量检查人员和开发人员）45分钟，这是我无法想象的。在大型企业应用程序中，如果您的应用程序是核心应用程序，那么更改它是正确的（小更改可能会产生深远的影响-必须与整个企业的消费者进行沟通和计划），这是一个巨大的活动-错误的架构OSGi。如果您的应用程序不是企业应用程序，即每个用户都可以拥有自己的定制模块，那么它们很可能会在各自的孤岛式数据库中访问自己的数据孤岛，并在承载许多应用程序的服务器上运行，那么可以看看OSGi。至少，

OSGi会抛出代码，NoClassDefFoundError并且ClassNotFoundException没有明显的原因（很可能是因为您忘记了将软件包导出到OSGi配置文件中）；因为它具有ClassLoader，所以它可能会使您的类com.example.Foo无法转换为对象，com.example.Foo因为它实际上是由两个不同的类加载器加载的两个不同的类。安装Eclipse插件后，它可使Eclipse引导进入OSGi控制台。

对我来说，OSGi只会增加复杂性（因为它为我增加了一个心理模型），由于异常而增加了烦恼。我从来没有真正需要它提供的动力。由于所有模块都需要OSGi捆绑包配置，因此它具有侵入性。这绝对不简单（在较大的项目中）。

由于我的糟糕经历，我倾向于远离那个怪物，非常感谢您。我宁愿遭受jar依赖地狱之苦，因为这比OSGi引入的类加载器地狱更容易理解。

如果基于Java的应用程序需要添加或删除模块（扩展应用程序的基本功能）而又不关闭JVM，则可以使用OSGI。通常，如果关闭JVM的成本更高，则仅仅是为了更新或增强功能。

例子：

1. Eclipse：提供用于插件安装，卸载，更新和相互依赖的平台。
2. AEM：WCM应用程序，其功能更改将由业务驱动，无法承受停机时间进行维护。

注意：Spring框架停止了对OSGI spring bundle的支持，将其视为基于事务的应用程序或这些行中某些点的不必要的复杂性。除非绝对必要，否则我个人不会考虑OSGI，例如构建平台之类的大事。

我已经使用OSGi进行了将近8年的工作，我不得不说，只有在业务需要在运行时更新，删除，安装或更换组件时，才应考虑使用OSGi。这也意味着您应该具有模块化的心态并了解模块化的含义。有一些论点认为OSGi是轻量级的-是的，的确如此，但是还有其他一些框架是轻量级的，并且易于维护和开发。安全java等等也是如此。

OSGi需要正确使用可靠的体系结构，并且很容易制作OSGi系统，使其成为独立运行的jar，而无需涉及任何OSGi。

OSGi提供以下好处：

■基于Java的可移植且安全的执行环境

■服务管理系统，可用于跨捆绑包注册和共享服务，并使服务提供者与服务使用者脱钩

■动态模块系统，可用于动态安装和卸载Java模块，OSGi称为捆绑软件

■轻巧且可扩展的解决方案

它也被用于在移动端带来中间件和应用程序的额外可移植性。例如，移动端可用于WinMo，Symbian，Android。与设备功能的集成一旦发生，可能会变得支离破碎。

至少，OSGi使您想到模块化，代码重用，版本控制以及总体上的项目管理。

其他人已经详细概述了好处，我在此解释我所见或使用过的OSGi的实际用例。

1. 在我们的一个应用程序中，我们有基于事件的流程，并且流程是在基于OSGi平台的插件中定义的，因此明天如果某些客户想要不同的/附加的流程，那么他只需要再部署一个插件，并在控制台中进行配置即可， 。
2. 它用于部署不同的Store连接器，例如，假设我们已经有了Oracle DB连接器，并且明天需要连接mongodb，然后编写一个新的连接器并进行部署，并通过控制台配置详细信息，然后再次完成。连接器的部署由OSGi插件框架处理。

它的官方网站上已经有一个令人信服的声明，我可以引用为

OSGi技术如此成功的关键原因在于，它提供了一个非常成熟的组件系统，该系统实际上可以在数量众多的环境中工作。OSGi组件系统实际上用于构建高度复杂的应用程序，例如IDE（Eclipse），应用程序服务器（GlassFish，IBM Websphere，Oracle / BEA Weblogic，Jonas，JBoss），应用程序框架（Spring，Guice），工业自动化，住宅网关，手机等等。

至于给开发商带来的好处呢？

开发人员：OSGi通过为当今的大型分布式系统以及小型嵌入式应用程序提供模块化体系结构来降低复杂性。使用内部和现成的模块构建系统可以大大降低复杂性，从而降低开发和维护费用。OSGi编程模型实现了基于组件的系统的承诺。

请检查使用OSGi的好处中的详细信息。