1、网关基础：微服务网关的定义、核心价值与演进历史
1.1 什么是微服务网关？
微服务网关，说白了就是系统的「总入口」。
我习惯把它比作公司的前台。所有外部请求进来，都得先经过前台。前台负责登记、分流、安全检查。网关干的也是这些活。
在微服务架构里，服务被拆得很细。用户服务、订单服务、支付服务……每个服务都有自己的地址。如果没有网关，客户端就得记住几十个地址。这显然不现实。
所以，网关就站在客户端和服务之间。它统一接收请求，再转发给后端服务。
核心定义：微服务网关是系统对外的唯一入口。它负责请求路由、负载均衡、认证鉴权、限流熔断等横切关注点。
1.2 网关的核心价值
你想想看，没有网关会怎样？
我在2017年接手过一个项目。当时团队图省事，让客户端直接调用各个微服务。结果呢？每次升级接口，都得逼着用户更新App。安全策略改一下，所有服务都得跟着改。那叫一个痛苦。
网关的价值，主要体现在这几个方面：
- 统一入口——客户端只认一个地址，后端怎么拆都无所谓
- 安全防护——认证、鉴权、防SQL注入、防XSS，都在网关层搞定
- 流量管控——限流、熔断、降级，保护后端不被冲垮
- 协议转换——外部用HTTP，内部用gRPC，网关帮你转
- 日志监控——所有请求的入口，天然适合做全链路追踪
我的经验：网关层一定要做「请求日志」的标准化。我曾经排查一个线上问题，就是因为网关日志格式不统一，花了整整两天才定位到问题源头。后来我强制要求：所有网关日志必须包含traceId、请求耗时、状态码、来源IP。这四样缺一不可。
1.3 网关的演进历史
网关不是一天长成这样的。我经历了它的三个时代。
第一阶段：单体网关（2010年前后）
那时候还是单体应用。一个Nginx反向代理就搞定了。配置简单，功能单一。说白了就是个「转发器」。
# 典型的Nginx单体网关配置
server {
listen 80;
location /api/ {
proxy_pass http://backend:8080/;
}
}这个阶段，网关只做两件事：路由转发和简单的负载均衡。
第二阶段：API网关（2014-2017年）
微服务火了以后，问题来了。服务多了，认证、限流、熔断这些需求就冒出来了。Nginx搞不定，或者搞起来很费劲。
于是出现了专门的API网关产品。比如Kong、Zuul、Spring Cloud Gateway。
我记得2016年选型时，我们对比过Zuul和Kong。Zuul跟Spring Cloud集成好，但性能一般。Kong基于OpenResty，性能强，但Java团队维护起来有点吃力。
| 特性 | Zuul 1.x | Kong | Spring Cloud Gateway |
|---|---|---|---|
| 语言 | Java | Lua/OpenResty | Java (Reactive) |
| 性能 | 一般（同步阻塞） | 高 | 高（异步非阻塞） |
| 扩展性 | Filter机制 | 插件机制 | Filter + 自定义 |
| 社区活跃度 | 已停止维护 | 活跃 | 活跃 |
避坑指南：我曾经在项目里用过Zuul 1.x。它的Filter是同步阻塞的。有一次流量突增，网关线程池被打满，整个系统都挂了。后来换成Spring Cloud Gateway，基于WebFlux的异步模型，同样的流量，CPU占用降了40%。所以，选网关一定要关注IO模型。
第三阶段：云原生网关（2018年至今）
现在大家都在谈云原生。Kubernetes成了标配。网关也跟着进化了。
云原生网关有几个特点：
- 声明式配置——用YAML定义路由规则，Git管理，自动生效
- 服务发现集成——自动感知后端服务的变化，不用手动改配置
- 可观测性——内置Metrics、Tracing、Logging
- 动态路由——运行时修改路由规则，不重启网关
典型的代表有：Istio Ingress Gateway、Kong for Kubernetes、APISIX。
我个人比较看好APISIX。它基于OpenResty，性能好，插件生态丰富。而且支持热加载，改配置不用重启。这在生产环境里太重要了。
1.4 网关选型的核心考量
选网关，我建议从这几个维度考虑：
- 团队技术栈——Java团队别硬上Go写的网关，出了问题没人能修
- 性能要求——QPS上万的话，避开同步阻塞模型
- 扩展性——会不会需要写自定义插件？插件开发成本高不高？
- 运维成本——配置管理、监控告警、灰度发布，这些配套成熟吗？
- 社区活跃度——遇到问题能搜到答案吗？有人持续维护吗？
我的建议：中小团队优先选Spring Cloud Gateway或Kong。大厂或者对性能要求极高的，可以看看APISIX或Envoy。别一上来就搞自研网关。我见过好几个团队，花半年自研网关，最后功能还没开源的好用。得不偿失。
1.5 小结
网关是微服务架构的「守门员」。它不负责业务逻辑，但负责所有横切关注点。
从单体Nginx到API网关，再到云原生网关，核心思路没变：把通用能力从业务服务中抽离出来，统一管理。
嗯，这一章先讲到这里。下一章我们深入聊聊网关的路由策略。我会结合具体案例，讲讲「路由规则怎么写才优雅」、「灰度发布怎么落地」。到时候见。
公众号：蓝海资料掘金营，微信 deep3321