使用 Docker 安装

一、微服务架构从 5 个服务膨胀到 50 个服务后客户端直接调用服务的方案彻底崩溃50 个服务地址需要客户端配置服务版本升级需要客户端同步更新认证授权需要在每个服务重复实现……API 网关就是解决这些问题的统一入口。但 API 网关的设计和选型不是装个 Nginx就能解决它需要覆盖路由、认证、限流、监控、缓存多个层面且需要高性能、高可用。那些看似简单的转发背后往往藏着复杂的架构决策。二、API 网关的核心功能与架构模式API 网关是系统的统一入口负责请求路由、组合和协议转换。它的核心功能包括graph TB A[客户端] -- B[API网关] B -- C[路由层br/路径匹配/负载均衡] B -- D[认证层br/JWT/OAuth/API Key] B -- E[限流层br/令牌桶/漏桶] B -- F[缓存层br/响应缓存/CDN] B -- G[监控层br/日志/指标/追踪] B -- H[转换层br/协议转换/数据格式] C -- I[后端服务1] C -- J[后端服务2] C -- K[后端服务3] style B fill:#e1f5fe style C fill:#fff3e0 style D fill:#e8f5e9 style E fill:#f3e5f51. 路由Routing根据请求路径、域名、Header 路由到不同后端服务。支持路径重写、负载均衡、健康检查。2. 认证与授权Authentication Authorization统一处理用户认证如 JWT 验证和权限检查避免在每个服务重复实现。3. 限流Rate Limiting保护后端服务不被流量冲垮。支持按 IP、用户、API Key 限流。4. 缓存Caching缓存后端响应减少后端压力提升响应速度。5. 监控与日志Monitoring Logging记录请求日志、收集指标、生成分布式追踪上下文。6. 协议转换Protocol Translation将外部协议如 HTTP/REST转换为内部协议如 gRPC、GraphQL。API 网关的架构模式单体重网关一个网关处理所有请求。优点简单缺点单点故障、性能瓶颈。分布式网关每个服务或每组服务伴生一个网关。优点无单点缺点运维复杂。分层网关流量网关如 Nginx 业务网关如 Spring Cloud Gateway。优点职责分离缺点延迟增加。三、生产级 API 网关的选型与实现主流 API 网关方案对比方案优点缺点适用场景Nginx高性能、稳定功能有限、配置复杂简单路由、静态内容Kong功能丰富、插件生态依赖 PostgreSQL、性能中等需要丰富插件APISIX高性能、云原生相对较新、生态不如 Kong云原生、高性能需求Envoy高性能、可扩展配置复杂、学习曲线陡服务网格、gRPCSpring Cloud GatewayJava 生态集成好性能不如 Nginx、依赖 JVMJava 微服务使用 APISIX 构建高性能 API 网关APISIX 是高性能的云原生 API 网关基于 OpenRestyNginx LuaJIT构建。安装 APISIX# 使用 Docker 安装 git clone https://github.com/apache/apisix-docker.git cd apisix-docker/example docker-compose up -d配置路由与负载均衡# 创建路由将所有 /api/* 请求路由到后端服务 curl http://127.0.0.1:9180/apisix/admin/routes \ -H X-API-KEY: edd1c9f034335f136f87ad84b625c8f1 \ -X POST \ -d { uri: /api/*, upstream: { type: roundrobin, nodes: { order-service:8080: 1, product-service:8080: 1, user-service:8080: 1 } } }配置认证JWT# 启用 JWT 插件 curl http://127.0.0.1:9180/apisix/admin/routes/1 \ -H X-API-KEY: edd1c9f034335f136f87ad84b625c8f1 \ -X PATCH \ -d { plugins: { jwt-auth: {} } } # 配置 JWT 密钥 curl http://127.0.0.1:9180/apisix/admin/consumers \ -H X-API-KEY: edd1c9f034335f136f87ad84b625c8f1 \ -X PUT \ -d { username: user1, plugins: { jwt-auth: { key: user-key, secret: my-secret-key } } }配置限流# 启用限流插件令牌桶算法 curl http://127.0.0.1:9180/apisix/admin/routes/1 \ -H X-API-KEY: edd1c9f034335f136f87ad84b625c8f1 \ -X PATCH \ -d { plugins: { limit-req: { rate: 10, # 每秒 10 个请求 burst: 20, # 允许突发 20 个请求 key: remote_addr, # 按 IP 限流 rejected_code: 429 } } }配置响应缓存# 启用代理缓存插件 curl http://127.0.0.1:9180/apisix/admin/routes/1 \ -H X-API-KEY: edd1c9f034335f136f87ad84b625c8f1 \ -X PATCH \ -d { plugins: { proxy-cache: { cache_key: [$uri, -cache], cache_bypass: [$arg_bypass], cache_method: [GET], cache_http_status: [200], cache_time: 300, # 缓存 300 秒 disk_cache_size: 1000 } } }四、API 网关的性能优化与高可用设计API 网关是系统的咽喉性能和高可用至关重要。性能优化策略减少网络跳转API 网关应该尽量靠近后端服务部署如同一个 Kubernetes 集群减少网络延迟。启用 Keep-Alive与后端服务保持长连接减少 TCP 握手开销。响应压缩启用 Gzip 或 Brotli 压缩减少传输数据量。连接池与后端服务使用连接池避免频繁创建连接。异步日志日志写入异步化避免阻塞请求。# Nginx 配置优化示例 worker_processes auto; # 自动设置 worker 数量 worker_rlimit_nofile 65535; # 增加文件描述符限制 events { worker_connections 10240; # 每个 worker 最大连接数 use epoll; # Linux 下使用 epoll multi_accept on; } http { # 开启 gzip 压缩 gzip on; gzip_comp_level 5; gzip_min_length 1024; gzip_types application/json application/javascript text/css; # 连接池优化 upstream backend { keepalive 100; # 保持 100 个空闲连接 keepalive_timeout 60s; keepalive_requests 1000; } # 代理优化 proxy_http_version 1.1; proxy_set_header Connection ; proxy_connect_timeout 5s; proxy_read_timeout 300s; proxy_send_timeout 300s; # 缓冲区优化 proxy_buffering on; proxy_buffer_size 16k; proxy_buffers 32 16k; }高可用设计多副本部署API 网关部署多个副本避免单点故障。健康检查定期探测后端服务健康状态自动摘除故障节点。熔断机制后端服务故障时自动熔断避免雪崩。限流与降级保护后端服务超限请求直接拒绝或返回降级响应。监控与告警实时监控网关性能异常时自动告警。graph TB A[DNS] -- B[负载均衡器br/HAProxy/Nginx] B -- C[API网关副本1] B -- D[API网关副本2] B -- E[API网关副本3] C -- F[后端服务] D -- F E -- F C -- G[健康检查] D -- G E -- G G --|故障节点| H[自动摘除] style B fill:#e1f5fe style G fill:#fff3e0 style H fill:#ffebee监控关键指标请求量QPS每秒请求数。延迟LatencyP50、P90、P99 延迟。错误率Error Rate4xx、5xx 响应比例。上游响应时间后端服务的响应时间。连接数Connections活跃连接数、等待连接数。# Prometheus 监控配置APISIX scrape_configs: - job_name: apisix static_configs: - targets: [apisix:9091] # APISIX 暴露的 metrics 端口五、API 网关的代价与工程陷阱API 网关引入的复杂度往往被低估。以下是工程决策的关键考量代价一单点故障风险API 网关是系统的统一入口一旦故障所有服务不可用。必须通过多副本、健康检查、熔断等机制保证高可用。代价二性能瓶颈所有流量都经过 API 网关可能成为性能瓶颈。需要通过性能优化如前文所述和水平扩展解决。代价三复杂度增加引入 API 网关后需要配置路由、认证、限流等规则增加运维复杂度。需要建立完善的配置管理和变更流程。代价四调试困难请求经过 API 网关转发排查问题需要检查网关日志和后端日志增加调试难度。需要建立分布式追踪系统。工程决策框架场景推荐方案理由小团队10人Nginx 或云负载均衡器简单、稳定需要丰富插件Kong 或 APISIX插件生态完善高性能需求APISIX 或 Envoy性能优异Java 微服务Spring Cloud Gateway生态集成好服务网格环境Envoy与 Istio 集成API 网关的替代方案服务网格Service Mesh如 Istio功能类似 API 网关但更专注于东西流量服务间通信。无网关架构小型系统可以不用 API 网关客户端直接调用后端服务通过 DNS 负载均衡器。GraphQL 网关前端优先的系统可以使用 GraphQL 作为统一入口聚合多个后端服务的数据。常见陷阱在网关实现业务逻辑API 网关应该只处理横切关注点如认证、限流业务逻辑应该在后端服务实现。过度依赖网关某些功能如缓存应该在更靠近用户的地方实现如 CDN而不是全部推给 API 网关。缺乏版本管理API 变更应该在网关层支持版本路由如 /api/v1/、/api/v2/避免 Breaking Change。独立开发者的实用主义建议从简单开始Nginx 或云负载均衡器足以支撑早期产品。明确需求是否需要认证是否需要限流根据需求选择网关方案。使用托管服务云厂商的 API 网关服务如 AWS API Gateway、Azure API Management可以快速搭建且免运维。建立降级策略API 网关故障时系统应该能降级到直接访问后端服务通过备用域名或 IP。深夜的架构图终于完整咖啡也凉了。API 网关不是银弹它只是解决特定问题的工具。真正重要的是理解你的业务需求选择合适的方案并在性能、可用性、复杂度之间找到平衡点。毕竟技术的终极目标是创造价值而不是堆砌组件。