已经做了有几年时间的Java后台开发工作, 所以插件化框架这些东西真正可不是随便找个SPI就能搞定的。今天想聊几个在实际项目开发过程里碰到过的陷阱或者问题点。java插件化框架选型在我的这个项目里面, 我是使用了Maven结合自定义ClassLoader的这种处理方案的。这样做的话, 它的整体架构比OSGi要轻得多。其中的核心操作方式是, 我们需要把每一个单独的插件都打包成独立的jar包形式。然后在系统启动的过程中去扫描相应的目录来实现动态的加载。对于类隔离这一项机制是如何来保证的问题, 主要是靠打破父类委托这个方式来实现的, 这部分内容在文本中得到了类隔离靠打破父委托这样的强调表述。在选择技术框架的时候, 不能仅仅只是盯着文档去看, 其实最核心的关键点是观察这个框架具体是如何处理各个插件之间出现的依赖冲突问题的。我有亲眼见过这么一个大项目实例, 当时在该项目里有两个不同的插件各自引用了不一样版本的fastjson组件, 最终导致了ClassCastException异常的发生,然后开发人员足足花了一整天的时间来进行排查和解决。java插件化热部署方案在热部署这个方面, 真正最靠谱的其实是用URLClassLoader替换这种办法。具体的做法是把旧的实例里面的加载类的东西给它置空, 这样就能让垃圾回收机制去把它收走了。然后呢, 再去把新的jar包给重新加载一遍。对于那些说什么可以直接修改字节码来达到效果的说法, 大家千万别信。特别是在生产环境里用的时候, 绝对不要自己去折腾那些花哨的东西去弄什么热字节码修改。你必须把接口定义的那个操作, 严格地放置在插件端以及宿主端进行共同协作的api那个包里面去, 与此同时插件端的代码绝对不允许出现向宿主进行反向依赖的这种情形, 这条规则要是稍微有点被破坏了这种状态的话, 那么在卸载插件环节的时候就会直接抛出NoClassDefFoundError这个错误现象, 然后排查起问题来那就真的是非常痛苦的状态了。插件化这种技术在表面上看是挺简单的, 不过真正的难点在于非得去把边界给划清楚。具体到宿主方要暴露出来什么东西、插件方面能够去调用什么东西、以及在出现异常的时候要怎么去进行兜底处理, 把这些事项都得定好了之后, 后面再去搞迭代开发才能不慌啊。
