2. 网关架构模式：集中式网关 vs 分布式网关、Sidecar模式、网关的部署拓扑
好，咱们接着聊网关架构。这一节我打算把几种主流的网关架构模式掰开揉碎了讲清楚。你想想看，选错了架构模式，后面整个SaaS系统的扩展性、稳定性都会受影响。我在好几个项目里都踩过坑，今天把这些经验分享给你。
2.1 集中式网关：最经典的模式
集中式网关，说白了就是所有流量都走一个统一的入口。这个入口负责路由、认证、限流、日志等等。我最早做SaaS系统时，用的就是这种模式。
核心特点：所有微服务对外暴露的API都通过一个网关节点转发。
举个例子，你的系统有用户服务、订单服务、支付服务。客户端请求先打到网关，网关根据路径前缀（比如 /user/**、/order/**）转发到对应的后端服务。
# 集中式网关的典型路由配置（以Kong为例）
services:
- name: user-service
url: http://user-svc:8080
routes:
- paths: [/user/*]
- name: order-service
url: http://order-svc:8081
routes:
- paths: [/order/*]
- name: payment-service
url: http://payment-svc:8082
routes:
- paths: [/payment/*]
优点很明显：
- 管理简单，就一个入口点
- 安全策略集中，好维护
- 跨横切关注点（认证、日志、限流）统一处理
缺点呢？
- 单点瓶颈，流量大了网关扛不住
- 单点故障，网关挂了整个系统就瘫了
- 扩展性受限，升级网关需要停机
我的经验：我曾经在一个日活百万的SaaS项目里用了集中式网关。刚开始还好，后来业务量翻了三倍，网关CPU直接飙到90%。嗯，那时候我才意识到，集中式网关不是万能的。
2.2 分布式网关：解决瓶颈的利器
集中式网关扛不住怎么办？分布式网关就派上用场了。它的思路是把网关拆成多个实例，每个实例处理一部分流量。
我个人习惯把分布式网关分为两种：
- 水平扩展型：多个网关实例前面加负载均衡器，流量分散到各个实例
- 功能拆分型：不同网关处理不同类型的流量（比如内部API网关、外部API网关、管理API网关）
# 分布式网关的部署拓扑示例
# 使用Nginx做负载均衡，后面挂多个Kong实例
upstream kong_cluster {
server 192.168.1.10:8000;
server 192.168.1.11:8000;
server 192.168.1.12:8000;
}
server {
listen 80;
location / {
proxy_pass http://kong_cluster;
}
}
分布式网关的好处：
- 水平扩展，加机器就能扛流量
- 高可用，一个实例挂了不影响整体
- 可以按业务域拆分，互不影响
注意：分布式网关不是简单的加机器。你还要考虑配置同步、会话一致性、日志聚合等问题。我曾经在一个项目里，因为配置没同步，导致两个网关实例的路由规则不一致，线上出了半小时的故障。从那以后，我每次做分布式网关都会强制要求配置中心。
2.3 Sidecar模式：服务网格的基石
说到Sidecar模式，我得先讲个故事。有一次我在做微服务改造，发现每个服务都要重复实现认证、限流、熔断这些功能。代码冗余不说，升级一次要改十几个服务。后来我接触到了Sidecar模式，豁然开朗。
Sidecar模式的核心思想是：把网关功能从中心化的节点，搬到每个服务实例旁边。每个服务实例配一个Sidecar代理，所有流量都经过这个代理。
# Istio中的Sidecar注入示例
apiVersion: apps/v1
kind: Deployment
metadata:
name: user-service
spec:
template:
metadata:
annotations:
sidecar.istio.io/inject: "true"
spec:
containers:
- name: user-service
image: user-service:latest
- name: istio-proxy # 这就是Sidecar
image: proxyv2:latest
Sidecar模式的优势：
- 解耦：业务代码和基础设施逻辑完全分离
- 统一管理：所有Sidecar由控制面统一配置
- 语言无关：无论你的服务用Java、Go还是Python，Sidecar都一样
关键点：Sidecar模式不是替代集中式网关，而是补充。我一般建议：南北向流量（外部到内部）用集中式网关，东西向流量（服务间调用）用Sidecar。
2.4 网关的部署拓扑：怎么选？
好了，模式讲完了，那实际项目中怎么选？我根据经验整理了一个表格：
| 场景 | 推荐模式 | 原因 |
|---|---|---|
| 小型SaaS（日活<10万） | 集中式网关 | 简单、够用、维护成本低 |
| 中型SaaS（日活10-100万） | 分布式网关 | 需要水平扩展和高可用 |
| 大型SaaS（日活>100万） | 分布式网关 + Sidecar | 既要南北向统一入口，又要东西向解耦 |
| 微服务数量>50 | Sidecar模式（服务网格） | 服务间调用复杂，需要统一治理 |
部署拓扑的几种常见方案：
- 单机房部署：所有网关实例部署在一个机房，适合初期
- 多机房部署：每个机房部署独立的网关集群，通过DNS或全局负载均衡做流量调度
- 混合部署：核心服务用Sidecar，非核心服务走集中式网关
我的建议：别一开始就上Sidecar。我见过太多团队，微服务还没几个就上了Istio，结果运维成本翻倍。先从小规模集中式网关开始，等业务复杂度上来了，再逐步演进到分布式和Sidecar。
2.5 避坑指南
最后，分享几个我踩过的坑：
- 不要迷信一种模式：我曾经在一个项目里强行用Sidecar替代所有网关，结果发现外部流量处理效率反而下降了。后来我改成混合模式，问题才解决。
- 注意网关的版本兼容：升级网关时，一定要先验证和后端服务的兼容性。我有一次升级Kong，结果路由插件的API变了，导致线上路由失效。
- 监控不能少：无论哪种模式，网关的监控都是必须的。我习惯至少监控：QPS、延迟、错误率、CPU/内存使用率。
嗯，这一节的内容就到这里。记住一句话：没有最好的架构模式，只有最适合当前阶段的模式。下一节我们聊聊网关的路由策略，到时候见。