一个入口，多个服务
外部客户端不应该了解内部服务拓扑。网关暴露稳定路由，对调用方只认证一次，执行配额，再把请求转发给当前后端。服务迁移或拆分时，公开契约保持不变。
routes:
- path: /api/orders
service: orders
auth: bearer
rate_limit: orders_default
timeout: 3s
- path: /api/catalog
service: catalog
auth: api_key
cache: 60s配置只是示意，关键在于边缘策略是显式且经过评审的。网关如果悄悄重试非幂等写入，或者给快速端点设置 30 秒超时，它自己就会制造生产事故。
把领域逻辑留在服务内
网关能看到每个请求，因此很容易在里面做数据补充、校验和编排。但这会把边缘耦合到领域规则，使每次业务变更都变成网关发布。业务校验应留在拥有数据的服务里；网关只负责身份、粗粒度配额、传输安全、路由和可观测性。
网关也是单点故障和共享瓶颈。部署时必须冗余、预留容量，并准备经过测试的绕过或故障转移路径。要单独监控网关延迟：网关 p99 问题不是服务问题，但用户感受到的影响相同。
何时使用
当多个客户端需要一致的边缘策略，或内部拓扑频繁变化时，使用 API 网关。优点是集中认证、配额和路由；代价是多一跳、多一个关键共享依赖，以及过度集中的诱惑。与在每个服务里嵌入反向代理相比，网关提供单一控制点，同时也集中了风险。