从Nginx到APISIX：一个后端开发者的微服务网关迁移实战（含Docker部署避坑）
从Nginx到APISIX：一个后端开发者的微服务网关迁移实战（含Docker部署避坑）
在微服务架构逐渐成为主流的今天，传统的Nginx虽然依然强大，但在动态路由、插件化扩展等方面开始显得力不从心。作为一名长期使用Nginx的后端开发者，我在最近的项目中经历了从Nginx到APISIX的完整迁移过程。这次迁移不仅解决了我们面临的动态配置痛点，还意外收获了更强大的流量管理能力。本文将分享这一过程中的关键决策、具体操作步骤以及那些教科书上不会告诉你的"坑"。
1. 为什么选择APISIX：从Nginx到云原生网关的演进
当我们的微服务数量超过20个时，Nginx配置文件开始变得难以维护。每次新增服务或调整路由策略，都需要手动修改nginx.conf并reload服务。更糟糕的是，当需要实现灰度发布或动态限流时，往往需要借助第三方模块或定制开发。
APISIX作为云原生API网关，最吸引我的几个特性包括：
- 动态配置：所有配置通过Admin API实时生效，无需重启服务
- 插件化架构：内置80+插件，从身份验证到日志收集应有尽有
- 性能表现：基于OpenResty，保持了Nginx的高性能优势
- 可视化面板：内置Dashboard，告别vim改配置的日子
注意：APISIX 2.x版本对etcd有特定版本要求，这是我们在部署时遇到的第一个坑，后文会详细说明。
2. 环境准备与Docker部署实战
我们选择在CentOS 7.9上通过Docker部署APISIX，这是目前生产环境最常用的组合之一。以下是关键步骤和遇到的典型问题：
2.1 基础环境配置
首先确保系统已安装Docker和docker-compose。APISIX依赖etcd作为配置存储，这里特别要注意版本兼容性：
# 安装指定版本的etcd（APISIX 2.x要求etcd 3.4.0+） docker run -d --name etcd \ -p 2379:2379 \ -p 2380:2380 \ -e ETCD_LISTEN_CLIENT_URLS=http://0.0.0.0:2379 \ -e ETCD_ADVERTISE_CLIENT_URLS=http://0.0.0.0:2379 \ bitnami/etcd:3.4.152.2 APISIX核心组件部署
典型的docker-compose.yml配置如下：
version: '3' services: apisix: image: apache/apisix:2.15.0-alpine ports: - "9080:9080/tcp" - "9443:9443/tcp" volumes: - ./apisix_log:/usr/local/apisix/logs depends_on: - etcd部署后最常见的两个问题：
- Dashboard无法访问：默认只监听127.0.0.1，需要修改conf/config.yaml中的admin_listen配置
- 插件加载失败：检查etcd连接是否正常，以及插件依赖的共享库是否完整
3. 关键功能迁移：从Nginx配置到APISIX插件
3.1 路由配置对比
传统Nginx的location配置：
location /user-service/ { proxy_pass http://user-service/; proxy_set_header Host $host; }在APISIX中通过Admin API动态配置：
curl http://127.0.0.1:9080/apisix/admin/routes/1 -H 'X-API-KEY: edd1c9f034335f136f87ad84b625c8f1' -X PUT -d ' { "uri": "/user-service/*", "upstream": { "type": "roundrobin", "nodes": { "user-service:8000": 1 } } }'3.2 限流实现进阶
Nginx中实现基本限流：
limit_req_zone $binary_remote_addr zone=mylimit:10m rate=10r/s; location / { limit_req zone=mylimit burst=20; }APISIX的limit-req插件提供更精细控制：
{ "plugins": { "limit-req": { "rate": 10, "burst": 20, "key": "remote_addr", "rejected_code": 503 } } }更强大的是可以结合consumer实现多维度限流策略：
| 维度 | Nginx实现难度 | APISIX实现方式 |
|---|---|---|
| IP地址 | 容易 | limit-req插件 |
| 用户ID | 困难 | 结合key-auth插件 |
| 接口路径 | 中等 | 路由级别插件配置 |
| 业务参数 | 几乎不可能 | 自定义插件开发 |
4. 生产环境踩坑与性能优化
4.1 常见问题排查指南
我们在生产环境遇到的一些典型问题及解决方案：
性能突然下降
- 检查插件链长度，避免不必要的插件调用
- 使用skywalking插件进行链路追踪
- 调整worker_processes数量匹配CPU核心数
配置丢失
- 确认etcd集群健康状态
- 定期备份etcd数据
- 考虑使用APISIX的配置导出功能
4.2 监控与日志最佳实践
推荐的生产级监控方案组合：
# 启用prometheus插件 curl http://127.0.0.1:9080/apisix/admin/plugins/reload -H 'X-API-KEY: edd1c9f034335f136f87ad84b625c8f1' -X PUT # 典型Grafana监控面板配置 - 请求QPS/延迟 - 插件执行耗时 - 上游服务健康状态 - etcd存储性能指标日志处理建议采用syslog插件直接推送到ELK：
{ "plugins": { "syslog": { "host": "logstash.example.com", "port": 514, "flush_limit": 1 } } }5. 迁移后的架构演进思考
完成APISIX迁移后，我们的架构获得了意想不到的灵活性。一些新的可能性：
- 金丝雀发布：通过traffic-split插件实现
- 全链路加密：easymock插件快速创建测试桩
- 服务网格集成：与Istio控制面对接
一个典型的灰度发布配置示例：
{ "plugins": { "traffic-split": { "rules": [ { "match": [ {"vars": [["http_x_user_id","==","1000"]]} ], "weighted_upstreams": [ {"upstream_id": "1", "weight": 20}, {"upstream_id": "2", "weight": 80} ] } ] } } }在迁移过程中最大的体会是：APISIX不是简单的Nginx替代品，而是开启了一种全新的流量管理模式。它特别适合需要频繁变更路由策略、实现复杂流量治理的场景。对于中小团队来说，可能初期学习曲线略陡峭，但长期来看，这种投入绝对值得。