[插件化开发] Poc之后，我选择放弃OSGI

poc之后，我选择放弃osgi

tips:
如贵司允许重构老系统或者允许使用osgi的第三方框架改造所带来的投入成本，并且评估之后roi乐观，那么还是可以使用的。

runtime version

以下问题全部基于equinox框架 & 使用blueprint 整合spring框架

• osgi
  • org.eclipse.osgi 3.15.0v20190830-1434
• equinox version
  • equinox 4.13
• spring framework
  • 5.0.4p
  • 3.0.0
• blueprint
  • 3.0.0.m1
• mybatis
  • 3.5.3
• mybatis-spring
  • 1.3.2
• mysql
  • 5+/8+

现状

以下方案前提条件：不使用第三方框架（camel/karaf...）。

• spring 3 整合
  使用spring3 实现了springmvc的整合，但是无法支持restful支持。
  spring3以后，好像就没有人维护osgi的版jar包了，想要使用更高版本，只能自己生成bundle.
• spring5 整合
  基础spring bean注入通过xml方式已经成功，但是目前的bundle缺失较多，最重要的为jdbc & transaction,spring 在3.2之后升级为spring-tx，而且不提供osgi版本，造成我们现有项目大部分业务需要重构，工作量巨大（等同于重写service）

问题

1. 如何在不使用第三方框架的情况下提供rest service暴露?

   暴露rest service 利用，osgi自带的httpservice服务，再通过org.eclipse.equinox.servletbridge.bridgeservlet把服务桥接出去

2. 关于现有的springmvc单体应用，如何将每一个controller中的所有methods封装为bundle中的bean services 对外统一暴露而不是one by one?
3. 如何在bundle使用spring annotation/是否可以使用？

4. 如何将现有springmvc 项目直接生成一个full bundle以提供对外暴露services, 并且对现有项目无侵入或很少侵入？

基于众多原因：

1. 社区停滞维护，技术较陈旧
2. 第三方开源框架可以实现，问题是对于我们原有系统改动太过巨大。
3. 未来遇到的问题无法得到外部解决，只能我们自身针对性对底层进行扩展。
4. 对于初中级朋友来说，学习成本太高（我翻阅了国内外大多数资料）
5. 如果不能重新编写新项目的话，对于原系统的改造成本太高。
6. ...

替代方案

我选择放弃该方案，使用servlet 3.0提供的热插拔来实现插件模式，只是需要重新加载应用上下文，因此，建议各位部署多实例节点，在升级服务时，采用灰度发布来降低影响。