为什么大公司要用网关，小公司接口直接暴露？
在大型互联网公司的系统架构图中，所有外部请求通常都会先经过一个名为 API 网关（API Gateway） 的组件。相比之下，许多初创公司或小型项目往往采用前端直接调用后端接口的方式。
这种架构差异背后并非简单的技术偏好，而是由业务规模、系统复杂度以及资源约束共同决定的。本文将深入探讨 API 网关的核心运行机制，分析大公司为何必须引入网关，小公司为何选择直接暴露接口，以及架构演进的临界点在哪里。
``API 网关：系统的“统一前台”
要理解 API 网关的作用，可以将其比喻为大型写字楼的一楼大堂前台。
如果没有前台，外卖员、快递员和访客就需要自行上楼，挨个敲门寻找目标人员。这不仅导致流程混乱，更存在极大的安全隐患。API 网关正是这个“前台”，它拦截所有外部请求，执行以下核心职能：
- 身份鉴权（Authentication & Authorization）： 网关首先查验请求者的身份凭证，确认其是否拥有访问特定资源的权限。
- 动态路由（Dynamic Routing）： 根据请求内容，将流量准确引导至对应的后端微服务。
- 解耦后端细节： 客户端只需认准网关这一统一入口，无需知晓后端具体有多少个微服务，也无需关心它们部署在哪台服务器上。
通过这种机制，网关确保了系统在面对海量请求时井然有序，而非陷入混乱。
大公司为何必须使用网关？
大公司后端系统通常已拆分为数十甚至上百个微服务（如订单服务、库存服务、用户服务等）。在这种架构下，直接暴露接口会带来严重的工程和安全问题：
1. 避免客户端硬编码与频繁发版
如果让移动端 APP 直接调用各个微服务，APP 内部必须硬编码几十个不同的接口地址。一旦某个服务的服务器 IP 变更或进行扩容，APP 就必须跟随发版更新。网关作为统一入口，屏蔽了后端拓扑结构的变化，使得后端调整无需客户端配合。
2. 集中处理安全逻辑，消除薄弱环节
如果每个微服务都独立实现一套用户登录状态查验代码，不仅造成代码重复（重复造轮子），还极易因个别开发人员的疏忽（如未严格校验）而留下安全漏洞。黑客往往从这些薄弱环节撕开缺口。 网关将鉴权、限流、日志监控等通用逻辑集中处理，后端微服务只需专注于业务逻辑，从而大幅降低安全风险和维护成本。
小公司为何选择直接暴露接口？
小公司或初创团队通常采用单体架构（Monolithic Architecture），所有功能集中在一个大项目中，部署在一两台服务器上。在这种场景下，直接暴露接口具有明显的务实优势：
- 链路最短，速度最快：前端直接调用后端，中间没有多余的跳转和序列化开销。
- 降低运维复杂度：引入网关意味着需要额外维护一个独立组件、增加服务器成本，并处理网关自身的高可用配置。
- 提升迭代效率：在业务尚未跑通、生存是第一要务的阶段，过度设计会拖慢开发节奏。直接暴露接口是小公司在资源有限情况下，为了快速冲刺而做出的务实妥协。
直接暴露接口的代价与失效边界
虽然直接暴露接口适合早期阶段，但它存在明确的失效边界。当业务发展到以下阶段时，必须引入网关：
- 流量激增与恶意攻击： 当用户量上涨或遭遇恶意刷单、爬虫抓取时，缺乏网关的**限流（Rate Limiting）和熔断（Circuit Breaking）**机制，后端数据库极易被瞬间打挂。
- 系统拆分后的混乱： 随着单体项目日益臃肿，团队不得不将其拆分为微服务。此时，原本直连的接口会变成一张“蜘蛛网”，前端调用关系混乱，问题排查如同大海捞针。
- 缺乏统一规范： 如果没有网关进行协议转换和统一错误码处理，研发团队将陷入无休止的联调与扯皮中，严重影响开发效率。
结语：架构是业务阶段的匹配
是否使用 API 网关，从来不是一个单纯的技术优劣问题，而是业务规模与架构复杂度的匹配问题。
- 小公司直连：是为了在资源受限的情况下快速验证业务，追求极致效率。
- 大公司用网关：是为了在庞大的微服务集群中维持秩序，保障安全与稳定性。
好的架构不是一步到位地堆砌最顶级的组件，而是在当前的业务阶段，选择最能解决当下痛点的那一套方案。当单体架构的痛点开始制约业务发展时，引入 API 网关便是架构演进的自然选择。