Solon v4.0.3 发布：继续押注轻量级 Java 企业开发

预计阅读时间：8 分钟

Solon v4.0.3 发布了。这个版本本身的公开摘要没有展开具体变更项，但它再次把 OpenSolon 的定位摆到台前：一个从零构建、不依赖 Java EE 的 Java 企业级应用开发框架，强调快速、小巧、接口灵活和开放生态。对于正在评估 Spring 生态替代方案，或者希望把服务做得更轻的团队，Solon 值得进入技术选型清单。

它不是“再造一个 Spring Boot”那么简单

OpenSolon，也常被直接称为 Solon，公开定位是 Java 企业级应用开发框架，并且明确强调 No Java-EE。这一点很关键：它不是在传统 Java EE 规范上继续堆抽象，而是从框架内核、接口规范到生态插件重新组织。

这类设计通常会影响几个工程层面的选择：

启动路径更短，框架包袱更轻。
接口规范由框架自身控制，扩展点更灵活。
生态插件可以围绕 Solon 的模型组织，而不是被旧规范牵着走。
团队迁移时需要重新确认注解、配置、过滤器、依赖注入、事务等行为边界。

摘要里还提到 Solon 使用 Apache 2.0 协议，这对企业采用比较友好。Apache 2.0 的价值不在“开源”两个字本身，而在于它给商业分发、二次开发和内部平台化留下了更清晰的法律空间。

“可替换 Spring 生态”应该怎么理解

来源摘要说 Solon 是 Java 应用开发的生态基座，可替换 Spring 生态。这个判断不能简单理解成“所有 Spring 项目直接无痛切过去”。更现实的读法是：Solon 试图提供一套覆盖 Web、配置、依赖注入、插件扩展等企业应用基础能力的框架底座。

对工程团队来说，替换框架不是替换一个 Maven 坐标，而是替换这些东西：

应用启动模型。
控制器和路由声明方式。
Bean 管理与依赖注入习惯。
配置文件结构和环境变量接入方式。
中间件集成，例如数据库、缓存、消息、网关、监控。
测试方式、打包方式和运行时诊断方式。

所以更稳妥的路线不是把一个大系统整体迁移，而是选一个边界清楚的小服务做验证：例如内部管理 API、轻量任务服务、边缘网关插件，或者一个新业务的 MVP 服务。

可以这样实践：用 v4.0.3 起一个最小 HTTP 服务

下面是一个可改造的最小示例，用来验证 Solon 的启动方式、路由注解和本地运行流程。运行前请确认本机已安装 JDK 17 或团队要求的 JDK 版本，并能访问 Maven 仓库。

pom.xml：

<project xmlns="http://maven.apache.org/POM/4.0.0"
         xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
         xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 https://maven.apache.org/xsd/maven-4.0.0.xsd">
    <modelVersion>4.0.0</modelVersion>

    <groupId>demo</groupId>
    <artifactId>solon-v403-demo</artifactId>
    <version>1.0.0</version>

    <properties>
        <maven.compiler.source>17</maven.compiler.source>
        <maven.compiler.target>17</maven.compiler.target>
        <project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
    </properties>

    <dependencies>
        <dependency>
            <groupId>org.noear</groupId>
            <artifactId>solon-web</artifactId>
            <version>4.0.3</version>
        </dependency>
    </dependencies>
</project>

src/main/java/demo/App.java：

package demo;

import org.noear.solon.Solon;
import org.noear.solon.annotation.Controller;
import org.noear.solon.annotation.Mapping;

@Controller
public class App {
    public static void main(String[] args) {
        Solon.start(App.class, args);
    }

    @Mapping("/ping")
    public String ping() {
        return "pong from Solon 4.0.3";
    }
}

运行命令：

mvn -q package
mvn -q exec:java -Dexec.mainClass=demo.App

如果你的项目没有配置 exec-maven-plugin，可以改用 IDE 直接运行 demo.App 的 main 方法。服务启动后，用下面的命令验证接口：

curl http://localhost:8080/ping

预期返回：

pong from Solon 4.0.3

这个例子不能代表完整企业项目的复杂度，但它适合做第一轮技术验证：依赖是否能拉取、启动是否符合预期、路由声明是否清晰、应用包大小和启动时间是否满足你的场景。

评估 v4.0.3 时，别只看“能不能跑”

框架选型最怕只跑一个 Hello World 就下结论。Solon 的优势叙事集中在快速、小巧、开放生态和不依赖 Java EE；这些点要落到你的系统里，需要用真实约束去压测。

建议用这份清单做一次小范围验证：

启动性能：记录冷启动时间、内存占用、容器镜像体积。
开发体验：控制器、配置、注入、异常处理是否容易形成团队规范。
生态覆盖：数据库、缓存、鉴权、日志、监控、OpenAPI 等插件是否满足现有栈。
迁移成本：Spring 项目里的注解、配置、AOP、事务、测试工具要如何替换。
运维边界：健康检查、优雅停机、配置热更新、链路追踪是否能接入现有平台。
升级节奏：v4.0.3 是一个更新版本，团队应跟踪后续变更说明和兼容性策略。

如果你正在做新服务，Solon 可以作为轻量级 Java 框架候选项尽早试用；如果你维护的是大型 Spring 存量系统，更建议从非核心服务、内部工具或新模块开始。框架替换不是信仰选择，而是一次关于成本、生态、性能和团队熟悉度的工程交易。

Solon v4.0.3 发布：继续押注轻量级 Java 企业开发

它不是“再造一个 Spring Boot”那么简单

“可替换 Spring 生态”应该怎么理解

可以这样实践：用 v4.0.3 起一个最小 HTTP 服务

评估 v4.0.3 时，别只看“能不能跑”

相关推荐

建议反馈