当前位置: 首页 > news >正文

KONG API Gateway中的核心概念

在使用Kong API Gateway(API网关)时,理解其核心概念是掌握其工作原理的基础。这些概念既体现了Kong的设计哲学,也决定了它如何适配复杂的API管理场景(如微服务、多团队协作等)。本文将系统梳理Kong的核心概念,解析它们的定义、作用及相互关系。

一、基础实体:API流量的“基本单元”

Kong通过几个核心实体(entity)抽象API管理的关键要素,这些实体是配置和管理的基础。

1. Service(服务)

Gateway Service entities are abstractions of each of your own upstream services

定义:Service是对后端业务服务(如用户服务、订单服务)的抽象,代表一个需要被Kong代理的上游(upstream)服务。

作用:Service存储了后端服务的核心信息,例如服务的协议(HTTP、gRPC、TCP等)、主机地址(域名或IP)、端口等,是Kong转发请求的“目标地址”。

举例:假设后端有一个用户服务,地址为http://user-service:8080,则在Kong中创建一个Service,配置protocol: httphost: user-serviceport: 8080,即可代表该服务。

2. Route(路由)

A Route defines rules to match client requests, and is associated with a Service.

定义:Route是客户端访问Service的“入口规则”,用于将客户端请求(通过URL、方法、头部等条件)匹配到对应的Service。

作用:Route定义了“如何访问Service”,通过匹配规则将外部请求路由到正确的后端Service。一个Service可以关联多个Route(多入口),一个Route只能关联一个Service。

核心配置

  • paths:匹配请求的URL路径(如/api/v1/users);
  • methods:匹配请求的HTTP方法(如GET、POST);
  • hosts:匹配请求的Host头部(如api.example.com);
  • headers:匹配请求的特定头部(如X-API-Version: v1)。

举例:为用户Service配置两个Route:

  • Route1:paths: /users,匹配http://api.example.com/users的请求;
  • Route2:paths: /v1/users,匹配http://api.example.com/v1/users的请求;
    两者最终都会转发到用户Service。

3. Consumer(消费者)

Consumers are the end users of a service.

定义:Consumer是对API调用方(如客户端应用、用户)的抽象,用于标识请求的来源身份。

作用:通过Consumer可以实现精细化的权限控制、流量限制、计费等功能(结合插件)。例如,为不同Consumer配置不同的限流阈值,或仅允许特定Consumer访问某Route。

关联方式:客户端请求需通过某种方式(如API密钥、JWT令牌)与Consumer关联,Kong通过验证令牌中的身份信息,识别对应的Consumer。

二、流量处理:从请求到转发的“中间层”

Kong作为网关,核心功能是处理客户端到后端服务的流量,以下概念描述了流量处理的关键环节。

4. Upstream(上游)

An Upstream represents a virtual hostname and can be used to load balance incoming requests over multiple Services.

定义:Upstream是对一组后端服务实例(如多个用户服务节点)的抽象,用于实现负载均衡(load balancing)和故障转移(failover)。

作用:当后端服务有多个实例(如微服务架构下的集群部署)时,Upstream通过负载均衡策略将请求分发到不同实例,避免单节点过载。

与Service的关系:Service可以直接关联单个后端地址(简单场景),也可以关联Upstream(集群场景)。例如,用户Service的host配置为Upstream名称,而非具体IP,即可启用负载均衡。

5. Target(目标)

A target is an IP address/hostname with a port that identifies an instance of a backend service.

定义:Target是Upstream下的具体后端服务实例(如192.168.1.100:8080),代表一个可接收请求的节点。

作用:Target是Upstream的“组成单元”,Upstream通过管理Target的状态(在线/离线)实现流量分发。例如,当某个Target故障时,Kong会自动将流量转发到其他健康Target。

健康检查:Kong支持对Target进行主动/被动健康检查(如HTTP状态码、响应时间),自动剔除故障节点。

6. Plugin(插件)

Plugins allow you to extend Kong’s capabilities with features like rate limiting, authentication, and logging.

定义:Plugin是Kong的“功能扩展模块”,通过嵌入请求处理生命周期,为API添加额外功能(如认证、限流、监控等)。

作用:插件无需修改网关核心代码,即可扩展Kong的能力,是Kong灵活性的核心。

生效范围:插件可以绑定到Service、Route、Consumer或全局(Global),实现不同粒度的功能生效。例如:

  • 绑定到Route:仅对该Route的请求生效;
  • 绑定到Consumer:仅对该Consumer的请求生效。

常见类型:JWT(认证)、Rate Limiting(限流)、Prometheus(监控)等(前文已详细介绍)。

三、架构组件:Kong的“运行骨架”

Kong采用“控制平面+数据平面”的分离架构,以下概念描述其运行时的核心组件。

7. Data Plane(数据平面)

定义:Data Plane是处理实际API流量的节点(Kong Gateway实例),负责请求转发、插件执行、负载均衡等实时操作。

作用:直接与客户端和后端服务交互,是流量的“处理中枢”。数据平面节点可横向扩展(部署多个实例),通过负载均衡器分担流量压力。

8. Control Plane(控制平面)

定义:Control Plane是管理全局配置的中枢,负责接收和存储配置(如Service、Route、插件规则),并将配置同步到所有Data Plane节点。

作用:实现“配置一次,全局生效”,避免逐个节点修改配置的繁琐。控制平面不处理业务流量,仅负责配置管理。

9. Admin API

定义:Admin API是Kong的管理接口,用于通过HTTP请求创建、修改、删除各类实体(Service、Route、插件等)。

作用:是用户与Kong交互的主要方式(除图形化界面Kong Manager外)。例如,通过POST /services创建Service,通过PUT /routes/{id}修改Route规则。

安全性:Admin API默认仅监听本地地址,生产环境需配置认证(如密钥)和网络隔离,防止未授权访问。

四、概念关系:一张图看懂Kong的工作流

这些概念的协作流程可简化为:

  1. 客户端发送请求(如GET http://api.example.com/users);
  2. 请求到达Data Plane节点,Kong通过Route的匹配规则(paths: /users)找到对应的Service;
  3. Service关联到Upstream,Kong根据负载均衡策略将请求转发到某个健康的Target(后端实例);
  4. 转发过程中,绑定到Route/Service的插件(如JWT认证、限流)在请求生命周期的特定阶段执行(如access阶段验证令牌);
  5. 后端服务处理请求并返回响应,经Kong返回给客户端;
  6. 所有配置(Route、Service、插件等)通过Control Plane同步到Data Plane,确保集群一致性。

结语

Kong的核心概念围绕“抽象实体”和“分层架构”设计:

  • 通过Service/Route抽象API的“目标”与“入口”
  • 通过Upstream/Target实现集群流量分发
  • 通过Plugin扩展功能
  • 通过控制平面/数据平面分离实现高效管理

理解这些概念,是灵活配置Kong、应对复杂API管理场景的基础。无论是简单的单服务代理,还是大规模微服务架构,这些概念都是构建Kong配置的“积木”。

http://www.lryc.cn/news/604634.html

相关文章:

  • 聊聊如何判断发现的缺陷属于前后端
  • 【Dolphinscheduler】docker搭建dolphinscheduler集群并与安全的CDH集成
  • winsock socket通讯为什么UDP服务器无法获取客户端IP?
  • UDP通讯和TCP通讯的区别-UDP(用户数据报协议)和 TCP(传输控制协议)
  • BeeWorks Meet:私有化部署,重塑高安全需求行业的视频会议体验
  • 云计算:一场关于“数字水电煤”的革命与未来
  • LoongCollector 安全日志接入实践:企业级防火墙场景的日志标准化采集
  • java~单例设计模式
  • react19更新哪些东西
  • 如何通过IT-Tools与CPolar构建无缝开发通道?
  • 第十七章 追新词
  • 7.Linux :进程管理,进程控制与计划任务
  • LLM—— 基于 MCP 协议(Streamable HTTP 模式)的工具调用实践
  • 【拓扑排序】P2403 [SDOI2010] 所驼门王的宝藏|省选-
  • Redis学习------缓存雪崩
  • 01初识算法:从零开始的思维之旅
  • 【Spring Cloud】Spring Cloud 跨域解决方案深度剖析与工程实践指南(万字详解)
  • docker 安装elasticsearch
  • uniapp中的$vm
  • LeetCode 56 - 合并区间
  • 7. 传输层协议 TCP
  • 关系型数据库架构最优选择:基于落霞归雁思维框架的分析
  • 15.11 单卡训练770M参数模型!DeepSpeed ZeRO-3实战:RTX 4090显存直降6.8GB
  • 10 分钟上手 Elasticsearch 语义搜索(Serverless Cloud 本地双版本教程)
  • 基因组选择育种-2.1.最佳线性无偏估计
  • GitHub使用小记——本地推送、外部拉取和分支重命名
  • RPA软件推荐:提升企业自动化效率
  • STM32学习记录--Day3
  • IPEmotion数据采集软件功能介绍
  • 【n8n】如何跟着AI学习n8n【02】:基础节点学习