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

2019-10-25 06:59:10来源:博客园 阅读 ()

新老客户大回馈,云服务器低至5折

[插件化开发] 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提供的热插拔来实现插件模式,只是需要重新加载应用上下文,因此,建议各位部署多实例节点,在升级服务时,采用灰度发布来降低影响。


原文链接:https://www.cnblogs.com/zhangpan1244/p/11724791.html
如有疑问请与原作者联系

标签:

版权申明:本站文章部分自网络,如有侵权,请联系:west999com@outlook.com
特别注意:本站所有转载文章言论不代表本站观点,本站所提供的摄影照片,插画,设计作品,如需使用,请与原作者联系,版权归原作者所有

上一篇:java 异常捕获小记

下一篇:oop面向对象【继承、super、this、抽象类】