【Java服务部署难题与Solon机制】将一个Java服务打成单个fatjar发布出去后运维想更改数据源指向业务团队想在不重启进程的情况下下线模块若只能选择“重新打包、整包重发”会产生诸多不便。而Solon为解决这些问题准备了两套机制E-Spi体外扩展和H-Spi热插拔。不过选错机制代价要么是灵活性要么是稳定性。下面将详细介绍它们的使用方法和适用场景。【共同痛点fatjar密封难题】fatjar部署方便但修改困难配置文件和业务模块都被打包在其中。E-Spi和H-Spi都能解决这一问题但契约不同。E-Spi可将配置文件和插件jar放在fatjar外面启动时加载进同一运行时简单且无需额外依赖但变更需重启H-Spi为每个插件提供独立的ClassLoader可在服务持续运行时启停模块能力更强但责任也更大。【E-Spi配置与模块外置方案】E-Spi直接针对fatjar部署场景。指定一个扩展目录启动时Solon会扫描并加载其中内容包括.properties/.yml文件作为扩展配置.jar/.zip文件作为插件包。具体步骤如下第一步 ---- 声明扩展目录可通过配置solon.extend指定扩展目录若加上“!”前缀Solon会自动创建该目录。第二步 ---- 放置文件将相关文件放在jar旁边如demo.jar、demo_ext/_db.properties、demo_ext/demo_user.jar、demo_ext/demo_order.jar。这样数据源配置在jar外运维可直接修改配置文件无需触碰fatjar。第三步可选 ---- 代码加载若想在代码中加载额外内容内核提供了接口。底层是AppClassLoader.addJar(URL | File)体现了E-Spi的特点一切共享拆合随意更新需重启无额外依赖。同时插件jar打包有要求官方示例为“demo2002-external_ext”。【H-Spi隔离与热替换利器】H-Spi是更强大的工具可将业务模块开发成自包含的插件包服务运行时可实时加载和卸载。与E-Spi的本质区别是隔离每个插件有自己的ClassLoader、AppContext和配置更新插件无需重启主服务但主应用需引入solon-hotplug依赖。ClassLoader契约隔离是关键类的可见性规则重要。父ClassLoader的类和资源子级可见但子级注册的东西需在父级stop事件中注销兄弟ClassLoader之间无法使用彼此的类和资源需通过事件总线沟通。start与stop方法可热插拔的插件实现Plugin接口start方法注册模块所需资源stop方法必须移除注册过的所有资源否则会泄漏。模板渲染在ClassLoader上有坑渲染器需钉在正确的ClassLoader上。跨模块通讯靠事件总线配弱类型载荷官方示例包为“demo1011”插件管理可借助solon-hotplug进一步优化。【E-Spi与H-Spi对比】从ClassLoader、AppContext、配置共享情况更新后是否需重启额外依赖侧重点资源移除方式跨模块通讯方式底层机制等维度对比E-Spi和H-Spi各有特点。维度E-SpiH-SpiClassLoader / AppContext / 配置共享隔离完全更新后是否需重启是否热更新额外依赖无内核内置solon-hotplug侧重点简单体外扩展 / 改配置隔离 热插拔 管理资源移除无需特殊处理必须在“stop”里手动移除所有注册的资源跨模块通讯直接共享事件总线 / 弱类型数据底层机制AppClassLoader.addJar隔离ClassLoader “Plugin.start/stop”【如何选择E-Spi与H-Spi】选择时可思考“这东西必须在不重启的情况下变更吗”若不需要有重启窗口即可可选择E-Spi它能满足多数“不想重打fatjar”的场景无额外依赖和生命周期记账负担若需要模块变更时服务一直在线则选择H-Spi可获得真正的隔离和实时替换但需遵守stop清理纪律和跨模块契约。不少团队会同时使用两者E-Spi管外置配置H-Spi管需热替换的模块。对于长期演进的Solon服务结构设计建议仔细阅读官方文档。那么你的fatjar最需要先甩掉的是配置还是整个模块