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

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.xdnf.cn/news/16609.html

相关文章:

  • 图像处理中级篇 [1]—— 彩色照相机的效果与预处理
  • SpringBoot之整合SSM步骤
  • PHP语法高级篇(七):MySQL数据库
  • [论文阅读] 人工智能 + 软件工程 | 增强RESTful API测试:针对MongoDB的搜索式模糊测试新方法
  • 【LINUX网络】使用TCP简易通信
  • 【STM32-HAL】 SPI通信与Flash数据写入实战
  • 国产化再进一步,杰和科技推出搭载国产芯片的主板
  • 【CF】Day115——杂题 (构造 | 区间DP | 思维 + 贪心 | 图论 + 博弈论 | 构造 + 位运算 | 贪心 + 构造 | 计数DP)
  • 代码随想录算法训练营第五十五天|图论part5
  • 【音视频】WebRTC-Web 音视频采集与播放
  • 如何利用 Redis 的原子操作(INCR, DECR)实现分布式计数器?
  • CSS-in-JS 动态主题切换与首屏渲染优化
  • IBM Watsonx BI:AI赋能的下一代商业智能平台
  • 领域驱动设计(DDD)在分布式系统中的架构实践
  • jenkins连接docker失败【还是没解决】
  • 基于SpringBoot+MyBatis+MySQL+VUE实现的便利店信息管理系统(附源码+数据库+毕业论文+远程部署)
  • 计算机网络基础(一) --- (网络通信三要素)
  • 【C++算法】77.优先级队列_数据流的中位数
  • PHP云原生架构:容器化、Kubernetes与Serverless实践
  • 机器学习笔记(四)——聚类算法KNN、Kmeans、Dbscan
  • 深入理解 Qt 元对象系统 (Meta-Object System)
  • 架构实战——互联网架构模板(“用户层”和“业务层”技术)
  • 【Linux系统编程】Ext2文件系统
  • 【C++】指针
  • 【面试场景题】阿里云子账号设计
  • 【数据结构】用堆实现排序
  • JavaWeb 入门:JavaScript 基础与实战详解(Java 开发者视角)
  • 「源力觉醒 创作者计划」_文心大模型 4.5 多模态实测:开源加速 AI 普惠落地
  • 某雷限制解除:轻松获取原始下载链接,支持多任务转换
  • Hyperchain安全与隐私机制详解