微服务网关到底解决了什么

一、没有网关的时候，乱在哪

假设一个项目，你拆了几个微服务：用户、订单、支付。客户端（前端/App）要调它们，最朴素的写法就是——直接连。

左边那种就是灾难现场：

• 客户端得记住一堆地址。用户服务 user.xxx.com、订单 order.xxx.com……前端代码里散得到处都是，哪个服务换地址，前端跟着改。
• 鉴权每个服务各写一遍。用户服务写一套登录校验，订单服务又写一套，重复不说，哪天规则变了，挨个改到怀疑人生。
• 跨域、证书、限流全得各自搞。服务一多，运维想骂人。

二、网关干的事，其实就三件

网关往那一站，客户端只认它一个入口，后面的破事它兜住：

1）路由转发。 客户端只管调 api.xxx.com/order/xxx，网关按路径把请求转给后面的订单服务。服务怎么拆、地址怎么变，客户端完全不知道，爽。

2）鉴权收口。 登录校验放在网关统一做。后面的服务默认"能进来的都是网关验过的"，不用每个都写一遍。这点是真省心，也是安全上的一大进步——内部服务甚至可以只对内网开放，外网根本摸不到。

3）限流、灰度、日志这些横切的事。 比如"这个接口每秒最多 1000 次"，在网关配一下全生效；想灰度发布，网关按规则把部分流量导到新版本。这类"对所有服务都一样"的逻辑，放网关最合适。

三、别啥都往里放

新手容易走另一个极端：把网关当万能中间件，啥逻辑都往里写。大坑：

• 业务逻辑别放网关。网关应该是"薄薄一层转发+通用的横切"，订单怎么算优惠这种业务，必须留在订单服务。不然网关越胖越难维护，还成了单点瓶颈。
• 网关挂了全完蛋。所有流量都过它，它一挂全线瘫痪。所以网关本身的高可用（多实例、健康检查）得做足，别省。
• 小项目真不一定需要。你就两三个服务，客户端直连也挺好，硬上网关纯属增加复杂度。等服务的多了、跨团队了，再引入不迟。

四、前后端分离架构中要了解的

网关在前后端分离那套架构里，正好站在"前端 SPA"和"后端服务"中间那层。它和 JWT 也是搭档：客户端登录拿到 token，之后每个请求带 Authorization 头，网关统一验签名。

小结

我现在的判断特别简单：网关解决的是"多个服务对外的统一和收口"，不是"业务本身"。它让客户端省心、让运维少跑腿、让安全有抓手。但只要它开始沾业务逻辑，就需要多注意了。