ava 后端开发的日常中有几个场景几乎每个开发者都会反复遭遇开发阶段的改一行等半天。调试一个 FreeMarker 模板的样式问题每改一次就要重启应用——等待容器初始化、等待依赖注入完成、等待数据库连接池建好。真正有效的修改时间可能只有 5 秒但等待重启却要 30 秒甚至更久。一个下午下来累计浪费的时间相当可观。生产环境的半夜停机更新。某个业务模块需要紧急修复一个线上 Bug但部署方案是整体重新打包、停机、替换 JAR、重启。凌晨两点被叫起来操作不说关键是服务中断期间的用户体验损失。对于 7x24 运行的在线服务来说每一秒的停机都在透支信任。模块化部署的耦合困境。一个中大型系统往往包含用户管理、订单处理、消息通知、报表统计等多个业务模块。当所有模块打包在一个 JAR 里任何模块的小改动都意味着整体重新发布。模块之间本应独立演进却因为缺乏运行时的隔离和动态加载能力被迫绑在一起。这三个痛点分别指向了三个核心能力需求开发态的热加载、运行态的热插拔、架构态的模块隔离。Solon 框架在这三个方面提供了原生的、体系化的支持。这不是通过第三方工具拼凑出来的方案而是从框架内核层面设计的一套完整的插件管理与生命周期管控机制。具体来说Solon 提供了以下关键技术能力Debug 模式面向开发阶段的资源热更新模板和静态文件修改即时生效启动参数体系一套统一的参数控制机制覆盖环境切换、安全停机、扩展目录等E-Spi体外扩展机制基于共享 ClassLoader 的外部插件加载解决 fatjar 部署场景下的扩展需求H-Spi热插拔机制基于隔离 ClassLoader 的运行时插件管理支持不停机安装、卸载、更新业务模块solon-hotplug 插件为 H-Spi 提供管理能力的基础扩展插件插件开发模板标准化的插件工程结构让业务插件的开发有章可循插件间交互基于 EventBus 的松耦合通信模式以及父子 ClassLoader 的资源访问规则ClassLoader 隔离每个热插拔插件拥有独立的类加载器避免类冲突和资源泄漏完整生命周期从start()到stop()的全流程管控确保资源的注册与清理对称AppContext 上下文每个插件拥有独立的应用上下文实现真正的运行时隔离本文将逐一展开这些技术点从开发调试效率提升到生产级热插拔实战覆盖完整的知识链路。2. Debug 模式与资源热更新Solon 的 Debug 模式是一个面向开发阶段的功能。开启之后框架会以更高的检测频率监控资源文件的变化实现模板文件和静态资源的即时刷新无需重启应用。2.1 四种启用方式Debug 模式的启用非常灵活可以根据使用场景选择最合适的方式# 方式一程序启动参数最常用 java -jar demo.jar --debug1 # 方式二JVM 系统参数 java -Dsolon.debug1 -jar demo.jar除了命令行参数还有两种更便捷的启用方式solon-test 单元测试自动启用引入solon-test-junit5依赖后测试运行时 Debug 模式会自动开启无需额外配置。这意味着在编写单元测试时所有资源变更都能即时反映。IDE 开发工具配置在 IntelliJ IDEA 或其他 IDE 的运行配置Run Configuration中添加 VM 参数-Dsolon.debug1或程序参数--debug1即可。配置一次后续每次运行都生效。四种方式本质上是同一条配置入口的不同写法选择哪种取决于使用习惯和场景。2.2 效果一览开启 Debug 模式后不同类型资源的变化会触发不同的行为资源类型效果动态模板文件变更即改即生效FreeMarker、Thymeleaf、Enjoy 等静态资源文件变更即改即生效CSS、JS、HTML、图片等Java 类代码不支持需 JRebel 或 DebugTools 等第三方工具属性配置文件打印提示信息提醒开发者配置已变更其中最实用的就是模板和静态资源的热更新。在前端联调阶段修改一个 FreeMarker 模板的布局刷新浏览器即可看到效果开发效率的提升是实实在在的。2.3 需要关注的限制有几个关键点值得深入理解Java 类代码不会被自动热加载。这不是 Solon 的设计缺陷而是由 JVM 类加载机制本身决定的。一个类一旦被 ClassLoader 加载在同一个 ClassLoader 内就无法被替换。要实现 Java 代码的热替换需要借助 JRebel、DebugTools 等在字节码层面工作的第三方工具。solon-proxy 插件会额外打印代理类信息。在 Debug 模式下如果你使用了solon-proxy插件Solon 的 AOP 动态代理实现框架会打印出动态代理的实现类名。这在排查 AOP 代理链问题时非常有用——你可以清楚地看到某个 Bean 被几层代理包裹每一层的实现类是什么。Debug 模式有性能损耗。更频繁的资源变更检测意味着更多的文件系统 I/O 操作和模板重新解析开销。因此仅建议在开发环境开启生产环境务必关闭。这也符合 Debug 模式的设计初衷——它就是一个开发调试辅助工具不是为生产环境准备的。在实际开发中建议将--debug1配置在 IDE 的开发运行配置中而生产部署脚本中明确不传该参数避免误操作。3. 启动参数体系Solon 提供了一套完整的启动参数体系用于在应用启动阶段控制各种行为。理解这套参数体系是掌握 Solon 运维能力的基础。3.1 一个关键前提启动参数有一个重要特性需要首先明确所有启动参数在应用启动完成后会被静态化。这意味着启动参数在启动时读取一次后就固定下来了运行期间无法通过任何方式修改。这个设计是为了内部更高效的利用——参数值不需要每次访问都去解析和判断直接缓存为常量即可。这也带来一个实际影响如果你想通过 E-Spi 体外扩展加载外部配置文件来覆盖启动参数是做不到的。启动参数的优先级高于一切外部配置。3.2 完整参数表启动参数对应应用配置描述--envsolon.env环境可用于配置切换--debugsolon.debug调试模式0 或 1--scanning—是否扫描默认 1--setupsolon.setup安装模式0 或 1--whitesolon.white白名单模式0 或 1--driftsolon.drift漂移模式部署到 K8s 设为 1--alonesolon.alone单体模式0 或 1--extendsolon.extend扩展目录路径--localesolon.locale地域设置--configsolon.config指定外部配置文件路径--config.add—追加配置文件--app.namesolon.app.name应用名--app.groupsolon.app.group应用分组--stop.safesolon.stop.safe安全停止0 或 1--stop.delaysolon.stop.delay安全停止延时秒数默认 10 秒3.3 三种等价写法Solon 的启动参数有三种等价的传入方式以设置运行环境为dev为例# 写法一JVM 系统属性 java -Dsolon.envdev -jar demo.jar # 写法二启动参数带 solon. 前缀 java -jar demo.jar --solon.envdev # 写法三启动参数短名称 java -jar demo.jar --envdev三种写法完全等价最终都会被解析为solon.env配置项。写法一通过 JVM 标准的-D参数设置系统属性写法二和写法三通过 Solon 自定义的--参数协议传入短名称是完整配置名的便捷缩写。3.4 几个重点参数的深入理解--env环境切换的核心开关。设置--envdev后Solon 会自动加载app-dev.yml作为环境配置与app.yml合并。不同环境使用不同的配置文件这在多环境部署中几乎是刚需。--stop.safe和--stop.delay优雅停机的关键配置。开启安全停止模式后Solon 在收到停止信号时不会立刻关闭而是先停止接收新请求等待已有请求处理完毕最长等待stop.delay秒默认 10 秒然后再执行关闭流程。在 Kubernetes 环境中这个能力至关重要——Pod 滚动更新时旧 Pod 需要优雅地处理完存量请求再退出。--drift为 K8s 量身定制的漂移模式。当 Pod 在集群中发生迁移例如节点故障导致的重新调度某些有状态的服务可能需要感知到这种变化并做出响应。设置--drift1后框架会在漂移场景下提供相应的状态保持和感知能力。--extendE-Spi 体外扩展的入口。指定一个外部目录路径Solon 启动时会自动扫描该目录下的 JAR 文件和配置文件并加载。这个参数是下一节要讲的 E-Spi 机制的基础配置。--scanning控制 Bean 扫描行为。默认值为 1表示正常扫描主类所在包及其子包下的所有组件。设置为 0 则跳过扫描——某些特殊场景下比如纯插件模式运行所有 Bean 由插件自行注册关闭自动扫描可以减少不必要的类路径遍历开销。3.5 在代码中访问启动参数由于所有带.的启动参数同时会成为应用配置因此可以通过Solon.cfg()在代码中随时获取Component public class StartupPrinter { Inject(${solon.env}) String env; Init public void init() { System.out.println(当前环境: env); System.out.println(应用名称: Solon.cfg().appName()); System.out.println(安全停止: Solon.cfg().get(solon.stop.safe, 0)); } }需要再次强调的是Solon.cfg()返回的配置在启动后是只读的。虽然你可以调用loadAdd()方法追加新的配置源但已经静态化的启动参数值不会被覆盖。在实际项目中建议将环境相关的参数如--env通过部署脚本或 K8s ConfigMap 注入而非硬编码在启动命令中。这样不同环境的部署差异可以通过运维配置来管理保持应用包的一致性。4. E-Spi体外扩展机制当我们把一个 Java 应用打包成 fatjar 部署到服务器时一个很现实的问题浮现出来如何在不重新打包主程序的前提下动态添加新的业务模块或修改配置传统的 classpath 扩展方式在 fatjar 模式下完全失效——你无法往一个已经打好的 JAR 包里追加 class 文件。E-SpiExternal Spi就是 Solon 内核为应对这个场景而直接提供的体外扩展机制。4.1 它解决什么问题考虑一个典型的生产部署场景你的主应用是order-service.jar业务上需要在不同客户环境中加载不同的扩展模块。有些客户需要短信通知模块有些需要特定的支付对接模块。你当然可以把所有模块都打进主应用但这会导致 fatjar 越来越臃肿而且任何一个小模块的更新都意味着整个应用要重新打包部署。E-Spi 的思路很直接把扩展模块和配置文件放在 JAR 包外部的一个目录中启动时由框架自动扫描加载。4.2 配置与文件结构在app.yml中声明扩展目录solon.extend: demo_ext # 手动创建目录目录不存在会静默跳过 solon.extend: !demo_ext # 前缀 ! 自动创建目录两种方式的区别仅在于目录是否自动创建。带!前缀时Solon 会在启动时自动创建该目录不带时如果目录不存在就安静地忽略——这在某些环境下更安全因为你可以通过是否创建目录来控制扩展是否生效。部署后的文件结构如下demo.jar demo_ext/ _db.properties # 外部配置文件如数据源配置 demo_user.jar # 外部插件包 demo_order.jar # 外部插件包启动时Solon 会自动扫描demo_ext目录下所有.jar、.zip作为插件包加载和.properties、.yml作为配置文件加载。整个过程零代码、零配置——放到目录里就行。4.3 代码方式的灵活加载如果你的需求更动态不想依赖固定目录也可以通过代码手动加载SolonMain public class Application { public static void main(String[] args) throws Exception { Solon.start(Application.class, args, app - { // 手动加载外部 jar 包 app.classLoader().addJar(new File(/demo.jar)); // 手动加载外部配置文件 app.cfg().loadAdd(new File(/demo.yml)); }); } }这种方式在Solon.start()的初始化回调中执行灵活性更高——你可以根据命令行参数、环境变量甚至远程配置来决定加载哪些扩展包。4.4 核心设计共享而非隔离E-Spi 最关键的设计决策是共享 ClassLoader。所有通过 E-Spi 加载的外部插件包和主应用使用同一个 ClassLoader、同一个 AppContext、同一份配置。这意味着什么外部插件中注册的Component、Controller等 Bean在主应用的AppContext中完全可见可以直接Inject注入外部插件可以直接引用主应用中的类和接口无需额外的 RPC 或序列化开销外部配置文件会与主配置合并就像它们本来就在app.yml里一样这种共享模型的代价是更新任何外部插件或配置后必须重启主服务。因为共享 ClassLoader 意味着类一旦加载就无法卸载热更新在共享模型下是不安全的。4.5 插件包打包的实践建议关于插件包如何打包有两种方案方案一fatjar 打包。使用maven-assembly-plugin将插件包连同所有依赖打成一个完整的 fatjar。简单粗暴但体积大且容易出现依赖版本冲突。方案二推荐公共依赖上提。将公共依赖如 Solon 核心、日志框架、工具库等放在主应用的pom.xml中插件包的pom.xml将这些依赖标记为optionaltrue/optional。这样插件包只包含自己的业务代码和私有依赖体积更小也从根本上避免了版本冲突。E-Spi 由 Solon 内核直接支持无需引入任何额外依赖。如果你的场景不需要热更新E-Spi 就是成本最低、最直接的体外扩展方案。5. H-Spi热插拔机制如果说 E-Spi 是体外扩展的经济型方案那 H-SpiHot-Spi就是为生产环境热插拔场景量身定制的高级方案。两者的核心区别可以用一个词概括隔离。5.1 为什么需要隔离E-Spi 的共享 ClassLoader 模型虽然简单但存在一个根本性的限制共享意味着耦合。当所有插件共享同一个 ClassLoader 时一个插件加载的类可能会影响另一个插件的行为——比如两个插件依赖同一个库的不同版本或者一个插件注册的 Bean 意外覆盖了另一个插件的同名 Bean。在共享模型下卸载一个插件并保证不影响其他插件几乎是不可能的。H-Spi 选择了完全不同的路径每个插件包独享 ClassLoader、AppContext 和配置完全隔离。这种设计牺牲了一些开发便利性但换来了真正的运行时独立性——你可以随时加载、卸载、更新任意一个插件而不影响主服务和其他插件的运行。5.2 与 E-Spi 的核心对比维度E-SpiH-SpiClassLoader共享独享完全隔离AppContext共享独享配置共享独享更新后是否重启需要不需要依赖内核直接支持需引入solon-hotplug适用场景简单外部扩展生产热插拔、模块隔离这张表基本决定了你的技术选型如果你的扩展模块更新不频繁或者可以接受重启E-Spi 就够了。如果你需要在线上不停机更新模块——比如一个 SaaS 平台需要在不同租户环境下动态加载业务模块——H-Spi 是唯一的选择。5.3 ClassLoader 隔离的规则H-Spi 的隔离遵循双亲委派模型的变体理解这个规则对正确开发热插拔插件至关重要父级到子级子级插件可以获取并使用父级 ClassLoader即主应用中的类和资源。这是合理的——公共库如数据库驱动、工具类放在主应用中所有插件都能用。但有一个硬性约束如果子级注册了什么资源到公共空间必须在插件的stop()方法中注销。否则插件卸载后这些注册就会成为悬挂引用造成资源泄漏。同级之间同级插件的 ClassLoader 互相不可见无法直接访问对方的类和资源。插件之间如果需要通信必须通过事件总线EventBus进行且交互数据应使用弱类型如Map、JsonString而不是强类型的自定义 DTO——因为你根本无法引用对方定义的类。这种设计思路可以类比为微服务架构中的服务间通信每个插件就像一个独立服务它们之间通过消息而非方法调用交互。官方也建议结合 DamiBus 来帮助解耦。5.4 一个必须遵守的开发约束H-Spi 插件的stop()方法不是可选的——它是插件生命周期中最关键的一环。每个在start()中注册到公共空间的资源都必须在stop()中精确移除路由规则、定时任务、事件订阅、静态文件映射一个都不能遗漏。否则所谓的热插拔就变成了热泄漏。6. solon-hotplug 插件solon-hotplug 是 H-Spi 机制的具体实现插件提供了从底层热插拔到上层管理的完整能力。理解它的 API 分层设计有助于在实际项目中做出正确的技术选择。6.1 依赖引入dependency groupIdorg.noear/groupId artifactIdsolon-hotplug/artifactId /dependency6.2 两层 API 设计solon-hotplug 提供了两层 API面向不同的使用场景底层接口PluginPackage这是最基础的原子操作接口直接操作单个 JAR 包的加载与卸载。一般不直接使用但理解它有助于掌握整个机制的运作方式// 加载 jar 包并返回插件包对象 PluginPackage jarPlugin PluginPackage.loadJar(new File(/xxx/xxx.jar)); // 启动插件执行插件生命周期的 start jarPlugin.start(); // 卸载插件执行插件生命周期的 stop并释放 ClassLoader PluginPackage.unloadJar(jarPlugin);PluginPackage是对单个插件包的完整抽象包含其独立的 ClassLoader、AppContext 和配置。loadJar负责创建隔离环境并加载类start触发插件生命周期unloadJar则执行清理并释放资源。管理接口PluginManager推荐使用PluginManager在PluginPackage之上封装了注册-管理-调度的能力是日常开发中推荐使用的接口PluginManager.add(add1, /x/x/x.jar); // 注册插件声明名称和路径 PluginManager.remove(add1); // 移除注册 PluginManager.load(add1); // 加载插件 PluginManager.start(add1); // 启动插件未加载则自动加载 PluginManager.stop(add1); // 停止插件 PluginManager.unload(add1); // 卸载插件未停止则自动停止注意到两个关键的自动化行为start(name)时如果插件尚未加载会自动执行加载unload(name)时如果插件尚未停止会自动执行停止。这种防御性设计避免了因操作顺序不当导致的异常。6.3 热管理的两种方式配置文件声明式在app.yml中声明待管理的插件solon.hotplug: add1: /x/x/x.jar # 格式name: jarfile add2: /x/x/x2.jar启动时 solon-hotplug 会读取配置但不会自动加载和启动这些插件——它们只是注册了等待你通过代码按需启动。