1. API网关概述：什么是API网关、为什么SaaS需要网关、网关的核心功能与价值

1.1 什么是API网关？

API网关，说白了就是一个「守门人」。

它站在客户端和后端服务之间，统一接管所有API请求。我习惯把它比作公司的前台——所有访客先到前台登记，前台再帮你联系具体部门。没有前台，访客就得自己满楼找人，乱不乱？

从技术角度看，API网关是一个反向代理服务器。它接收外部请求，做一系列处理（认证、限流、路由、协议转换等），再把请求转发给内部服务。

举个例子：

// 没有网关时，客户端直接调用多个服务
GET https://service-a.example.com/users
GET https://service-b.example.com/orders
GET https://service-c.example.com/payments

// 有网关后，客户端只调用一个入口
GET https://gateway.example.com/api/users
GET https://gateway.example.com/api/orders
GET https://gateway.example.com/api/payments

你看，客户端只需要知道网关地址，不用关心背后有多少服务。这就是统一入口的价值。

1.2 为什么SaaS需要网关？

这个问题我经常被问到。很多SaaS创业团队早期觉得：「就几个微服务，直接暴露出去不就行了？」

嗯，我刚开始做SaaS时也这么想。直到有一次，一个客户调用了我们内部的管理接口，差点把数据搞崩了。那次事故之后，我才真正理解网关的必要性。

SaaS系统有几个特点，决定了它离不开网关：

• 多租户隔离：不同客户的数据必须严格隔离。网关可以在入口层识别租户身份，把请求路由到对应的数据源。
• 统一认证：SaaS通常支持OAuth2、JWT、SSO等多种认证方式。网关统一处理，后端服务不用重复实现。
• 流量控制：大客户和小客户的流量差异巨大。网关可以按租户做限流，防止某个客户拖垮整个系统。
• 协议转换：老系统用SOAP，新系统用REST，移动端可能用gRPC。网关能把这些协议统一转换成内部服务需要的格式。
• 灰度发布：新功能先让10%的客户试用。网关可以根据请求头或用户ID，把流量路由到不同版本的服务。

1.3 网关的核心功能

网关的功能很多，但核心的就这几项。我按重要性排个序：

功能	说明	为什么重要
请求路由	根据URL、Header等条件，把请求转发到对应服务	这是网关最基础的功能，没有它就不叫网关
认证授权	验证用户身份，检查是否有权限访问资源	SaaS多租户场景下，认证是安全的第一道防线
限流熔断	控制请求速率，防止系统过载	我见过太多因为流量突增导致系统雪崩的案例
日志监控	记录所有请求的详细信息，用于排查问题	没有日志，出问题就像大海捞针
协议转换	把外部请求转换成内部服务需要的格式	微服务架构中，不同服务可能用不同协议
缓存	缓存高频请求的响应，减少后端压力	对SaaS来说，缓存能显著降低成本和延迟

你想想看，如果没有网关，这些功能每个服务都要自己实现一遍。维护成本高不说，还容易出漏洞。

1.4 网关的价值

网关的价值，我总结成三句话：

1. 让后端更专注：后端服务只需要关心业务逻辑，不用管认证、限流、日志这些「脏活累活」。
2. 让客户端更简单：客户端只需要跟一个地址打交道，不用知道背后有多少服务在协作。
3. 让系统更安全：所有流量都经过网关，安全策略可以集中管控，不容易遗漏。

另外，网关会增加一次网络跳转，带来微小的延迟。但相比它带来的好处，这点延迟完全可以接受。你想想看，为了安全、可维护性、可扩展性，多花几毫秒值不值？

1.5 什么时候该上网关？

很多团队会问：「我们才几个服务，需要网关吗？」

我的建议是：超过3个微服务，就应该考虑网关。

为什么是3个？因为当你有3个服务时，客户端就要维护3个地址，每个服务都要单独处理认证和限流。这时候网关的收益已经大于成本了。

当然，如果你只有一个单体应用，那确实不需要网关。但话说回来，做SaaS的，谁还没几个服务呢？

好，这一章就聊到这儿。下一章我们聊聊网关的架构模式，看看市面上主流的网关方案都有哪些，各自适合什么场景。