微服务Kong（八）——代理参考

标签：plugin   local   class   决定   nginx   upstream   概述   client   指南   

Kong侦听四个端口的请求，默认情况是：

　　8000：此端口是Kong用来监听来自客户端的HTTP请求的，并将此请求转发到您的上游服务。这也是本教程中最主要用到的端口。

　　8443：此端口是Kong监听HTTP的请求的端口。该端口具有与8000端口类似的行为，但是它只监听HTTPS的请求，并不会产生转发行为。可以通过配置文件来禁用此端口。

　　8001：用于管理员对KONG进行配置的端口。

　　8444：用于管理员监听HTTPS请求的端口。

　　在本文中，我们将介绍Kong的路由功能，并详细说明8000端口上的客户端请求如何根据请求头、URI或HTTP被代理到配置中的上游服务。

基础术语：

　　API：指Kong的API实例。您可以通过管理员身份配置您的API。

　　Plugin：他指的是Kong的“插件”，它们是在代理生命周期中运行的业务逻辑。可以通过管理员身份进行全局配置，也可针对每个API进行分别配置。

　　Client：指向Kong的代理端口发出请求的下游客户，即第三方客户端。

　　Upstream service：指的是位于Kong后面的您自己的API服务，客户端请求被转发的最终目的地。nginx中的上游服务器。

概述

　　从整体上来看，Kong侦听其配置的代理端口上的HTTP请求（默认为8000），并识别正在请求的是哪个上游服务，然后运行在该API上的配置插件（如果没有则不执行），并将上游的HTTP请求转发到您自己的API服务。

　　当客户端向代理端口发出请求时，Kong将根据API在KONG里的配置情况，来决定将请求传入到哪个上游服务中。 您可以在KONG里对每个API添加许多属性，但是有三个是必须要配置的，他们是hosts、uris和methods。如果KONG无法确定API请求的上游服务地址，则会返回一下内容：

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

{
    "message": "no API found with those values"
}

　　回忆下：如何向KONG添加一个API

　　　　在之前的添加一个API的指南中，有学习过如何使用8001端口，在KONG服务中添加一个API的操作：

$ curl -i -X POST http://localhost:8001/apis/ \
    -d ‘name=my-api‘     -d ‘upstream_url=http://my-api.com‘     -d ‘hosts=example.com‘     -d ‘uris=/my-api‘     -d ‘methods=GET,HEAD‘
HTTP/1.1 201 Created
...

　　　　该代码表示用户成功在Kong里注册一个名为“my-api”的API，可通过访问“http://example.com”发送请求。它还指定了一些HTTP请求的属性，但请注意，这里有且只有一个HOST，URIS和METHODS属性。当完成此配置后，以后所有的符合此host、uris和methods的请求，都将由KONG来代理过滤转发。Kong是一个透明的代理，它会将请求转发给您的上游服务，除了添加诸如Connection之类的各种标题。

　　路由功能

　　　　现在我们来讨论一下，一个HTTP请求是如何与API配置属性（如host、uris、methods）相匹配的。需要注意的是，这三个字段（h、u、m）都是可选的，但至少要有一个被指定。对于客户端请求与API的匹配：

　　　　· 请求必须包含所有已配置的字段

　　　　· 请求中的字段值必须与至少一个已配置的值相匹配（尽管字段配置接受一个或多个值，请求只需要考虑匹配其中之一）

　　　　让我们来看几个例子。请看如下一个API配置：

{
    "name": "my-api",
    "upstream_url": "http://my-api.com",
    "hosts": ["example.com", "service.com"],
    "uris": ["/foo", "/bar"],
    "methods": ["GET"]
}

　　　　与该API相匹配的一些请求可能是：

GET /foo HTTP/1.1
Host: example.com

GET /bar HTTP/1.1
Host: service.com

GET /foo/hello/world HTTP/1.1
Host: example.com

　　　　以上的三个请求都满足API定义中设置的条件。但是，以下的几个请求则与配置的条件不匹配：

GET / HTTP/1.1
Host: example.com

POST /foo HTTP/1.1
Host: example.com

GET /foo HTTP/1.1
Host: foo.com

　　　　以上的三个请求只满足两个配置条件。第一个请求的URI不匹配，第二个请求的HTTP方法不匹配，第三个请求的Host头不匹配。

　　　　现在我们了解了hosts、uris、methods是如何一起工作的。下面我们来逐个了解他们是如何单独工作的。

　　　　1. 请求的HOST头：

微服务Kong（八）——代理参考

标签：plugin   local   class   决定   nginx   upstream   概述   client   指南   

原文地址：http://www.cnblogs.com/SummerinShire/p/6628021.html