API网关、服务发现和负载均衡怎么区分？系统架构设计师讲解

先看它面对的是外部请求，还是服务内部调用

API 网关更像微服务系统的对外门面。客户端不需要知道订单服务、库存服务、支付服务分别在哪里，而是先访问统一入口，由网关做路由、认证鉴权、限流、日志、协议适配等横切能力。

服务发现关注的是服务实例动态变化以后，调用方怎么找到当前可用实例。服务扩容、缩容、故障迁移以后，如果地址还靠手写配置，微服务就很难弹性运行。服务发现通常会和注册中心配合出现。

API 网关确实承担统一入口职责，但它不应该变成新的大单体。比如订单金额计算、库存扣减、会员积分规则，这些核心业务逻辑通常仍应在对应业务服务里完成。网关更适合处理认证、路由、协议转换、限流、日志、灰度发布等共性能力。

考试题如果说“外部客户端不用分别了解每个服务地址，并在统一入口完成认证、路由和限流”，答案大概率是 API 网关；如果题干说“服务实例地址变化，调用方要找到可用实例”，那就不是网关的首要职责，而是服务发现。

App 用户访问系统入口：先想到 API 网关。

订单服务要找到当前可用的库存服务实例：先想到服务发现。

三台商品服务共同承接请求：先想到负载均衡。

服务启动后把地址和健康状态上报：先想到注册中心。

负载均衡的重点是把请求合理分配给多个后端节点，常用于提升吞吐、横向扩展和可用性。它可以基于轮询、权重、最少连接等策略分发请求，也可以配合健康检查避开异常节点。

服务发现解决的是“有哪些可用节点”的问题，负载均衡解决的是“这次请求发给哪个节点”的问题。它们经常一起工作，所以题目才爱混着考。做题时不要只看到多个服务实例就直接选服务发现，要看题干到底强调动态定位，还是请求分摊。

这组概念不建议背成一堆产品名。看到“统一入口”，先想 API 网关；看到“动态找到实例”，先想服务发现；看到“服务上报地址和健康状态”，先想注册中心；看到“多节点分担请求”，先想负载均衡。

真实架构里这些组件常常组合使用，但软考选择题通常问的是最贴合题干的职责。不要因为它们都出现在微服务图里，就把职责边界抹掉。能把边界讲清楚，才算真正掌握。