OSGI(Open Services Gateway Initiative) Java动态化模块化系统的一系列规范。

个人理解为支持模块热部署，方便模块管理。

OSGI ：
bundle是OSGi的部署(和模块)单元。在OSGi运行时，bundle具有如下三种状态：installed，resolved，active。在Spring中最主要的单元模块是应用程序上下文（application context），在应用程序上下文里包括了一些bean（被Spring的应用程序上下文所管理的对象）。在OSGi bundle和Spring应用程序上下文之间有很自然的紧密联系。
使用Spring Dynamic Modules（Spring DM），一个active的bundle可以包含一个Spring 应用程序上下文，它负责在bundle里实例化、配置、组装和装饰对象（bean）。这些bean即可作为OSGi服务输出而提供给其他bundle，也能透明地注入其他OSGi服务的引用。

分布式：
1、系统间相互隔离，系统之间的交互通过RPC来调用，即提供方提供接口及实现，调用方直接调用，阿里采用的是sofa框架集成的tr，ws等。

2、另一种为消息模式，一方作为消息发送端发送消息，一方作为消息接收端接收消息（发送的消息体对象必须序列化），消息中间件：阿里采用msgbroker（订阅关系管理及消息转发）。现市面使用zookeeper。

以下转载分布式RPC框架性能大比拼：
Dubbo 是阿里巴巴公司开源的一个Java高性能优秀的服务框架，使得应用可通过高性能的 RPC 实现服务的输出和输入功能，可以和 Spring框架无缝集成。不过，略有遗憾的是，据说在淘宝内部，dubbo由于跟淘宝另一个类似的框架HSF（非开源）有竞争关系，导致dubbo团队已经解散（参见http://www.oschina.net/news/55059/druid-1-0-9 中的评论），反到是当当网的扩展版本仍在持续发展，墙内开花墙外香。其它的一些知名电商如当当、京东、国美维护了自己的分支或者在dubbo的基础开发，但是官方的库缺乏维护，相关的依赖类比如Spring，Netty还是很老的版本(Spring 3.2.16.RELEASE, netty 3.2.5.Final),倒是有些网友写了升级Spring和Netty的插件。

Motan是新浪微博开源的一个Java 框架。它诞生的比较晚，起于2013年，2016年5月开源。Motan 在微博平台中已经广泛应用，每天为数百个服务完成近千亿次的调用。

rpcx是Go语言生态圈的Dubbo， 比Dubbo更轻量，实现了Dubbo的许多特性，借助于Go语言优秀的并发特性和简洁语法，可以使用较少的代码实现分布式的RPC服务。

gRPC是Google开发的高性能、通用的开源RPC框架，其由Google主要面向移动应用开发并基于HTTP/2协议标准而设计，基于ProtoBuf(Protocol Buffers)序列化协议开发，且支持众多开发语言。本身它不是分布式的，所以要实现上面的框架的功能需要进一步的开发。

thrift是Apache的一个跨语言的高性能的服务框架，也得到了广泛的应用。

以下内容转载自 osgi确实面临鸡肋之嫌

osgi最明显的缺陷

bundle尽管可以为隔离的服务建立独立生命周期管理的热部署方式，以及明确的服务导出和导入依赖能力，但是其最终基于jvm，无法对bundle对应的服务实现计算资源的隔离，一个服务的故障依然会导致整个jvm crush,这使得在一个运行时的osgi上部署模块级服务只获得了模块部署和启停隔离，服务明确依赖的好处，但是没办法实现计算节点的线性扩展，在当前分布式，微服务，网络计算的趋势下，使得osgi只适合构建单一服务节点的内部应用，但是其分离的bundle的部署负担对于微服务架构来说，有点用大炮打蚊子的臭味。

推荐的应用架构方式

因此必须将基于进程间构建的分布式应用和进程内的单一应用分开来架构设计，对于进程间构建的分布式应用，采取基于soa的理念进行容器模式的服务部署模式，服务交互基于远程服务交互相关协议，采用可忍受网络失败的架构设计原则；

对于进程内的应用，如果需要模块级的独立生命周期热部署和模块管理，可以考虑采用OSGI,但是，容器内基于本地进程间通信的模块交付方式不仅能提供同样的独立生命热部署和模块管理，而且具备随时脱离出去部署成单独容器级服务应用的能力，加速进程间的服务交付提供的整体管理和监视环境基础.

osgi还有用武只地吗？当然我前述都是以构建分布式企业和面向互联网这类应用为前提来讨论的，对于嵌入式的jvm应用，比如著名的osgi案例宝马的车载系统，osgi依然是最好的原则，不过我怀疑基于andriod系统的机制构建类似应用，osgi的采用依然值得商榷。因此，osgi确实面临鸡肋之嫌。

分布式应用的关键技术点及解决思路汇总

为什么要分布

为得到吞吐量和可靠性及故障隔离的架构属性，需要将传统的单一应用按照业务逻辑进行垂直拆分以实现构建工程的独立，部署的独立。

分布失去了什么

进程内服务调用的便利性和可测试性

代价巨大的资源分布导致的跨资源事务能力

部署和运维工作量指数级增长

不可靠网络的应用状态一致性

及其复杂的分布式应用依赖关系

分布式关键技术选择

容器级的分布式应用工程和部署管理；

可视化的分布式应用及服务监视管理视图；

前端和后端应用的分离；

客户端路由

服务注册中心

分布式协调

消息中件间

分布式存储

集成框架