介绍

此篇将通过详细解释Kong的路由功能和内部工作原理来介绍Kong的代理功能。

Kong暴露了几个接口，可以调整三个配置属性：

• proxy_listen：它定义了一个地址/端口列表，在这个列表上，Kong将接受来自客户端的公共HTTP (gRPC, WebSocket等)流量，并代理它到你的上游服务(默认8000)。
• admin_listen：它还定义了一个地址和端口列表，但是这些应该被限制为只有管理员才能访问，因为它们暴露了Kong的配置功能：Admin API(默认为8001)。
• stream_listen：它类似于proxy_listen，但用于第4层(TCP, TLS)通用代理。这在默认情况下是关闭的。

术语

• 客户端：指向Kong代理端口发出请求的下游客户端。
• 上游服务：指您位于Kong后面的API或服务，客户端请求/连接被转发后面的API或服务。
• 服务：服务实体，顾名思义，是您上游服务的抽象。例如数据转换微服务、账单API服务等等。
• 路由：指Kong路由的实体。路由是Kong的入口点，它定义了匹配请求的规则，并路由到给定的服务。
• 插件：指的Kong的“插件”，它们是在代理生命周期中运行的业务逻辑片段。插件可以通过管理API来配置，无论是全局的(所有传入的流量)还是特定的路由和服务。

概述

从高层次的角度来看，Kong在其配置的代理端口(默认为8000和8443)上监听HTTP流量，在显式配置的stream_listen端口上监听L4流量。Kong将根据您配置的路由评估任何传入HTTP请求或L4连接，并尝试找到一个匹配的规则。如果给定的请求与特定路由的规则相匹配，Kong将处理代理该请求。

因为每个路由都可能连接到一个服务，Kong将运行您在路由上配置的插件及其相关服务，然后代理上游的请求。你可以通过Kong的管理API来管理路由。路由具有特殊的属性，用于对传入HTTP请求进行路由匹配。路由属性因子系统而异(HTTP/HTTPS、gRPC/gRPC和TCP/TLS)。

子系统和路由属性：

• http： methods，hosts，headers，paths (https的snis)
• tcp： sources，destinations (tls的snis)
• grpc： hosts， headers，paths (grpcs的snis)

如果试图配置一个不支持的路由属性的路由(例如，带有sources或destinations 字段的http路由)，将输出一个错误消息：

HTTP/1.1 400 Bad Request
Content-Type: application/json
Server: kong/<x.x.x>
  
{
    "code": 2,
    "fields": {
        "sources": "cannot set 'sources' when 'protocols' is 'http' or 'https'"
    },
    "message": "schema violation (sources: cannot set 'sources' when 'protocols' is 'http' or 'https')",
    "name": "schema violation"
}

如果Kong接收到一个无法与任何已配置路由匹配的请求(或者没有配置路由)，它将响应：

HTTP/1.1 404 Not Found
Content-Type: application/json
Server: kong/<x.x.x>

{
    "message": "no route and no Service found with those values"
}