9.1 与 Spring Boot 及主流框架的整合

9.1 与 Spring Boot 及主流框架的整合

本节摘要：把 Netty 服务做成 Spring Bean，随容器生命周期启停，业务 Handler 交由容器注入；反过来，理解 Dubbo、gRPC、WebFlux 等框架把 Netty 藏在哪一层，遇到底层问题时能直接下钻。本节给两边的完整代码与装配关系图。

一、核心矛盾：两套生命周期要合流

Spring Boot 有自己的启动与关闭序列，Netty 的 sync() 会阻塞主线程——直接在 main 里启动 Netty，Spring 起不来；直接交给 Spring 托管而不处理关闭，发布时连接被腰斩。解法是把 Netty 服务封装成 Bean，启动放独立线程，关闭挂容器生命周期钩子。

@Component
public class NettyServer implements SmartLifecycle {
    private EventLoopGroup boss, workers;
    private Channel serverChannel;
    private volatile boolean running;
    private final BizHandlerFactory handlerFactory;   // 注入 Spring 管理的业务工位

    public NettyServer(BizHandlerFactory handlerFactory) {
        this.handlerFactory = handlerFactory;          // 构造注入，Handler 可用 @Service
    }

    @Override
    public void start() {
        boss = new NioEventLoopGroup(1);
        workers = new NioEventLoopGroup();
        ServerBootstrap b = new ServerBootstrap();
        b.group(boss, workers)
         .channel(NioServerSocketChannel.class)
         .childOption(ChannelOption.TCP_NODELAY, true)
         .childHandler(new ChannelInitializer<SocketChannel>() {
             @Override
             protected void initChannel(SocketChannel ch) {
                 ch.pipeline().addLast(
                     new LengthFieldBasedFrameDecoder(1024 * 1024, 0, 4, 0, 4),
                     handlerFactory.codec(),
                     handlerFactory.biz());             // Spring 工位进场
             }
         });
        // bind 放进新线程执行，不阻塞 Spring 主线程
        b.bind(8080).addListener(f -> {
            if (f.isSuccess()) running = true;
        });
    }

    @Override
    public void stop() {                                 // 挂进容器优雅停机序列
        if (serverChannel != null) serverChannel.close();
        boss.shutdownGracefully();
        workers.shutdownGracefully();                    // 第八章的停机四步在此兑现
        running = false;
    }

    @Override public boolean isRunning() { return running; }
}
​

SmartLifecycle 让 Netty 的启停纳入容器序列：Spring Boot 收到 SIGTERM 时先调 stop，走完 8.3 的优雅停机再退出。业务 Handler 通过工厂注入，Handler 内部还能继续注入 Service 与配置——两套体系真正合流。

三个工程细节：配置项（端口、worker 数）用 @ConfigurationProperties 外置；initChannel 里组装的 Handler 若带状态，每连接各 new（6.2 纪律），无状态的从容器拿单例；启动失败要回调给 Spring（抛异常或广播事件），别静默吞掉。

双体系合流后的装配关系

二、借力框架：先认出它的 Netty

在用这些框架时，前八章的知识直接换算成排障能力：

• Dubbo 调优就是调它的 Netty 参数（worker 数、缓冲区在 Dubbo 配置里对应透传）；"Dubbo 超时"排查先看是不是 EventLoop 被业务阻塞（6.1 的队列指标在 Dubbo 里同样适用）。
• gRPC-Java 的拦截器运行在 Netty 线程上，里面做慢 IO 会拖垮整个 Channel——与 6.2 的慢业务剥离完全同构。
• WebFlux 报 "block on reactor thread" 本质就是 Netty EventLoop 线程被检测到阻塞调用，理解了 6.1 就明白它为什么设计成 Error 而不是警告。

反过来，框架源码是绝佳的 Netty 进阶教材：想看生产级 Pipeline 装配，读 Dubbo 的 NettyServer；想看 HTTP 解析器的工业化实现，读 netty-codec-http 的 HttpObjectDecoder。

三、选型判断：何时自建、何时用框架

自建的代价要诚实计入：第八章的应急设施、第七章的监控、9.2 的实战装配，都得自己写。框架的代价则是黑盒——出了底层问题，没有本教程前八章的底子就无从下手。

⚠️ 常见坑：在 Netty 的 Handler 里直接注入带事务的 Service 并同步调用——事务上下文与线程绑定，而 Handler 跑在 EventLoop 线程上，事务传播行为诡异且难复现。跨体系调用一律走 6.2 的业务线程池剥离模式。

💡 关键直觉：整合的本质是"谁管生命周期、谁管线程"。Spring 管容器级启停，Netty 管 IO 级线程，业务 Handler 作为两边的接口层——边界清晰了，合流就只是胶水代码。

整合要点速记

• SmartLifecycle 合流：Netty 启停纳入容器序列，bind 进独立线程。
• 注入边界：无状态 Handler 可为容器单例，有状态每连接新建。
• 框架即封装：Dubbo/gRPC/WebFlux 的底层排障，直接换算成前八章知识。
• 选型表：标准协议用框架，自定义协议与海量长连接自建，单测用 EmbeddedChannel。
• 事务与线程：跨体系调用走业务线程池，别让 EventLoop 背事务上下文。