OSGi确实面临鸡肋之嫌

　

osgi

osgi最明显的缺陷

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

推荐的应用架构方式

• 因此必须将基于进程间构建的分布式应用和进程内的单一应用分开来架构设计，对于进程间构建的分布式应用，采取基于soa的理念进行容器模式的服务部署模式，服务交互基于远程服务交互相关协议，采用可忍受网络失败的架构设计原则；
• 对于进程内的应用，如果需要模块级的独立生命周期热部署和模块管理，可以考虑采用OSGI,但是，容器内基于本地进程间通信的模块交付方式不仅能提供同样的独立生命热部署和模块管理，而且具备随时脱离出去部署成单独容器级服务应用的能力，加速进程间的服务交付提供的整体管理和监视环境基础.
• osgi还有用武只地吗？当然我前述都是以构建分布式企业和面向互联网这类应用为前提来讨论的，对于嵌入式的jvm应用，比如著名的osgi案例宝马的车载系统，osgi依然是最好的原则，不过我怀疑基于andriod系统的机制构建类似应用，osgi的采用依然值得商榷。因此，osgi确实面临鸡肋之嫌。

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

• 为什么要分布

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

• 分布失去了什么
  • 进程内服务调用的便利性和可测试性
  • 代价巨大的资源分布导致的跨资源事务能力
  • 部署和运维工作量指数级增长
  • 不可靠网络的应用状态一致性
  • 及其复杂的分布式应用依赖关系
• 分布式关键技术选择
  • 容器级的分布式应用工程和部署管理；
  • 可视化的分布式应用及服务监视管理视图；
  • 前端和后端应用的分离；
  • 客户端路由
  • 服务注册中心
  • 分布式协调
  • 消息中件间
  • 分布式存储
  • 集成框架

　备注：最近研究camel，再次提到osgi的运行模式，再次反思分布式应用架构的技术栈选择，有了前述之感，姑且作为当前的想法笔记，免得后续在选择技术方向时又犹豫不决。

相关阅读