Feat 2.2.0：把 Spring Boot 的手感做轻，把 Java Web 的吞吐做硬

预计阅读时间：8 分钟

Feat v2.2.0 的发布，把这个国产 Java Web 框架重新推到一个清晰的位置：它想保留 Spring Boot 式的开发体验，但在运行时绕开重反射、重容器和传统 Servlet 栈的包袱。根据发布信息，Feat 集成自研 smart-socket 引擎，支持 HTTP/2 和 WebSocket，通过编译期生成代码做到零反射，并强调启动快、内存小、吞吐量高；官方还给出了“比 Vert.x 快两倍”的性能定位。

它盯上的不是语法糖，而是运行时成本

很多 Java Web 框架都说自己“像 Spring Boot 一样好写”。真正难的是：写起来像，跑起来不要像一个越来越厚的运行时平台。

Feat 这次强调的几个点，基本都围绕运行时成本展开：

编译期生成代码、零反射：把路由、依赖绑定、元数据解析等工作前移到编译期，减少启动和请求路径上的动态扫描。
smart-socket 引擎：不把网络层完全交给传统嵌入式 Servlet 容器，而是走自研网络引擎路线。
HTTP/2 与 WebSocket：说明它不是只服务普通 REST API，也覆盖长连接和现代协议场景。
启动快、内存小、吞吐高：这些指标对容器化部署、Serverless、边缘服务和高密度微服务都很敏感。

这里要注意边界：发布摘要里没有给出完整 benchmark 环境、压测脚本和机器配置，所以“比 Vert.x 快两倍”更适合作为选型时值得验证的信号，而不是直接搬进架构文档的绝对结论。

Spring Boot 手感为什么仍然重要

Java 后端团队很少愿意为了性能完全换一种编程心智。Spring Boot 的强势不只是生态大，还在于它把“写一个接口、注入一个服务、配一个参数”变成了肌肉记忆。

Feat 如果真的能做到近似 Spring Boot 的开发体验，它降低的是迁移试验成本：团队可以先拿一个边界清晰的服务验证，而不是重写整套业务框架。适合试水的模块通常有这些特征：

接口数量不多，但 QPS 压力明显。
启动速度和内存占用影响部署密度。
依赖 Spring 生态不深，比如没有大量 Spring Security、Spring Cloud、复杂 AOP 或事务扩展。
需要 WebSocket 或 HTTP/2，但不想把完整网关能力塞进业务服务。

不适合第一批迁移的，是那些强绑定 Spring 生态的核心系统。性能不是唯一变量，监控、排障、团队熟练度、插件生态都会影响真实成本。

可以这样实践：先做一个可回滚的性能探针

下面示例不假设 Feat 的具体 API 包名。你可以把它当成一个最小验证项目的形状：同一个接口、同一台机器、同一套压测命令，分别跑 Spring Boot、Vert.x 和 Feat，再看启动时间、RSS 内存、P95 延迟和吞吐。

1. 定义统一的 HTTP 行为

接口尽量简单，避免数据库、Redis、日志刷盘这些外部因素干扰第一轮测试。

GET /ping

HTTP/1.1 200 OK
Content-Type: application/json

{"ok":true,"framework":"feat"}

2. Feat 侧可以按这个形状改造

以下是假设性伪代码，用于说明验证项目结构。请按 Feat v2.2.0 实际依赖、注解和启动类名称替换。

package demo;

// 假设 Feat 提供类似注解，请替换为实际包名
@HttpController
public class PingController {
    @GetMapping("/ping")
    public PingResponse ping() {
        return new PingResponse(true, "feat");
    }

    public record PingResponse(boolean ok, String framework) {}
}

如果你的服务会用 WebSocket，也可以把验证目标拆成两个：短连接 API 看吞吐和延迟，长连接看连接数、心跳、断线重连和内存曲线。不要把两类负载混在一次压测里。

3. 用同一套命令压测

把 http://127.0.0.1:8080/ping 换成你的 Feat 服务地址。wrk 适合快速观察吞吐和延迟分布；正式结论还需要更长时间、更贴近生产的负载模型。

# macOS: brew install wrk
# Ubuntu/Debian: sudo apt-get install wrk

wrk -t4 -c200 -d60s --latency http://127.0.0.1:8080/ping

记录启动时间和内存也要用同一口径：

# 启动服务后替换为实际 Java 进程 PID
PID=$(pgrep -f 'feat-demo' | head -n 1)

ps -o pid,rss,etime,command -p "$PID"
curl -s http://127.0.0.1:8080/ping

如果要做更公平的对比，至少固定这些条件：

JDK 版本一致。
JVM 参数一致，例如堆大小、GC、容器内存限制。
日志级别一致，压测期间不要输出每条请求日志。
响应体大小一致。
关闭无关中间件调用。
每轮压测前预热，再取稳定区间数据。

选型时看三张表，而不是只看一个倍数

Feat v2.2.0 值得关注，因为它把几个方向放在同一个框架里：Spring Boot 式开发体验、smart-socket 网络引擎、HTTP/2、WebSocket、编译期生成代码和零反射。这个组合对追求低资源占用和高吞吐的 Java 服务很有吸引力。

但落地前建议准备三张表：

性能表：QPS、P95/P99、启动时间、RSS 内存、CPU 使用率。
兼容表：现有认证、配置、日志、监控、链路追踪、JSON 序列化、异常处理能否接上。
运维表：打包方式、容器镜像、健康检查、优雅停机、线上排障工具是否成熟。

一个务实的采用路径是：先用 Feat 写一个无状态边缘 API 或内部高频小服务，压测和灰度都通过后，再考虑更复杂的业务模块。新框架最怕被一次性押上主干系统；让它先在小而硬的场景里证明自己，结果会更可信。