立项原因：
云服务做远程运维时，网络架构复杂，通常需要运维了解实际的网络架构才能进行具体的运维工作，付出了很多额外的成本。为了提高运维效率、降低运维成本，研发了这个基于netty框架的高并发、非对称、单边接入、双向通信的RPC通信工具。
行业场景：
传统 RPC 框架（如 Dubbo、HSF）通常要求服务端可被客户端直接访问。但在以下场景中，客户端位于内网或防火墙后，服务端无法主动连接：
内网穿透场景：1. 客户端在内网，服务端在公网；2. 客户端主动连接服务端，但服务端需要调用客户端能力
防火墙限制：1. 客户端无法开放端口供服务端访问 2. 只能由客户端发起出站连接
双向调用需求：1. 服务端需要主动调用客户端功能（如执行命令、获取状态）
项目解决的问题：
解决“客户端主动连接，但需要支持服务端调用客户端”的通信需求，实现：
1. 客户端主动建立连接（绕过防火墙）
2. 服务端可调用客户端接口（双向通信）
3. 异步转同步调用（简化使用）
4. 高并发处理能力
主要功能：
nettym 是一个基于 Netty 的轻量级双向通信框架，支持客户端主动连接、服务端反向调用，适用于内网穿透、远程运维和 IoT 场景。
整体上，nettym 提供完整的 RPC 能力：参数传递、请求路由、响应返回一应俱全。开发者只需注册接口，即可实现双向调用，无需关心底层通信细节。框架内部封装了连接管理、编解码、异步调度等复杂逻辑，兼顾高并发、可靠性与易用性，显著降低开发门槛。
核心功能模块：
1. 连接管理：客户端主动建连，服务端被动接收。支持断线后每 2 秒自动重连。通过 ChannelManager 管理活跃连接，支持按 IP 查询与控制。
2. 消息编解码：采用 FastJSON 序列化，支持请求、响应和默认三类消息。通过长度字段解决 TCP 粘包/拆包问题；编码器限制单条消息最大 1MB，解码器校验完整性，防止溢出。
3. 请求处理：支持动态注册服务接口，按 API 名称路由请求。使用 64 线程的线程池异步执行业务逻辑，并自动捕获异常，转为错误响应。
4. 响应管理：通过唯一消息 ID 匹配请求与响应，利用 ReqFuture 实现“异步转同步”——开发者可同步等待结果。支持超时机制，并定期清理过期 Future，避免内存泄漏。
5. 心跳保活：客户端每 5 秒发送心跳包，维持连接活跃；连接断开时自动释放相关资源。
6. 错误处理：统一捕获网络、序列化及业务异常，转换为标准错误响应；连接中断时自动清理未完成请求。
我负责的具体任务：
1. 架构设计与实现
2. 核心模块开发（连接管理模块、消息编解码模块、请求处理模块、响应管理模块、心跳保活模块）
3. 异步转同步机制
4. 资源管理
5. 异常处理
6. 并发安全
7. 测试与优化
技术栈：
核心框架：Netty
开发语言：Java 8
序列化：FastJSON
工具库：Lombok、SLF4J
构建工具：Maven
测试框架：JUnit
系统架构：
1. 网络传输层：基于 Netty NIO，使用 LengthFieldBasedFrameDecoder 解决粘包拆包
2. 编解码层：自定义 ByteBufEncoder/ByteBufDecoder，支持请求、响应、默认三种消息类型
3. 业务处理层：ReqHandleHandler 处理业务请求，使用 64 线程池异步执行
4. 调用管理层：ReqInvokeHandler 管理请求响应配对，实现异步转同步
5. 连接管理层：ChannelManager 管理连接生命周期，支持自动重连
亮点：
1. 支持双向 RPC 调用，服务端可反向调用客户端，适用于内网穿透。
2. 异步转同步调用（ReqFuture + 消息 ID），简化开发。
3. 自动重连（2秒间隔）、心跳保活、资源自动清理（30秒定时+断连触发）。
4. 高并发处理：线程池 + ConcurrentHashMap，支持64并发请求。
难点与解决方案：
1. 异步转同步：用 ReqFuture 阻塞等待响应，消息 ID 唯一匹配。
2. 消息 ID 冲突：AtomicInteger 生成，防溢出重置。
3. TCP 粘包拆包：LengthFieldBasedFrameDecoder + 数据完整性校验。
4. 资源泄漏：超时 Future 定期清理，连接断开时主动回收。
评论