国产Java框架Solon v4.0.6：信创选型新选择

一、为什么信创场景需要一个"从零构建"的 Java 框架

信创（信息技术应用创新）的核心诉求是自主可控。但对大量 Java 团队来说，这里长期存在一个现实矛盾：

业务系统几乎都建在 Spring 生态之上——而这套生态由美国博通公司（Broadcom）主导。它在功能上无可挑剔，问题不在技术，而在于技术栈的根不在自己手里。

过去的选择题是"没得选"。现在多了一个答案：Solon。

二、Solon 是什么

Solon 是一个纯国产的 Java 企业级应用开发框架，定位为"新一代、克制、高效、开放"。它的几个关键特征：

• 从零开始构建（No Java-EE），不基于任何既有框架改造
• 拥有自主接口规范与开放生态，Apache 2.0 商用友好协议
• 由杭州无耳科技发起维护，当前版本 v4.0.6

"从零构建"这一点值得展开：它意味着不需要背负历史包袱去兼容庞大的既有规范，可以按照更直接的方式设计 API——这也是它在启动速度与内存占用上表现突出的根本原因。

三、官方基准数据

根据 Solon 官网公布的对比数据（与 Spring 生态对比）：

需要说明：以上为官方公布的基准测试结果。实际表现会随业务模型、JVM 参数、部署环境而变化，建议在选型时用自身业务的压测数据做最终判断，而不是直接采信任何一方的跑分。

四、技术特性

运行时兼容范围很宽

Solon 同时支持 Java 8 到 Java 26，并支持 native 运行（AOT 编译）。

这一点在信创场景里格外实用：现实中的政企项目，JDK 版本往往横跨多个代际——老系统还在 Java 8，新项目已经想用 Java 21 LTS。一个框架能同时覆盖，省掉了大量版本适配工作。

多语言支持

除 Java 外，官方示例同时提供 Kotlin 与 Groovy 版本，团队可以按既有技术栈选择。

两种编码模式

Solon 同时支持手写式路由与注解式声明，一个方法可以映射多种 HTTP method：

@Controller
public class App {
    public static void main(String[] args) {
        Solon.start(App.class, args, app -> {
            // 手写模式
            app.router().get("/hello1", ctx -> ctx.output("Hello world!"));
        });
    }

    // 注解模式（一个方法可支持多种 method）
    @Get
    @Socket
    @Mapping("/hello2")
    public String hello2(String name) {
        return String.format("Hello %s!", name);
    }
}

五、生态模块

框架本身只是一个入口，工程可用性取决于生态。Solon 目前覆盖的模块包括：

配套工具方面，官方提供项目生成器与流程设计器，降低上手门槛。

六、社区与采用情况

框架的成熟度最终要看有多少人在用、用得有多深。Solon 官网公布的社区数据：

在采用方一侧，官网登记的企业名单中包含了相当一批有分量的名字：

• 互联网：美团（北京三快在线）、快手（北京达佳互联）
• 制造业：珠海格力电器、海尔系相关企业
• 金融保险：中国人寿、华江证券
• 通信与电子：中国移动通信集团数智化部、中国电子科技集团、杭州海康威视
• 以及东华软件、浪潮创新（沈阳）等大量软件与集成商

名单中标注为国企/央企背景的比例不低，这与 Solon 主打的信创定位是吻合的。

七、选型建议

Solon 值得考虑的场景：

• 信创合规要求明确的项目——需要技术栈自主可控，且能通过国产化审查
• 资源受限的部署环境——内存省 50%、打包小 90% 在边缘设备、容器密度受限的场景下是实打实的收益
• 追求快速启动的场景——Serverless、函数计算、需要频繁扩缩容的服务
• 新项目从零起步——没有历史 Spring 代码包袱，迁移成本最低

需要谨慎评估的场景：

• 已有大型 Spring 存量系统——改造收益需要仔细核算，框架替换从来不是纯技术问题
• 重度依赖 Spring 特有生态——如 Spring Cloud 全套组件、Spring Batch 等，需逐项确认替代方案
• 团队完全没有 Solon 经验——请预留学习与踩坑成本，先从小服务试点

八、小结

国产化替代不是简单地"换个国产名字"，而是要真正拿得出可用、好用、有人用的东西。Solon 从 2019 年起步至今，走的是"从零构建 + 自主规范 + 开放生态"的路线。

它的价值不在于是否在每一项跑分上赢过 Spring，而在于为信创场景提供了一个真实可选的技术底座——这对一个长期由单一生态主导的领域来说，本身就是有意义的补充。

选型建议：无论最终用不用，都值得花半天时间跑一个真实业务的小服务做对照测试。跑分是别人的，压测数据才是自己的。