OSGi是什么，能够解决的问题（os是啥?）

1. 什么是OSGi

OSGi——Open Service Gateway Initiative，最初的目的是为各种嵌入式设备提供通用的软件运行平台。后来经过10年的发展和壮大，OSGi已经不只是在嵌入式设备中应用，而是被推广到各种其他的应用领域，比如其中最成功的Eclipse IDE。目前在企业级应用开发中也开始大量使用OSGi技术，尤其是在应用服务器领域，各大主要厂商相继宣布推出支持OSGi规范的中间件产品，例如Websphere、Glassfish、JBoss等。而从应用开发人员的角度来说，OSGi应该被理解为：OSGi Service Platform，它是一个开放的并且提供统一接口标准的体系框架，基于这个体系框架，服务提供商，应用开发人员，软件提供商，服务网管运营商，设备提供商之间能够联合起来相互协作，形成一个健康的生态系统，并向终端用户提供各种各样的服务(例如：SaaS，SOA等)。

2. OSGi能带来什么好处，能解决什么样的问题？

做为一名实用主义者，新技术或新概念除了能够带给我们暂时的新鲜感外，还应该了解它是否能给我们的工作带来实际的好处，它能帮助我们解决怎么样的问题。OSGi与所谓的“云计算”相比并不算什么新技术，它已经存在了10年，所以它是成熟的、可靠的、经过验证的。只是相对于企业级开发领域来说，它还未被充分的实践，所以对企业级开发来说OSGi的确能算得上是新技术。以下是我眼中的OSGi给我带来的好处以及能够帮助我解决的问题，但不仅限于此，更有待您的发掘。

首先，OSGi改变了我们设计系统的传统思维模式（评价一名优秀的架构师，思考问题的方式是至关重要的评判指标之一）。模块化的系统设计理念并非新事物，早在面向对象的设计思想诞生之前就已经出现。在面向过程的程序开发中，模块化是非常重要的工具，它可以提高程序的内聚性，降低程序的耦合度，并且在大规模协同开发中发挥着重要的作用。当然OSGi对模块化又做了更进一步的发展，提出了服务平台（Service Platform）的概念——在网络环境下的服务平台，从此我们从面向对象的时代步入面向服务的时代。我们不再把关注重点放在如何高度抽象出优美的对象模型上，而是更加注重根据实际的业务需求划分各种服务接口的边界以及各服务接口之间的依赖关系。当然，组成服务内部的构件仍然基于面向对象的思想，只不过不再成为我们唯一的关注重点。在当今SaaS(软件即服务)的大趋势下，能提供何种质量的服务将被作为评判企业级管理软件优劣的重要标准，因为服务是用户唯一可见的交互渠道，系统内部的对象模型对用户来说只是一个黑盒子（这里的用户并非单指终端用户，也包括使用服务的开发人员）。而OSGi正好能用来解决如何更好的抽象服务，拆分复杂业务逻辑等诸如此类的问题。

其次，OSGi使我们可以更好的控制每个模块之间的约束和依赖。它可以让我们明确定义各模块的运行时环境（JDK版本）、导入包、导出包、依赖包，而所有的这些依赖关系的合法性验证均由OSGi运行时容器自行完成，当出现jar包版本冲突，依赖丢失等错误时，OSGi可以明确的给出提示信息，帮助我们尽快的定位问题、解决问题。在某些场景中，我们并不希望暴露某些模块的package，这时我们只需要在定义文件中不导出这些package就可以了，实现了包级别的封装控制机制。

再次，OSGi可以解决企业级应用系统启动速度慢的问题。随着企业业务的快速增长，员工对企业级应用系统的依赖程度也就越来越高，各种新的功能不断的被加入到原来的系统中，使得系统越来越臃肿。而系统中的有些功能并非被经常使用，却需要经历非常复杂的初始化过程，为了启动这个不被经常使用的功能，整个企业级应用系统的启动时间被整整拖延了数分钟（OK！您可能觉得我说的言过其实了，但是这的确是真的，我发誓！）。启动如此缓慢的应用，对于开发和测试来说简直就是噩梦，因为每次的代码修改都需要漫长而无谓的等待才能看到真正的结果。通过OSGi，我们可以将臃肿的业务逻辑拆分成边界清晰的功能模块，并对模块启动顺序进行规划，即那些模块需要第一时间启动，那些模块可以延迟加载，最后通过Bundle元数据文件（MANIFEST.MF）进行明确的启动策略定义。只有当正真需要这个模块时，OSGi运行时容器才会去加载它。这样就可以使启动缓慢的企业级应用系统如同Apache Server那样快速启动。

最后，OSGi可以实现我梦想中“即插即用，即拔即无”的奇妙系统。热部署可能是所有了解OSGi的人不假思索就能说出的特性。目前所有的web容器均实现了热部署功能，我们可以在不停止服务的前提下动态的部署各种应用程序。如果能将此功能带入到我们自己开发的系统中那将是多么的cool啊！OSGi将实现我们的梦想，我们可以在OSGi环境下掌控所有模块的生命周期方法，比如安装、启动、停止、卸载等，而这些操作均可在不停止当前应用的情况下进行，大大提高了无故障运行时间。并且我们还可以并发运行相同模块的不同版本，当某个新发布的版本出现问题时，我们可以暂时停止该模块，并重新启动前一个稳定版本，以隔离出问题的模块，而所有的这一切对用户来说都好像从来没有发生过一样。

个人认为，OSGi最大的好处并不是那些在各类网络文章中反复描述的“语法糖”，而是它改变了我设计系统架构的思维模式，它帮助我形成了一套面向服务的模块化架构设计思路，让我成为一名可以站在更高层次来考虑系统设计的优秀架构师（架构师如果在设计前期就陷入细节设计的话，那将是一个非常糟糕的开始）。

3. 我们真的需要OSGi吗？

虽然OSGi存在这样那样的问题，但是在企业级开发中它的确是存在价值的，我们评判一个事物是否有需要往往会考虑它的价值，是否利大于弊。所以做为架构师的你是否有一种冲动，是否会大声的对着项目经理说——下一个项目我们就用OSGi来构建。慢来！先让我们冷静一下，问一下自己，我们的项目真的需要OSGi吗？OSGi会不会像达摩克利斯之剑那样，在美妙的背后却隐藏着巨大的风险呢？对于我们技术人员来讲，没有最好的技术，只有最适合的技术。OSGi不是“银弹”，不可能帮助我们解决所有的问题。在为一个项目确定是否需要OSGi时，可以将OSGi的各项特性罗列出来，然后针对自己的系统逐一核对，评估每一项特性是否是系统真正需要的。比如你的系统只是一个部门内部使用的小工具，而且其他部门对此系统并不敢兴趣，那这样的系统就没有必要使用基于OSGi的架构，如果使用了反而会增加系统的复杂度，从而提高开发成本。而那些为企业级应用系统提供基础服务的服务端系统来说则更加的适合OSGi架构，因为通过模块化，它可以提供更加稳定的服务(7*24运行时间)。这里我需要特别的指出，OSGi需要生存在一个生态系统环境中，才能展现它的价值所在，所以更加适合解决方案级别的系统架构。如果在您的生态系统环境中只存在1，2个OSGi的系统，那就好比走在南极冰盖上的大象，等待它的只有死亡。