Kong怎么用：我把接口网关跑通的实测记录
Kong怎么用，最容易卡住的不是安装，而是把“路由、服务、插件”三件事连起来。我用本地 Docker 跑了一个后端接口，再接入限流、鉴权和日志，整理出一套能在半小时内看见效果的实测路径，也把几个看似正常、实际埋雷的细节写清楚。
先说结论：Kong适合拿来做什么
Kong 是 API Gateway，也就是放在客户端和后端服务中间的一层入口。客户端不用记住十几个微服务地址，只请求 Kong；Kong 再决定把流量转给谁、要不要校验 Token、是否限流、是否记录日志。
我最喜欢它的一点，是把原本散落在每个业务服务里的“横切逻辑”抽出来。比如登录态校验、跨域、每分钟 100 次的访问限制，这些不该由订单服务、商品服务各写一遍。小团队先用它统一入口，大一点的团队再逐步接监控、灰度和多环境配置，路径比较顺。
第一步：用Docker启动，别急着碰复杂配置
本地体验建议直接用 Kong 的数据库无关模式（DB-less）。准备一个 kong.yml，Docker 容器启动时挂载进去即可。这样不需要先安装 PostgreSQL，适合学习路由和插件。命令里的关键是把 8000 暴露为代理端口、8001 暴露为管理端口；生产环境别把 8001 直接暴露到公网，这个后面会反复提。
启动后先访问管理接口确认状态，例如请求 /status。看到数据库或配置状态正常，再继续配业务。很多人一上来粘一大段 declarative config，容器报错后完全不知道是 YAML 缩进、镜像版本还是插件名称的问题；先跑空配置，排查成本最低。
第二步：把Service和Route配成一条可访问链路
Kong 里 Service 表示上游服务，Route 表示用户怎么进来。我的测试后端是 httpbin：Service 指向 http://httpbin.org，Route 匹配路径 /demo。请求 http://localhost:8000/demo/get 时，Kong 就会把请求代理到上游对应路径。
这里有个很直观的理解法：Service 是“送货地址”，Route 是“快递柜取件规则”。一个 Service 可以挂多个 Route，例如 /v1/user 和 user.example.com 都转给用户服务；一个 Route 也能按 path、host、method 组合匹配。实测中最容易误判的是路径处理：要明确是否保留前缀，别看到上游 404 就立刻怀疑网络。
第三步：只加两个插件，马上感受网关价值
我建议先试 rate-limiting 和 key-auth。rate-limiting 可以按 consumer、IP 等维度限制请求频率，例如每分钟 10 次；连续 curl 十几次，返回 429 时你就能立刻确认插件生效。注意开发环境常见的 local 策略不适合多节点共享计数，集群要根据部署方式选择 Redis 等合适策略。
key-auth 则会要求请求带 API Key。创建 Consumer、生成 Key，再通过 apikey 参数或指定请求头调用。它不是用户登录系统的替代品，却非常适合内部工具接口、开放平台的第一道门。测试时别把 Key 写进前端代码或 Git 仓库；这类事故比配置错误更常见。
最后的实测清单：能通不等于能上线
跑通以后，我会顺手检查五件事：上游超时是否合理、代理端口是否只对必要网络开放、管理接口是否限制访问、错误日志是否能查、配置是否能在新机器复现。尤其是超时，Kong 默认或继承的行为未必符合业务：支付回调和图片下载的等待时间就不该一样。
Kong怎么用，核心不是背配置字段，而是按“Service 指向哪里、Route 怎么进来、Plugin 做什么”这条线思考。先让一条请求稳定穿过网关，再增加认证、限流、可观测性。这样学不会乱，也不会把一个本来很轻的网关项目搞成配置迷宫。
推荐阅读
常见问题
Kong怎么用，必须安装数据库吗？
不必须。学习、本地开发和部分配置管理场景可使用 DB-less 模式，以声明式配置加载。需要通过 Admin API 动态管理实体，或采用相应集群方案时，再评估数据库模式。
Kong的8000和8001端口有什么区别？
8000 通常是代理流量入口，业务客户端访问它；8001 通常是管理接口。管理端口应只允许受信任网络或管理平面访问，不能为了方便直接暴露公网。
一个接口需要同时配置Service和Route吗？
通常需要。Service 定义上游地址，Route 定义匹配规则。没有 Route，外部请求无法按规则进入；没有 Service，Route 也没有可代理的目标。