网关这个词做后端的人几乎天天挂在嘴边但真要自己从零写一个很多人第一反应是“这玩意儿不是Nginx或者Spring Cloud Gateway干的事吗”。我当初也是这么想的直到有一次项目里需要做一套完全定制化的流量治理逻辑——既要在入口层做细粒度的鉴权又要按业务维度做动态路由还要把请求日志按自定义格式落到消息队列里——现成的开源网关要么太重要么扩展点不够灵活改起来比自己写还费劲。于是我就花了大概两周时间从最裸的Socket开始一步步搭了一个能跑在产线的小网关。这篇文章就是那次折腾的完整复盘。我会把网关的核心骨架拆开讲清楚每个模块为什么这么设计、代码怎么写、踩过哪些坑。不管你是刚接触后端架构的新手还是想深入理解网关内部机制的老手应该都能从里面找到有用的东西。全文会涉及网络编程、协议解析、路由匹配、负载均衡、限流熔断、可观测性等核心话题代码以Java为主但思路是跨语言的。1. 先想清楚网关到底在解决什么问题1.1 网关的本质是一个“中间人”很多人把网关想得很神秘其实它的本质特别朴素客户端不直接访问后端服务而是先访问网关网关再转发给后端。就这么简单。它站在客户端和服务端之间所有进出的流量都从它身上过所以它有机会在转发前后做各种事情。你可以把网关想象成一栋写字楼的前台。访客客户端来了不会直接冲到某个公司后端服务的工位上而是先到前台网关。前台会核对你的身份鉴权、问你找谁路由、看看今天这家公司是否正常营业健康检查、如果访客太多还会让你排队限流最后引导你到正确的楼层转发。前台本身不处理业务但没有它整栋楼就乱套了。理解了这一点你就明白网关的核心职责就两件事转发和治理。转发是基础治理是价值。1.2 为什么不用现成的要自己写这个问题我被问过很多次。说实话90%的场景用Nginx加几个Lua脚本或者用Spring Cloud Gateway配一配就够了。但以下几种情况自己写会更合适定制化逻辑极重比如你的路由规则要根据请求体里的某个字段动态计算而不是简单的路径匹配现成网关的扩展点写起来很别扭。需要深度嵌入现有系统比如你的鉴权体系是自研的服务发现用的是内部协议硬套开源网关反而要写大量适配层。性能要求极端某些场景下通用网关的抽象层次太多你想砍掉一切不必要的开销直接操控网络层。学习目的想真正搞懂网关内部怎么运转的写一遍是最快的方式。我自己那次属于第一种和第四种的混合。下面讲的方案是一个基于Netty的异步非阻塞网关核心思路是接收请求、解析协议、匹配路由、执行过滤器链、转发到后端、回写响应。1.3 整体架构长什么样在动手写代码之前先把架构想清楚。我设计的网关分为这么几层接入层负责监听端口、接收连接、编解码HTTP协议。用Netty的ServerBootstrap搞定。路由层根据请求的路径、方法、Header等信息匹配到对应的后端服务。路由规则支持动态更新。过滤器链在转发前后执行一系列处理逻辑比如鉴权、日志、限流、改写请求头。这是网关最核心的扩展点。转发层把请求转发给后端服务支持负载均衡和健康检查。响应处理层接收后端响应经过过滤器链回写最后返回给客户端。这五层里过滤器链是灵魂。所有治理逻辑都挂在这条链上增删功能只需要加减过滤器不用动核心流程。这个设计借鉴了Servlet Filter和Spring Interceptor的思路但更轻量。2. 核心模块拆解与关键设计决策2.1 为什么选Netty而不是原生NIOJava原生NIO写起来有多痛苦写过的都知道。Selector、Channel、Buffer三件套加上各种半包粘包处理一个不小心就是bug。Netty把这些都封装好了提供了事件驱动的编程模型ChannelHandler链式处理逻辑清晰。内置编解码器HTTP、WebSocket、SSL等开箱即用。零拷贝ByteBuf的设计比原生ByteBuffer高效得多。成熟的线程模型bossGroup负责acceptworkerGroup负责IO读写分工明确。我实测下来Netty处理HTTP请求的吞吐量比手写NIO高出30%以上而且代码量少了一半。所以接入层直接用Netty不犹豫。2.2 过滤器链的设计责任链模式的实战过滤器链我用的是责任链模式。每个过滤器实现同一个接口链式调用。核心接口大概长这样public interface GatewayFilter { String name(); int order(); MonoVoid filter(GatewayContext context, GatewayFilterChain chain); }GatewayContext封装了请求和响应的所有信息GatewayFilterChain负责调用下一个过滤器。每个过滤器可以决定继续往下走chain.next(context)直接返回响应不调用next自己写回结果修改上下文在调用next前后改context里的数据这里有个关键设计过滤器的order值决定执行顺序。鉴权过滤器order设成10日志设成20限流设成30转发设成100。数字小的先执行。这样调整顺序只需要改数字不用动代码。注意过滤器链里如果某个过滤器抛异常要有统一的异常处理机制否则整个请求就挂了。我是在链的末尾加了一个ExceptionHandlerFilter兜底所有异常。2.3 路由匹配从简单前缀到复杂表达式路由匹配看起来简单其实门道不少。我一开始只支持路径前缀匹配比如/api/user/**转发到用户服务。但很快就不够用了因为需要按HTTP方法匹配GET和POST走不同后端按Header匹配带特定Header的请求走灰度环境按查询参数匹配?versionv2走新版本最后我设计了一个路由规则模型public class RouteRule { private String id; private String pathPattern; // 路径模式支持通配符 private SetString methods; // HTTP方法 private MapString, String headers; // Header匹配条件 private String targetService; // 目标服务名 private int order; // 匹配优先级 }匹配的时候按order从小到大遍历第一个匹配上的就用。路径匹配我用的是Ant风格通配符**匹配任意多级路径*匹配单级路径。这个规则简单直观够用。2.4 负载均衡轮询、随机还是加权转发到后端服务时一个服务通常有多个实例需要选一个。我实现了三种策略轮询按顺序依次选适合实例性能差不多的场景。随机随机选一个实现简单但可能短时间打到同一个实例。加权轮询根据实例权重分配流量适合机器配置不一样的场景。默认用轮询。选实例的时候会跳过健康检查失败的实例。健康检查我用的是被动检查如果某个实例连续N次请求失败就标记为不健康隔一段时间再试探性放一个请求过去成功了就恢复。实操心得健康检查的阈值不要设得太激进。我一开始设成连续2次失败就摘除结果网络抖动一下就把正常实例摘了导致流量全打到剩下的实例上差点雪崩。后来改成连续5次失败才摘除稳定多了。3. 动手实现从Socket到完整网关3.1 环境准备与依赖我用的是Java 17加Netty 4.1Maven管理依赖。核心依赖就这几个dependency groupIdio.netty/groupId artifactIdnetty-all/artifactId version4.1.100.Final/version /dependency dependency groupIdcom.fasterxml.jackson.core/groupId artifactIdjackson-databind/artifactId version2.15.2/version /dependencyNetty的netty-all包含了所有模块省得一个个引。Jackson用来处理JSON配置和响应。3.2 接入层Netty服务端启动服务端启动的代码很标准但有几个参数需要根据实际情况调public class GatewayServer { private final int port; public void start() throws InterruptedException { EventLoopGroup bossGroup new NioEventLoopGroup(1); EventLoopGroup workerGroup new NioEventLoopGroup(); try { ServerBootstrap b new ServerBootstrap(); b.group(bossGroup, workerGroup) .channel(NioServerSocketChannel.class) .option(ChannelOption.SO_BACKLOG, 1024) .childOption(ChannelOption.SO_KEEPALIVE, true) .childOption(ChannelOption.TCP_NODELAY, true) .childHandler(new GatewayChannelInitializer()); ChannelFuture f b.bind(port).sync(); f.channel().closeFuture().sync(); } finally { bossGroup.shutdownGracefully(); workerGroup.shutdownGracefully(); } } }几个关键参数说明SO_BACKLOG1024等待accept的连接队列长度。高并发场景可以调大。TCP_NODELAYtrue禁用Nagle算法减少小包延迟。网关场景必须开。SO_KEEPALIVEtrue保持长连接减少握手开销。GatewayChannelInitializer里配置ChannelHandler链public class GatewayChannelInitializer extends ChannelInitializerSocketChannel { Override protected void initChannel(SocketChannel ch) { ChannelPipeline p ch.pipeline(); p.addLast(new HttpServerCodec()); p.addLast(new HttpObjectAggregator(10 * 1024 * 1024)); p.addLast(new GatewayHandler()); } }HttpServerCodec负责HTTP编解码HttpObjectAggregator把多个HTTP片段聚合成完整的FullHttpRequest最大10MB。超过这个大小的请求会被拒绝防止大请求打爆内存。3.3 核心处理器请求进来之后发生了什么GatewayHandler是整个网关的入口继承SimpleChannelInboundHandlerFullHttpRequest。核心逻辑Override protected void channelRead0(ChannelHandlerContext ctx, FullHttpRequest request) { // 1. 构建上下文 GatewayContext context new GatewayContext(request, ctx); // 2. 执行过滤器链 GatewayFilterChain chain new DefaultGatewayFilterChain(filters); chain.next(context).subscribe( unused - {}, error - handleError(ctx, error) ); }这里用了响应式编程Mono/Flux因为转发是异步的用回调容易写成回调地狱。响应式能把异步逻辑串起来代码更清晰。GatewayContext里存了请求、响应、路由信息、属性Map。属性Map用来在过滤器之间传递数据比如鉴权过滤器把用户信息放进去日志过滤器取出来记录。3.4 过滤器实现鉴权、日志、限流鉴权过滤器public class AuthFilter implements GatewayFilter { Override public int order() { return 10; } Override public MonoVoid filter(GatewayContext context, GatewayFilterChain chain) { String token context.getRequest().headers().get(Authorization); if (token null || !validateToken(token)) { context.writeResponse(HttpResponseStatus.UNAUTHORIZED, unauthorized); return Mono.empty(); } context.setAttribute(userId, extractUserId(token)); return chain.next(context); } }鉴权失败直接写回401不往下走。成功就把userId塞进上下文后面的过滤器能用。日志过滤器public class LogFilter implements GatewayFilter { Override public int order() { return 20; } Override public MonoVoid filter(GatewayContext context, GatewayFilterChain chain) { long start System.currentTimeMillis(); return chain.next(context).doFinally(signal - { long cost System.currentTimeMillis() - start; log.info(path{}, method{}, cost{}ms, status{}, context.getRequest().uri(), context.getRequest().method(), cost, context.getResponse().status()); }); } }日志过滤器在doFinally里记录耗时不管成功失败都能记上。这个位置很关键放在chain.next之后才能拿到完整耗时。限流过滤器限流我用的是令牌桶算法。每个路由维护一个令牌桶请求来了先拿令牌拿不到就返回429。public class RateLimitFilter implements GatewayFilter { private final MapString, TokenBucket buckets new ConcurrentHashMap(); Override public int order() { return 30; } Override public MonoVoid filter(GatewayContext context, GatewayFilterChain chain) { String routeId context.getRoute().getId(); TokenBucket bucket buckets.computeIfAbsent(routeId, k - new TokenBucket(1000, 100)); // 容量1000每秒补充100 if (!bucket.tryAcquire()) { context.writeResponse(HttpResponseStatus.TOO_MANY_REQUESTS, rate limited); return Mono.empty(); } return chain.next(context); } }令牌桶的参数要根据实际QPS调。容量是突发流量的上限补充速率是稳态QPS。我一般把容量设成稳态QPS的5到10倍能扛住短时突发。3.5 转发层把请求发给后端转发是网关最核心的动作。我用Netty的HttpClientNetty也提供了客户端来发请求public class ForwardFilter implements GatewayFilter { private final HttpClient httpClient; Override public int order() { return 100; } Override public MonoVoid filter(GatewayContext context, GatewayFilterChain chain) { RouteRule route context.getRoute(); String targetUrl loadBalancer.choose(route.getTargetService()); FullHttpRequest request context.getRequest(); // 改写请求路径 String newUri rewritePath(request.uri(), route); return httpClient.send(request, targetUrl, newUri) .flatMap(response - { context.setResponse(response); return chain.next(context); }); } }转发时有几个细节要注意路径改写比如/api/user/123转发到用户服务时要去掉/api前缀变成/user/123。Header透传客户端的Header大部分要透传但Host、Content-Length这些要改写。超时控制转发请求必须设超时否则后端卡住会把网关拖死。我设的是连接超时1秒读超时5秒。踩过的坑一开始没设超时后端某个接口因为数据库慢查询卡了30秒结果网关的线程全被占满整个网关不可用。后来加了超时并且用Netty的ReadTimeoutHandler做兜底再没出过这个问题。3.6 响应回写别忘了释放资源后端响应回来后要经过过滤器链反向处理最后写回客户端。这里有个容易忽略的点Netty的ByteBuf必须释放否则会内存泄漏。public void writeResponse(ChannelHandlerContext ctx, FullHttpResponse response) { try { ctx.writeAndFlush(response).addListener(ChannelFutureListener.CLOSE); } finally { ReferenceCountUtil.release(response); } }ReferenceCountUtil.release确保ByteBuf被回收。如果忘了这一步跑一段时间就会OOM。4. 生产环境必须考虑的那些事4.1 动态配置路由规则不能写死在代码里路由规则写死在代码里每次改都要重启这在生产环境不可接受。我的做法是路由规则存在配置中心比如Nacos、Apollo或者自己搞个简单的配置表。网关启动时拉取全量规则同时监听变更。规则变更时原子替换内存里的路由表不影响正在处理的请求。public class RouteManager { private volatile ListRouteRule routes new ArrayList(); public void updateRoutes(ListRouteRule newRoutes) { // 排序后原子替换 newRoutes.sort(Comparator.comparingInt(RouteRule::getOrder)); this.routes newRoutes; } public RouteRule match(String path, String method) { for (RouteRule route : routes) { if (route.matches(path, method)) { return route; } } return null; } }用volatile保证可见性替换时直接赋新列表读的时候不用加锁。这个模式在高并发下很稳。4.2 可观测性日志、指标、链路追踪网关是所有流量的入口可观测性做不好出了问题就是抓瞎。我做了三件事结构化日志每条请求日志都是JSON格式包含traceId、path、method、status、cost、clientIp等字段。方便用ELK或者类似系统检索。核心指标用Micrometer暴露指标包括QPS、P99延迟、错误率、限流次数、后端健康实例数。这些指标接到监控面板上一眼就能看出问题。链路追踪在入口生成traceId透传到后端服务。后端服务的日志里带上traceId排查问题时能串起来。public class TraceFilter implements GatewayFilter { Override public int order() { return 5; } Override public MonoVoid filter(GatewayContext context, GatewayFilterChain chain) { String traceId context.getRequest().headers().get(X-Trace-Id); if (traceId null) { traceId UUID.randomUUID().toString().replace(-, ); } context.setAttribute(traceId, traceId); context.getRequest().headers().set(X-Trace-Id, traceId); MDC.put(traceId, traceId); try { return chain.next(context); } finally { MDC.remove(traceId); } } }traceId放在MDC里日志框架会自动带上不用手动拼。4.3 高可用网关自己挂了怎么办网关是单点它挂了整个系统就不可用了。所以网关本身必须高可用多实例部署至少两个实例前面挂负载均衡。无状态设计网关不存业务数据所有状态放Redis或者配置中心实例可以随时扩缩容。优雅停机收到停机信号后先停止接收新请求等正在处理的请求完成再退出。Runtime.getRuntime().addShutdownHook(new Thread(() - { // 停止接收新连接 serverChannel.close(); // 等待正在处理的请求完成 workerGroup.shutdownGracefully(5, 10, TimeUnit.SECONDS); }));shutdownGracefully的第一个参数是静默期第二个是超时时间。静默期内不再接收新任务超时后强制关闭。4.4 性能调优几个关键参数网关的性能调优核心是减少不必要的开销。我总结了几条调优项默认值建议值说明worker线程数CPU核数*2CPU核数网关是IO密集型线程太多反而增加切换开销SO_BACKLOG1281024高并发下需要更大的accept队列TCP_NODELAYfalsetrue禁用Nagle算法降低延迟聚合缓冲区大小1MB10MB根据业务请求体大小调整连接池大小无每后端实例50避免频繁建连实操心得worker线程数不是越多越好。我试过设成CPU核数的4倍结果QPS反而下降了因为线程切换开销太大。后来设成CPU核数P99延迟降了20%。5. 常见问题与排查实录5.1 请求超时了怎么定位是哪一段慢网关的请求链路长超时了要分段排查。我在每个关键节点都打了时间戳请求到达网关的时间过滤器链执行完的时间转发请求发出的时间后端响应回来的时间响应写回客户端的时间这样一对比就知道慢在哪一段。如果是过滤器链慢看是哪个过滤器如果是转发慢看是后端问题还是网络问题。5.2 内存泄漏怎么查Netty的内存泄漏最让人头疼。我的排查步骤启动时加-Dio.netty.leakDetection.levelparanoidNetty会检测未释放的ByteBuf并打印堆栈。用jmapdump堆内存用MAT分析看哪些对象占内存最多。重点检查FullHttpRequest和FullHttpResponse有没有释放。我遇到过一次泄漏原因是异常分支里忘了释放请求。后来在channelRead0里用try-finally包住确保任何情况下都释放。5.3 后端实例挂了流量还在往那打这是健康检查没做好。我的解决方案是主动加被动双重检查被动检查请求失败时记录失败次数超过阈值标记不健康。主动检查定时比如每5秒向后端实例发健康检查请求失败就摘除。两者结合既能快速发现故障又能及时恢复。5.4 常见问题速查表问题现象可能原因排查方向解决方案请求502后端不可达检查后端实例健康状态摘除不健康实例检查网络请求504后端超时查看后端处理耗时调大超时或优化后端内存持续增长ByteBuf未释放开启泄漏检测检查释放逻辑QPS上不去线程模型不合理查看线程数和CPU使用率调整worker线程数限流误伤阈值设太低查看限流日志调整令牌桶参数路由不生效规则未更新检查配置中心推送手动刷新或重启6. 后续可以怎么扩展这个网关跑起来之后我又陆续加了一些东西。如果你也想继续深挖这几个方向值得试试协议扩展目前只支持HTTP可以加WebSocket、gRPC的支持。Netty对这些协议都有现成的编解码器接进来不难。插件化把过滤器做成插件支持热加载。这样加新功能不用重启网关直接上传jar包就行。灰度发布基于Header或者用户ID做流量切分把一部分流量导到新版本服务验证没问题再全量。服务熔断当某个后端服务的错误率超过阈值时直接熔断不再转发请求给它时间恢复。这个可以用Resilience4j实现。配置热更新目前路由规则是手动刷新的可以接入配置中心实现秒级推送。写网关这件事最大的收获不是代码本身而是对网络编程和系统设计有了更深的理解。你会发现平时用的那些开源网关拆开来看也就是这些模块的组合只是它们做得更完善、更通用。自己写一遍再去看那些开源项目很多设计决策就能看懂了。最后分享一个小技巧调试网关的时候可以在本地起一个mock后端用curl发各种奇怪的请求去测比如超长URL、超大Body、畸形Header、并发连接。这些边界情况在正常测试里很难覆盖但生产环境一定会遇到。提前测过心里就有底。