1.初识OSGI
OSGI的全称是Open Service Gateway Initiative，直接翻译过来理解很费劲。为了理解这个问题，我们先看看OSGI的设计目的与实现特点是什么。
在传统Web开发中，我们为了进行功能的分离，经常会进行模块划分，比如基础信息模块交由A和B做，接口信息模块交由C和D做。最终，再汇集到一起，组成一个完整的项目。在这整一个流程中，我们做到的只是逻辑上的解耦，最终这些模块还是运行于同一服务器上，共享同一个classpath。这时就会出现一个局限性问题，比如现在接口规范改了，我只想停掉接口信息模块，而基础信息模块仍能正常运行，这显然是无法实现的。
而使用OSGI可以完美解决这个问题，OSGI是基于模块（Bundle）驱动的，每个模块都有属于自己的classpath和类加载器，模块之间通过包暴露和引入进行关联，每个模块有着自己独立的生命周期，我们可以动态地对模块进行加载、卸载、更新。如此看来，OSGI可以用一句话描述，就是一个为Java提供的动态模块化的系统。
2. OSGI中模块的生命周期
在OSGI中，每个Bundle有着下列六种状态，状态图如图2-1所示：
Ø INSTALLED — 成功安装Bundle。
Ø RESOLVED — 所有Bundle需要的Java类可用。这个状态标志着 bundle已经是启动就绪或者是已经停止。
Ø STARTING — 正在启动Bundle。调用了Bundle**器的start方法，而且还没有从方法中返回。
Ø ACTIVE — Bundle已经启动完毕，正在运行中。
Ø STOPPING — 正在停止Bundle。调用了Bundle**器的stop方法，而且还没有从方法中返回。
Ø UNINSTALLED — Bundle已经卸载完毕，不能进入其他状态。
图2-1 Bundle生命周期状态图
3. OSGI与SOA
通过前面的说明，我们可以发现，OSGI可以看成是一个服务发布规范，每个模块可以看成是一个服务包，模块可以进行注册、监听，模块间通过暴露服务进行联系，很显然，这是SOA的思想嘛。在OSGI RFC 119之前，OSGI只能运用于单体架构，与主要用于分布式架构的SOA有着本质的区别，RFC 119增加了分布式领域规范，这使得OSGI适用于实现SOA。
4. OSGI现状
OSGI目前在国内只有为数不多的公司和项目有在使用，究其原因，还是它的弊端太大了。OSGI过于复杂，似乎每个程序员用过了都说不好，主要问题有以下几点：
（1）入门门槛高，OSGI规范多达几十个，并包含上千个API；
（2）增加系统不稳定性，由于OSGI类加载机制比较特别，经常会出现不明原因的ClassNotFoundException等异常；
（3）应用性不强，运用OSGI大部分是因为其“热插拔”和Jar隔离特性，但是，如果不是对动态性要求特别高的项目，引入OSGI似乎只是徒增麻烦。
目前，OSGI的应用更多的是因为其模块性和服务性，这与主流的微服务也是融合的，但是其复杂性使得它很难成为主流。
附阿里架构师对OSGI的评价：http://hellojava.info/?p=152