1. 微服务网关的重要性

想象一家外卖平台，同时需要处理用户下单、骑手调度、支付回调等服务。若每个请求都让客户端直接访问微服务，不仅会增加服务间耦合，还会让安全、限流等逻辑重复开发。微服务网关如同「流量调度中心」，统一处理路由、鉴权、限流等非业务逻辑。

传统单机限流（例如Express中间件）在分布式场景下存在局限：缺乏全局视角、动态配置困难。这正是Kong和APISIX的舞台——它们以API Gateway身份，为企业级流量管理提供标准化解决方案。

2. Kong网关：OpenResty生态下的老牌选手

2.1 Kong的安装与基础路由
docker run -d --name kong \
    -e "KONG_DATABASE=postgres" \
    -e "KONG_PG_HOST=your_postgres_host" \
    -p 8000:8000 \
    -p 8001:8001 \
    kong:3.0.0

# 添加路由规则（假设服务名为order-service）
curl -i -X POST http://localhost:8001/services \
    --data name=order-service \
    --data url='http://backend-service:3000'

curl -i -X POST http://localhost:8001/services/order-service/routes \
    --data 'paths[]=/api/v1/orders'

注释：通过管理端口8001创建服务与路由，将/api/v1/orders的流量代理到后端服务

2.2 请求限流实战：令牌桶算法
# kong.yml（声明式配置）
plugins:
- name: rate-limiting
  config:
    minute: 100        # 每分钟允许100次请求
    policy: local      # 单节点计数器策略
    fault_tolerant: true
routes:
- paths: ["/api/v1/orders"]

注释：通过rate-limiting插件实现基础限流，注意policy参数的选择对分布式一致性有直接影响

3. APISIX网关：云原生时代的后起之秀

3.1 动态路由与插件热加载
# 创建限流路由规则（APISIX Dashboard操作）
route:
  uri: /api/v1/payments/*
  plugins:
    limit-count:
      count: 200
      time_window: 60
      key: remote_addr
      rejected_code: 429
  upstream:
    nodes:
      "payment-service:4000": 1

注释：使用limit-count插件实现IP级限流，策略修改后无需重启生效

3.2 熔断降级：基于故障比例的弹性策略
plugins:
  proxy-rewrite:
    uri: "/v1/iot/device-status"
  api-breaker:
    break_response_code: 503
    unhealthy:
      http_failures: 5  # 连续5次错误触发熔断
      min_fails: 3
    healthy:
      success_count: 2  # 恢复2次成功请求则关闭熔断

注释：当后端服务连续出现5次错误，APISIX会自动切断流量，避免雪崩效应

4. 核心功能对比分析

特性 Kong APISIX
底层架构 基于Nginx + OpenResty 基于Nginx + LuaJIT + etcd
配置生效速度 依赖数据库同步（秒级） 实时生效（毫秒级）
插件生态 官方插件数量多，社区成熟 官方插件质量高，部分企业定制插件
分布式限流 需依赖Redis集群 原生支持ETCD/ZooKeeper协调

经验提示：中小型项目可用Kong的local策略简化部署，高并发场景必须选择redis策略保证全局一致性

5. 生产环境踩坑指南

5.1 缓存导致配置不生效
# Kong强制刷新缓存
curl -X POST http://localhost:8001/cache/reload

# APISIX无需操作，所有配置实时生效

开发常见误区：误以为修改配置后立即生效，实际需要关注缓存机制

5.2 熔断阈值设定陷阱
# 错误示范：将错误率设置过低
healthy:
  success_count: 1
unhealthy:
  http_failures: 2
# 可能导致系统在偶发异常时频繁熔断

推荐值参考：熔断触发阈值应高于业务实际容错能力20%-30%

6. 典型应用场景分析

  • 电商秒杀系统
    使用APISIX的动态限流快速应对突发流量，通过Prometheus实时监控QPS波动

  • 物联网设备管理
    Kong的JWT插件统一鉴权，搭配自定义插件解析MQTT协议头

  • 金融支付链路
    双网关架构：APISIX处理外部API请求，Kong管理内部服务间通信

7. 技术选型决策树

  1. 是否需要灰度发布和动态路由？ → 选APISIX
  2. 是否已有PostgreSQL运维经验？ → 选Kong
  3. 是否需要处理WebSocket长连接？ → 选APISIX
  4. 是否需要对接旧有Java系统？ → 选Kong（更完善的企业支持）

8. 总结与展望

Kong像传统重型卡车：配置严谨但灵活性受限，适合已形成技术体系的企业。APISIX则像新能源跑车：爆发力强但需要谨慎驾驶，适合快速迭代的互联网团队。未来随着Service Mesh的普及，网关角色可能向「边缘计算+网格控制面」方向演进。