在微服务架构中,你为何选用 Gateway 作为 API 网关?请说明其选型理由。
考察说明
考察候选人对微服务网关选型的理解,以及其在实际项目中的技术决策能力和场景适配性。
回答思路
- 【回答框架 1】Spring Cloud Gateway 基于 Spring WebFlux 和 Reactor,采用非阻塞 IO,在处理高并发请求时相比 Zuul 1.x 的同步 Servlet 模型具有更好的资源利用率和吞吐量表现,这通常是选型的关键性能考量。
- 【回答框架 2】Gateway 提供了丰富的路由、过滤器(Global Filter 和 Gateway Filter)机制,能够灵活实现请求转发、鉴权、限流、灰度发布等横切关注点,其谓词(Predicate)工厂和过滤器工厂的设计使得配置和扩展都较为便利。
- 【回答框架 3】选择 Gateway 也考量了与现有技术栈 Spring Cloud 的生态集成。它原生支持与注册中心(如 Nacos、Eureka)整合,能自动发现服务实例进行路由分发,降低了开发与运维成本。同时,其内置的限流过滤器等能力可以简化实现复杂度。
- 【回答框架 4】具体选型还需结合团队技术熟悉度与运维能力评估。若团队对响应式编程不熟悉,存在学习成本;且对于超低延迟或少量请求的场景,其性能优势可能不显著,需要权衡收益。
- 【关键点 1】Gateway 非阻塞异步模型相比传统同步模型在高并发下更有优势。
- 【关键点 2】灵活的谓词与过滤器机制满足路由和横切需求。
- 【关键点 3】与 Spring Cloud 生态集成好,方便服务发现与统一治理。
- 【易错点 1】将网关的选型仅归因于性能,而忽略其功能特性和团队适配性。
- 【易错点 2】认为 Gateway 的性能一定优于所有同步网关,忽略具体场景和压测评估。