Solon 作为一款轻量级 Java 应用开发框架,近期连续发布了 v..、v.. 和 v..-M 三个版本更新,并正式启动了长期支持(LTS)计划。这标志着框架进入更稳定的发展阶段,对于企业级用户和开发者而言具有重要意义。
在实际项目中使用 Solon 近两年,我发现其"约定优于配置"的设计理念能显著降低 Spring 迁移成本。最新版本通过模块化拆分进一步提升了轻量化特性,基础包仅 0.1MB 大小,启动时间保持在 0.1 秒级别,特别适合云原生场景下的微服务部署。
提示:v..-M 版本中的 M 表示里程碑版本(Milestone),通常包含即将在稳定版中发布的新特性预览,生产环境建议等待对应的 GA 版本。
本次版本更新对内核进行了三项关键改进:
java复制@Configuration
public class AppConfig {
@Bean
public void setup(SolonApp app) {
app.cfg().set("solon.plugin.hotswap.accelerate", true);
}
}
智能路由调度:新版路由表采用前缀树结构优化,基准测试显示 5000+ 路由项时的匹配效率提升 40%。特别是在 RESTful API 场景下,带参数路径的解析速度从 1200ns/次降至 750ns/次。
内存管理增强:引入弹性对象池替代部分场景的即时对象创建,在高并发测试中,GC 停顿时间减少约 15%。这对于内存敏感的 Serverless 环境尤为重要。
版本对比表格清晰展示各版本差异:
| 特性 | v.. 企业版 | v.. 社区版 | v..-M 里程碑版 |
|---|---|---|---|
| GraalVM 原生镜像支持 | ✅ | ✅ | ✅(增强) |
| Kotlin DSL 扩展 | ✅ | ❌ | ✅(实验性) |
| 分布式事务插件 | ✅ | ❌ | ❌ |
| 响应式编程增强 | ✅ | ✅ | ✅(新API) |
| 监控中心集成 | ✅ | ❌ | ❌ |
企业版独有的监控中心提供了线程池、连接池等关键指标的实时可视化,我们在金融项目中借助该功能成功将线上故障定位时间从小时级缩短到分钟级。
Solon 的 LTS 计划采用 3+2 模式:
当前被纳入 LTS 的版本是 v.. 企业版,其维护周期将持续到 2026 年 Q2。这意味着采用该版本的中大型系统可以获得持续稳定的运行保障。
对于不同现状的项目,建议采取差异化升级策略:
Spring 迁移项目:直接采用最新 LTS 版本,利用兼容层平稳过渡。我们团队的经验是先用 solon.boot.spring 模块实现共存,再逐步替换核心组件。
已有 Solon 项目:非关键业务可升级到社区版 v..,核心系统建议等待 v.. 的 .1 修订版(通常解决早期问题后再部署更稳妥)。
新建项目:技术预览类项目可尝试 v..-M 的新特性,但要注意 API 可能变更。最近在物联网网关项目中,我们就利用里程碑版的 RSocket 支持实现了设备双向通信。
在高并发场景下,建议调整以下默认参数:
yaml复制solon:
executor:
corePoolSize: ${runtime.availableProcessors} # 根据CPU核心数动态设置
maxPoolSize: 200
queueCapacity: 1024
server:
maxHttpPostSize: 10MB # 文件上传场景需要调整
通过 JMeter 压力测试,这套配置在 8C16G 服务器上可稳定支撑 6000+ QPS。注意线程池队列过大可能导致 OOM,需要配合监控指标动态调整。
Docker 镜像构建时容易遇到的坑:
eclipse-temurin:17-jre-jammy,比 openjdk 镜像小 30%solon.app.group 一致,否则热加载会失效/run/check 端点(Solon 特有健康检查)这是我们使用的典型 Dockerfile:
dockerfile复制FROM eclipse-temurin:17-jre-jammy as builder
COPY target/app.jar /app/
RUN java -jar /app/app.jar --solon.app.group=builder --export
FROM eclipse-temurin:17-jre-jammy
COPY --from=builder /app/export /app/
ENTRYPOINT ["java","-jar","/app/app.jar"]
当出现 NoSuchMethodError 或 ClassCastException 时,通常是因为依赖冲突。Solon 提供诊断工具:
bash复制java -jar yourApp.jar --solon.debug.classloader=dump
这会在 logs 目录生成类加载树形图,清晰展示冲突源头。最近处理过的一个案例是 Jackson 2.12 和 2.14 混用导致序列化异常。
如果应用启动时卡在 banner 显示阶段,大概率是插件初始化阻塞。通过添加参数可获取详细启动日志:
bash复制java -jar app.jar --solon.debug.startup=1
曾遇到某安全插件因连接 Vault 超时而阻塞整个启动流程,最终通过设置 @Order(-100) 调整加载顺序解决。
Solon 内置的 /run/metrics 端点提供内存详情,结合以下 JVM 参数更易发现问题:
bash复制-XX:+HeapDumpOnOutOfMemoryError
-XX:HeapDumpPath=/tmp/heapdump.hprof
某次线上事故分析发现是缓存插件未正确实现 WeakReference,导致用户会话数据无法回收。现在框架已内置防御性检测,启动时会扫描常见内存泄漏模式。