/tags/api-gateway/ Recent content in api-gateway on Hugo -- gohugo.io en Fri, 10 Apr 2026 10:00:00 +0800 /posts/openapi-aggregation-in-microservice-architecture/ Fri, 10 Apr 2026 10:00:00 +0800 /posts/openapi-aggregation-in-microservice-architecture/ 📦 本文基于的完整项目源码：https://github.com/meirongdev/shop 🏷️ 当前文章对应的代码版本：main 背景 在一个典型的微服务架构中，每个服务都独立维护自己的 API 文档。随着服务数量增长，前端开发者和第三方集成方常常面临一个痛点： 我需要去哪里找某个接口的文档？ 传统的解决方案是让开发者记住每个服务的地址，或者维护一个手动的聚合页面。但这些方案都存在明显的问题：容易过时、维护成本高、无法与 CI/CD 集成。 本文以一个云原生电商平台的实际案例，记录我们当前如何通过 Spring Cloud Gateway MVC + SpringDoc 维护一套相对省事的 OpenAPI 聚合方案。 架构概览 我们的平台采用 Gateway + Thin BFF + Domain Service 三层架构： Client └→ api-gateway:8080 (Spring Cloud Gateway MVC, JWT validation, rate limiting) ├→ /auth/** → auth-server ├→ /buyer/** → buyer-portal (Kotlin + Thymeleaf SSR) ├→ /seller/** → seller-app (KMP WASM SPA) ├→ /api/buyer/** → buyer-bff (aggregates domain services) ├→ /api/seller/** → seller-bff (aggregates domain services) ├→ /api/loyalty/** → loyalty-service ├→ /api/activity/** → activity-service ├→ /api/webhook/** → webhook-service └→ /api/subscription/** → subscription-service 共包含： /posts/shop-platform-api-gateway/ Wed, 01 Apr 2026 10:00:00 +0800 /posts/shop-platform-api-gateway/ 在上一篇总览文章中，我们看到了 Shop Platform 的整体架构分层。API Gateway 作为整个系统当前统一的外部入口，承载了身份验证、流量控制、路由分发、文档聚合等多项职责。 📦 本文基于的完整项目源码：https://github.com/meirongdev/shop 上一篇：（一）Shop Platform 总览 2026-04 实践更新 当前主线代码已经从 HS256 共享密钥切到 RS256 + JWKS，并把网关限流的 Lua 执行器统一到 RedissonClient + RScript。下面相关代码片段已按仓库当前实现同步。 为什么选 Spring Cloud Gateway Server MVC Spring Cloud Gateway 最初基于 WebFlux（Reactor）构建，是一个响应式网关。但在 2024–2025 年间，Spring Cloud 团队推出了 Spring Cloud Gateway Server MVC——一个基于 Servlet/MVC 的网关实现。 我们选择 MVC 而非 WebFlux，主要考虑了三点： 1. 统一编程模型 项目里 15+ 个后端服务全部是 Spring Boot MVC + Virtual Threads。如果网关用 WebFlux，就意味着团队需要同时维护两套编程模型：一套响应式（网关），一套同步阻塞（所有下游服务）。调试、日志追踪、异常处理的风格都不一样，增加了认知负担。 2. Virtual Threads 目前能满足需求 Virtual Threads 让每个 I/O 阻塞操作都运行在轻量级虚拟线程上，网关的并发能力不再完全依赖非阻塞 I/O 模型。对于 API Gateway 这种典型的 I/O 密集型应用（读 JWT、查 Redis、转发请求），它在当前项目的流量模型里已经提供了可接受的吞吐量，同时保留了同步代码的可读性。