什么是微服务网关？为什么需要服务网关？
- 标签：Spring Cloud、微服务、后端、网关
🏛 业务架构师
微服务网关是系统的统一流量入口，横在客户端与后端服务之间，做四类事：路由转发、协议适配、统一横切、流量治理。
为什么需要它——没有网关的业务痛点：
- 客户端直连服务不可持续：前端要配几十个服务地址、跨域问题各自处理、认证逻辑每服务实现一遍——重复建设 + 漏洞百出；
- 横切逻辑无收口：鉴权、限流、日志、灰度，每个服务自己写一遍，标准无法统一，一个服务漏了鉴权就是安全事故；
- 服务对客户端暴露细节：内部重构（服务合并、拆分、改路径）直接破坏客户端——没有缓冲层，内部演进代价外溢。
网关统一解决的：
- 统一接入：一个域名/入口，路由规则集中管理，内部变更对客户端透明；
- 统一安全：认证鉴权（JWT 校验、签名）、防重放、IP 黑白名单——安全策略一处实现全站生效；
- 统一治理：全局限流、熔断兜底、灰度路由（按用户/标签分流新旧版本）、API 聚合（BFF）；
- 统一观测：访问日志、traceId 注入、接口级监控。
架构师视角的边界提醒：网关要薄且稳——只做通用横切，业务逻辑（编排、事务）不要进网关（否则网关变单体核心，发布风险集中）；网关自身要高可用（多实例 + 无状态），它挂了全站就挂了，属于最高优先级的稳定性保障对象。
🏗 系统架构师
定义：微服务体系南北向流量的统一入口——所有外部请求经网关进入内部服务。
为什么必须：
- 收敛横切策略：认证、限流、熔断、黑白名单、审计——写一次全服务生效；没有网关这些散在各服务，策略漂移、漏洞百出；
- 协议与边界：对外 REST/HTTPS，对内任意协议；隐藏内部拓扑（服务名与实例不暴露）；
- 路由与版本：路径/域名/头路由，是灰度与版本切分的执行点；
- 安全边界：DDoS 清洗联动、WAF、请求校验、内头清洗（外部伪造的 X-User-Id 必须剥掉重写）——南北向安全策略执行点（PEP）；
- 可观测收口：入口级访问日志、traceId 起点、按 API 维度的 SLA 度量。
架构红线：
- 网关无业务逻辑（只做路由与策略）——有业务就变成全公司发布的瓶颈；
- 网关自身无状态集群化加前置 LB，它挂全站挂，可用性目标高于任何单个服务（按 99.99% 设计）；
- 东西向服务间调用不走网关（多一跳浪费）。
💻 全栈开发专家
网关是微服务的统一流量入口（南北向流量），所有外部请求先进网关再路由到内部服务。
为什么需要——把横切关注点从每个服务收敛到一处：
- 统一路由：外部 API 到内部服务的映射（
/api/order/**→ order-service），屏蔽内部拓扑变化 - 统一认证鉴权：JWT 验签一次做完，验签后注入用户身份 header 向下传递，内部服务免做
- 统一限流熔断：入口级流量治理（按 API/租户的令牌桶），把洪峰挡在最外层
- 安全防护：IP 黑白名单、WAF 规则、敏感 header 清洗、SSL 卸载
- 可观测与审计：全量访问日志、trace 起点注入 traceId、流量大盘
- 协议转换/聚合：对外 REST 对内 RPC、轻量 BFF 聚合、跨域统一处理
没有网关的反面（我接手遗留系统的真实痛点）：客户端记 N 个服务域名、每个服务各自暴露公网、鉴权逻辑复制 N 份、某服务改端口全端发版。
配套认知：东西向（服务间）流量治理靠 Feign/Sentinel/mesh，网关管的是边界；K8s Ingress 是网关的一种实现形态。