Kong 中级教程

最新推荐文章于 2024-05-17 21:03:27 发布
最新推荐文章于 2024-05-17 21:03:27 发布
阅读量1.4k 收藏 4
点赞数
文章标签： 分布式 java 数据库 大数据 javascript
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/lzy_zhi_yuan/article/details/107373898
版权


本文目录结构


什么是kong

 

Kong目前的定位是一个网关组件，非常适合在现代的微服务下进行集成。尽管很多技术网友声称Kong是完全基于Nginx，但是Kong官方纠正了这一不太准确的说法，官方给出的描述是：Kong是运行在Nginx中的Lua应用程序，通过OpenResty的lua-nginx-module模块实现，并且与OpenResty一起发布，这为可插拔的体系结构奠定了基础。在这种体系结构中，可以在运行时启用和执行Lua脚本（称为“插件”）。kong的核心是实现数据库抽象、路由和插件管理。插件可以存在于不同的代码库中，并且可以通过几行代码将限流、降级、鉴权、流量监控等功能插件注入到请求生命周期的任何地方，Kong支持非常丰富的现成插件，并且支持自行开发插件。

 

Kong很多概念确实和Nginx非常类似，实际上笔者认为在功能实现上Kong确实是基于Nginx进行封装的， 当你启动Kong后你可以直接通过ps aux|grep nginx看到实际的Nginx进程在运行。Kong核心思想是通过面向对象的方式将Nginx的基础功能以及加强的其它功能进行良好地架构化（参考插件式微内核架构），包装后通过对外提供Admin-API的Restful接口的方式进行配置。

Kong 快速入门

Kong的定位是应用层面的网关中间件实现，而代理转发功能是网关组件角色的基本功能，实际上Kong的核心功能就是代理转发，其它功能都是基于代理转发的生命周期上进行插件式地拦截处理。本节我们就通过一个简单的代理转发来快速入门Kong。在这之前请确保你已经安装好Kong并启动成功。

 

Kong核心对象概念

学习Kong代理转发前先理解Kong几个核心概念：

 

  • Client：指请求Kong网关的发起请求的客户端，可能是curl或Postman，也可能是微服务应用。

  • Service：Kong核心服务实体对象，指上游后端服务，对应Nginx upstream配置的后端服务条目，或者IPVS的Real Server的概念。

  • Upstream Service：Kong核心服务组实体对象，对一组Service的抽象，对应Nginx的upstream的概念和功能。

  • Route：Kong核心路由规则实体对象，对应Nginx的location配置url规则的功能和概念，Kong除了支持url规则配置外还提供了其它方式的规则配置。

  • Plugin：Kong核心插件实体对象。可以通过Admin API配置全局或特定的路由和服务的插件，通过在代理转发不同生命周期节点上嵌入业务逻辑，例如鉴权，限流等。

  • 看到这里，第一感受应该就是Kong将Nginx的功能进行对象化、丰富化。下面我们开始使用Kong。

 

准备虚拟机节点

 

准备部署虚拟机节点，笔者节点清单如下：

 

hostname

ip

role

node0

10.68.212.100

Kong、PostgreSQL

node1

10.68.212.101

后端服务1

node2

10.68.212.102

后端服务2

 

安装httpd后端服务

# node1、node2安装apache httpd服务，方便后面测试代理转发用：
# 通过yum安装httpd
yum install httpd -y
 
# httpd服务默认配置文件，可根据需要进行配置，这里我们使用默认配置
# vi /etc/httpd/conf/httpd.conf，将默认监听80的端口改为8080：
Listen 8080
 
# 启动httpd服务
service httpd restart
 
# httpd默认将网站的根页面指向/var/www/html/index.html,
# node1我们vi /var/www/html/index.html,输入以下内容：
from node1
# node2我们vi /var/www/html/index.html,输入以下内容：
from node2
 
# 关闭防火墙
systemctl stop firewalld
 
# 浏览器访问验证服务可用：
http://10.68.212.101:8080/
http://10.68.212.102:8080/

配置Kong服务对象

本文从下面开始没有明确说明情况下默认所有命令都在node0节点上执行。

# 添加node1服务
curl -i -X POST \
  --url http://localhost:8001/services/ \
  --data 'name=node1-httpd-service' \
  --data 'url=http://10.68.212.101:8080'

配置Kong服务路由对象

# url规则/node1-httpd开头的流量转发到node1-httpd-service服务
curl -i -X POST \
  --url http://localhost:8001/services/node1-httpd-service/routes \
  --data 'name=node1-httpd-route'
  --data 'paths[]=/node1-httpd'

验证访问

curl -X GET http://localhost:8000/node1-httpd

从上图中可以看到正常返回了node1部署的httpd服务的index.html页面内容。

 

Kong端口监听

注意，Kong默认在8000端口上监听来自客户端的流量请求。具体其它端口监听说明如下：

  • 8000 Kong在该端口上侦听来自客户端的传入HTTP流量，并将其转发到上游服务。

  • 8443Kong在其上侦听传入的HTTPS流量。此端口具有与端口类似的行为:8000，除了它仅期望HTTPS通信。可以通过配置文件禁用此端口。

  • 8001用于配置Kong侦听的Admin API。

  • 8444 Admin API在其上侦听HTTPS流量。

 

Kong 代理转发

 

Kong通过路由（Route）规则对象来实现代理转发的规则配置。路由规则是Kong接收外部客户请求的第一入口，基本所有的客户端请求到达Kong默认监听的8000端口后，内部通过配置的路由规则和路由规则匹配策略进行查找匹配，将客户端请求转发到匹配规则的后端服务，如果是一组upstream后端服务时，则会根据配置的负载均衡算法进行负载。如果没有找到任何匹配的路由转发规则时，则返回：{"message":"no Route matched with those values"}。

Kong除了支持http协议的代理转发外，还支持tcp、grpc等协议，这里我们重点讨论http协议的路由转发规则配置。路由规则的配置等同Nginx的location配置的概念，Kong将其包装为对象的形式对外提供Restful-API，同时丰富了路由配置的配置项。

 

Kong 路由规则配置项

http协议的情况下Kong支持以下路由转发规则配置项：

 

  • methods：例如指定GET、POST、PUT、DELETE,一般和其它规则组合使用。

  • hosts：通过hosts的方法来配置路由转发规则，通过请求头携带Host的方式来指定。

  • headers：通过http协议的header参数来配置路由转发规则。

  • paths：通过http协议的url来配置路由转发规则，支持正则表达式。

  • snis：ssl安全协议下，可以通过 Server Name Indication来配置路由转发规则。

 

路由规则匹配逻辑

 

1、可以为单个后端服务Service或upstream（负载均衡部分会介绍）配置多个路由规则，例如前面的两次curl请求。

2、单个后端服务Service或upstream支持多个配置项组合配置，例如同时指定methods、paths、headers；

3、当配置多个配置项时，客户端请求必须满足单个ruote包含的全部配置项的要求，配置项属于AND布尔逻辑。

4、每个配置项的值为数组时，表示支持配置多个，单个配置项多个配置值时只需要满足其中一个即可，配置项值属于OR布尔逻辑。

5、当同一个服务配置了多个路由规则时，Kong启动默认查找优先级策略，规则配置项最多的路由将优先匹配。

 

创建路由规则示例

# 列出服务名称为node1-httpd-service的所有路由规则
curl -i -X GET http://localhost:8001/services/node1-httpd-service/routes/
# 为名称为node1-httpd-service的服务新增路由规则route1
curl -i -X POST http://localhost:8001/services/node1-httpd-service/routes/ \
    -H 'Content-Type: application/json' \
-d '{"name":"route1","hosts":["node1.com", "node1-httpd.com"],"methods":["GET", "POST"],"paths":["/node1", "/node1-httpd"]}'
# 为名称为node1-httpd-service的服务新增路由规则route2
curl -i -X POST http://localhost:8001/services/node1-httpd-service/routes/ \
    -H 'Content-Type: application/json' \
-d '{"name":"route2","headers":{"version":["v1"]}}'
# 如果要删除某个路由规则可以执行以下请求
curl -i -X DELETE \
http://localhost:8001/services/node1-httpd-service/routes/<routename或routeid>

最佳实践建议：在Kong中任何对象基本都有name属性，在新增时强烈建议指定name，这样做好处是可以防止重复创建，如果不指定name，多次执行会创建多条配置相同但id不同的数据（个人认为这是Kong的设计缺点）。需要注意name是全局范围的，需要保证全局唯一（个人认为这也是Kong的设计缺点）。除此之外当我们通过curl删除Service服务时，Kong内部是不会自动删除该服务的其它关联对象的，删除服务对象时要手工删除该服务关联的路由规则、认证等数据。删除关联对象可以查阅官方API文档：

https://docs.konghq.com/2.0.x/admin-api/#delete-service

 

路由规则匹配示例

为了方便理解，将前面配置的两个路由规则合并在一起进行json格式化：

 

# route1
{
    "name":"route1",
    "hosts":[
        "node1.com",
        "node1-httpd.com"
    ],
    "methods":[
        "GET",
        "POST"
    ],
    "paths":[
        "/node1",
        "/node1-httpd"
    ]
}
# route2
{
    "name":"route2",
    "headers":{
        "version":[
            "v1"
        ]
    }
}
# 匹配route2路由规则
curl -i -X GET \
  --url http://localhost:8000/ \
  --header 'version: v1'
# 不匹配任何路由规则
curl -i -X GET \
  --url http://localhost:8000/ \
  --header 'version: v2'
# 匹配route1路由规则
curl -i -X GET \
  --url http://localhost:8000/node1 \
  --header 'Host: node1.com'
# 同时满足route1、route2路由规则，根据优先级这里将匹配到route2
curl -i -X GET \
  --url http://localhost:8000/node1 \
  --header 'Host: node1.com' \
  --header 'version: v2'
# 虽然匹配route2路由规则的methods、paths，但是缺少hosts所以不匹配
curl -i -X GET \
  --url http://localhost:8000/node1

路由规则其它用法

# paths正则示例，正则需要通过URL进行编码转义特殊符号
curl -i -X POST http://localhost:8001/services/node1-httpd-service/routes/ \
--data "name=route3" \
--data-urlencode "paths[]=/node1/\d+"
# paths正则指定优先级示例，正则需要通过URL进行编码转义特殊符号
curl -i -X POST http://localhost:8001/services/node1-httpd-service/routes/ \
--data "name=route4" \
--data "regex_priority=100" \
--data-urlencode "paths[]=/node1/status/\d+"
# 通过strip_path标记指定代理转发时是否去掉paths部分，true:去掉，false:不去掉，默认为true,正则时也是一样的。
curl -i -X POST http://localhost:8001/services/node1-httpd-service/routes/ \
--data "name=route5" \
--data "name=paths[]=/node1/abc" \
--data "strip_path=true"
# 示例说明
http://localhost:8000/node1/abc
strip_path为true时代理后url为：
http://node1:8080
strip_path为false时代理后url为：
http://node1:8080/node1/abc

关于更多Kong代理转发功能可以直接查阅官方文档：

https://docs.konghq.com/2.0.x/proxy/

 

Kong 负载均衡

当代理转发的后端服务是一组集群服务时，则需要配套负载均衡来实现代理转发。Kong支持外部DNS和upstream内置的环形平衡器（ring-balancer）两种方式实现负载均衡。这里我们主要介绍upstream的方式。Kong upstream负载均衡等同Nginx的upstream的概念，只是Kong将其包装为对象的方式对外提供Restful-API进行配置。每个upstream都有属于自己的环形平衡器（ring-balancer），环形平衡器实现负载均衡的原理是根据配置的负载均衡算法在初始化时一次性将1-slots（可配置，默认10000，推荐值为后端服务数量 * 100）插槽随机设置在环形上（例如环形链表），后续只需要通过简单的顺序读取环形链表（node.next）即可实现负载均衡效果，slots值和后端服务对应关系可以理解为：插槽位置 % 后端服务数量 = 本次转发的后端服务标号）。下面我们来实战一个例子。

配置node2服务对象

# 列出当前配置的所有服务
curl -i -X GET \
  --url http://localhost:8001/services/
# 添加node2节点的httpd服务
# 快速入门章节我们添加了node1节点的httpd服务
curl -i -X POST \
  --url http://localhost:8001/services/ \
  --data 'name=node2-httpd-service' \
  --data 'url=http://10.68.212.102:8080'
# 可以通过下面请求删除服务
# 删除前需要手动删除关联对象，否则提示类似 an existing 'routes' entity references this 'services' entity ....
curl -i -X DELETE  \
 --url http://localhost:8001/services/<serviceName或serviceId>
# 查询服务列表
curl -i -X GET \
  --url http://localhost:8001/services

配置upstream对象

curl -X POST http://localhost:8001/upstreams \
  --data "name=httpd-upstream" \
  # 指定负载均衡算法（默认）
  --data "algorithm=round-robin" \
  # 指定插槽数量，默认10000
  --data "slots=200"

关于创建upstream对象更多说明可以查阅官方文档：

https://docs.konghq.com/2.0.x/admin-api/#add-upstream

 

创建upstream后端目标服务

curl -X POST http://localhost:8001/upstreams/httpd-upstream/targets \
    --data "target=10.68.212.101:8080" \
    --data "weight=100"
 
curl -X POST http://localhost:8001/upstreams/httpd-upstream/targets \
    --data "target=10.68.212.102:8080" \
    --data "weight=100"


配置upstream service对象

# upstream也是需要配置为服务对象，才能于route进行关联
curl -X POST http://localhost:8001/services/ \
    --data "name=httpd-upstream-service" \
    --data "host=httpd-upstream" \
    --data "path=/"

配置upstream service对应的路由规则对象

curl -i -X POST http://localhost:8001/services/httpd-upstream-service/routes/ \
    -H 'Content-Type: application/json' \
    -d '{"name":"httpd-upstream-service-route1","hosts":["httpd-service.com"],"paths":["/httpd-service"]}'

 

验证负载均衡效果

# 循环发起100个请求，可以看到轮询输出from node1和from node2
for((a=1;a<100;a++)); do curl -i -X GET \
  --url http://localhost:8000/httpd-service \
  --header 'Host: httpd-service.com' ;done

Kong 健康检查

负载均衡技术解决的是代理后端服务高并发过载的问题，而健康检查技术解决的是代理后端服务可用性的问题。代理转发、负载均衡、健康检查通常是网关或负载均衡器的基本功能要求。Kong支持两种健康检查：主动健康检查、被动健康检查。

 

Kong主动健康检查原理

通过定期请求后端服务的某个HTTP端口，根据返回是否TCP错误，超时或HTTP状态代码来判断服务是否可用，并依据配置的信息来决定如何更新内部健康计数器。大致原理如下：

1、如果返回的状态码是配置为“健康”的状态码，它将为目标增加“成功”计数器，并清除其所有其他计数器。

2、如果连接失败，它将为目标增加“ TCP failures”计数器，并清除“ Successes”计数器。

3、如果超时，它将增加目标的“超时”计数器，并清除“成功”计数器。

4、如果返回的状态码是配置为“不健康”的状态码，它将为目标增加“ HTTP失败”计数器，并清除“成功”计数器。

5、如果“ TCP失败”，“ HTTP失败”或“超时”计数器中的任何一个达到配置的阈值，则目标将被标记为不正常。

6、Kong可以通过配置后端目标服务最少可用的“weight”比例值（threshold）来指示Kong是否返回上游服务为：503 Service Unavailable

7、运行状况检查仅对活动目标进行操作，而不会在Kong数据库中修改目标的活动状态。

8、不健康的目标不会从负载均衡器中删除，因此在使用哈希算法时（不会被忽略）不会对均衡器的布局产生任何影响。

 

Kong主动健康检查示例

# 创建upstream对象
curl -i -X POST http://localhost:8001/upstreams \
    -H 'Content-Type: application/json' \
-d '{
    # upstream名称
"name":"httpd-health-upstream",
# 轮询算法
"algorithm": "round-robin",
# 健康检查配置
"healthchecks":{
    # HTTP协议
    "type": "http",
    # 主动健康检查
        "active":{
            # 每次同时检查2个后端服务
            "concurrency":2,
            # 健康配置
            "healthy":{
                # 健康http状态配置
                "http_statuses":[200,302],
                # 对健康的后端服务检查间隔，单位：s
                "interval":10,
                # 符合http_statuses次数，则认为健康
                "successes":1
            },
            # 后端服务http端点
            "http_path":"/",
            # 超时时间，单位：s，超时后不健康计数器加1
            "timeout":10,
            # 不健康配置
            "unhealthy":{
                # 返回http_statuses为不健康的次数，达到则认为不健康
                "http_failures":2,
                # 不健康的http_status
                "http_statuses":[
                429,404,500,501,502,503,504,50
               ],
                # 对不健康的后端服务检查间隔，单位：s
                "interval":10,
                 # TCP错误的次数，达到则认为不健康
                "tcp_failures":2,
                # timeout超时的次数，达到则认为不健康
                "timeouts":2
            }
        },
        # 最少可用的“weight”百分比
        "threshold":0
    }
}'

Kong threshold说明

假设配置了的上游healthchecks.threshold=55。它有5个目标，每个目标都有weight=100，因此环形平衡器的总重量为500。当故障开始发生时，第一个目标的断路器跳闸。现在认为它不健康。这意味着在环形平衡器中，现在容量的20％不健康（500个重量中的100个重量）。该阈值仍高于55的阈值，因此其余目标将为失败目标的流量提供服务。当第二次失败发生时，另一个目标失败，另外100磅不健康而丢失。现在，环形平衡器以其容量的60％运行，但仍在配置的阈值内。如果我们假设这2个故障是由于系统过载而发生的，那么现在我们可以假设剩下的60％也将无法应付满负荷，并且很快第三个节点将发生故障，从而将正常容量减少到40％。此时，上游健康状况将小于其阈值，并且自身将被标记为不健康。一旦进入不正常状态，上游只会返回错误。这可使目标/服务从遇到的级联故障中恢复。一旦目标开始恢复并且上游的可用容量再次超过阈值，则环形平衡器的运行状况将自动更新。

Kong 被动健康检查原理

根据当前代理转发请求的响应状态来判断该服务是否可用，类似断路器。被动健康检查是根据（HTTP / HTTPS / TCP）代理转发请求时对响应情况的检查，当目标服务无响应时，被动健康检查器将其标记为不健康，环形平衡器将开始跳过此目标，因此将不再有流量路由到该目标。当解决目标服务问题并准备再次接收流量时，可以通过Admin API端点手动通知运行状况检查器要求其再次启用目标服务。

curl -i -X POST \
http://localhost:8001/upstreams/my_upstream/targets/10.68.212.102:8080/healthy

 

Kong被动健康检查示例

curl -i -X POST http://localhost:8001/upstreams \
    -H 'Content-Type: application/json' \
-d '{"name":"httpd-health-upstream",
# 轮询算法
"algorithm":"round-robin",
# 健康检查配置
"healthchecks":{
    # 被动检查配置
        "passive":{
            # 不健康检查
            "unhealthy":{
                # 代理转发过程TCP错误次数
                "http_failures":2,
                # 代理转发过程TCP错误状态次数
                "http_statuses":[
                    429,500,503
                ],
                "tcp_failures":2,
                "timeouts":2
            },
            "type":"http",
            "healthy":{
                # http_statuses响应健康状态次数
                "successes":1,
                "http_statuses":[
                    200,201,202,203,204,205,206,207,226,300,301,302,303,304,305,306,307,308
                ]
            }
        }
    }
}'

Kong 被动健康检查和主动健康检查优缺点

1、主动健康检查可以在目标再次恢复健康后自动重新启用环形平衡器中的目标服务，被动健康检查不能。

2、被动健康检查通常更快识别到不健康的目标服务，而主动健康检查识别时间为：间隔时间 * 失败次数。

3、被动健康检查不会对目标产生额外的流量，主动健康检查则相反。

4、主动健康检查要求目标服务创建一个HTTP端口，被动运行状况检查不需要这种配置。

最佳实践建议：

可以组合两种模式，例如，可以启用被动健康检查来识别不健康的目标服务，然后主动健康检查只监测不健康的目标服务。下面是配置示例：

{
"healthchecks":{
    # ........省略其它配置
        "active":{
# ........省略其它配置
            "healthy":{
                # 间隔设置为0表示不检查健康的目标服务
                "interval":0
            },
        # ........省略其它配置
            "unhealthy":{
                # 间隔设置不为0表示检查不健康的目标服务
                "interval":10
            }
        }
    }
}

Kong 服务鉴权

对于网关来说，除了支持基本的代理转发功能外，保护服务的安全也是一项基本需求。Kong通过插件的方式提供服务鉴权的支持，不同的服务鉴权可以通过不同的插件来实现。关于插件可以查阅官方提供的插件支持说明：https://docs.konghq.com/hub/。

如果没有找到满足业务需求的插件，也可以自行开发，这是Kong最大的特点，有需要时可以好好利用这点来扩展自己的业务需求。下面我们来看下Kong基本最简单的服务鉴权是如何实现的。

创建服务和路由

#创建服务
curl -i -X POST \
   --url http://localhost:8001/services/ \
   --data 'name=mockbin-service' \
   --data 'url=http://mockbin.org/request'
 
#创建路由
curl -i -X POST \
   --url http://localhost:8001/services/mockbin-service/routes \
   --data 'name=mockbin-service-route' \
   --data 'paths[]=/auth-sample'
 
# 测试路由（直接可以返回html页面）
curl -X GET http://localhost:8000/auth-sample

启用key-auth身份认证插件

# 启用服务key-auth身份认证插件
curl -i -X POST \
   --url http://localhost:8001/services/mockbin-service/plugins/ \
   # 表示启动key-auth认证插件
   --data 'name=key-auth'
# 或者启用路由key-auth身份认证插件
curl -i -X POST \
   --url http://localhost:8001/routes/mockbin-service-route/plugins/ \
   # 表示启动key-auth认证插件
   --data 'name=key-auth'
 
# 测试路由：
# 应该收到无权访问提示：{"message":"No API key found in request"}
curl -X GET http://localhost:8000/auth-sample

创建消费者对象

# 创建消费者对象
curl -d "username=lazy" http://localhost:8001/consumers/

为消费者生成apikey

# 为消费者lazy生成一个apikey
curl -X POST http://localhost:8001/consumers/lazy/key-auth -d ''

验证访问

# 测试访问，现在应该有权限访问了
curl -X GET http://localhost:8000/auth-sample \
--header 'apikey: C6tYGtoekPU4flgNTg6FJPx6bC5K6HFn'

遗留问题

下面给大伙抛出几个思考问题，这些问题有空笔者会写一篇文章进行解答：

1、Kong在实际业务中使用场景，例如如何和普通SpringBoot项目进行集成？或者如何跟Spring Cloud进行集成，能实现自动注册的功能吗？或者说Kong能否替代类似eruka这样的注册中心组件？

2、github是否有现成的Kong 界面化开源界面？

3、Kong使用PostgreSQL作为数据信息存储时，会影响高并发性能吗？

---------- 正文结束 ----------

长按扫码关注微信公众号

Java软件编程之家

 

极客编程玩家
关注
  • 0
    点赞
  • 踩
  • 4
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
Kong 微服务网关在 Kubernetes 的实践
qhh0205
08-17 1万+
本文主要介绍将 Kong 微服务网关作为 Kubernetes 集群统一入口的最佳实践，之前写过一篇文章使用 Nginx Ingress Controller 作为集群统一的流量入口：使用 Kubernetes Ingress 对外暴露服务，但是相比于 Kong Ingress Controller 来说，Kong 支持的功能更加强大，更适合微服务架构： 拥有庞大的插件生态，能轻易扩展 Kong...
kong oauth2获取令牌找不到路由
qq_42600889的博客
01-21 2558
直接访问端点 ： https://localhost:8443/oauth2/token 一直提示找不到路由：“message”: “no Route matched with those values” 需要搭配安装了oAuth2 插件的服务路由才能使用 如：我的服务路由路径为 /getArea 那么正确地址为：https://localhost:8443/getArea/oauth2/token 注意：安装 oauth2插件时 启用你需要使用的认证方式，按需要设置 ...
Node.js 健康检查和过载保护
程序员成长指北
07-04 92
大厂技术高级前端Node进阶点击上方程序员成长指北，关注公众号回复1，加入高级Node交流群设想一下，你有30个Node服务器与 "Nginx "服务器平衡。服务器的负载被平均分配，所以如果你有9000个用户，每个服务器有300个客户。把负载平均分配给每台服务器并不意味着你可以避免过载，因为你的工作对每个用户都可能不同。例如，对于user_1，你可能读取3个文件，但对于user_2，你可...
Kong api网关实战教程
最新发布
weixin_43546282的博客
05-17 1183
Kong是一款基于OpenResty(Nginx+Lua模块)编写的高可用、易扩展的，由Mashape公司开源的API Gateway项目。Kong是基于NGINX和Apache Cassandra或PostgresQL构建的，能据供易于使用的RSTTAP[来操作和配置API管理系统，所以它可以水平扩展多个Kong服务器，通过前置的负载均衡配置把请求均匀地分发到名今Senver，来应对大批量的网络请求。kong组件说明service。
系统稳定：如何监控和保护Node.js进程安全？
我乐了的博客
02-22 359
图 3 是一个最简单的层级结构图，具体每个层级设计其实是非常复杂的。图 3 监控告警平台简单流程图自动定时采集进程的指标数据；接口被调用或者访问后主动上报的信息。以上的两部分信息都会异步地发送给本地一个采集服务，落地到本地临时缓存中，然后定时地将本地临时缓存的上报信息发送给监控数据处理服务。触发告警，根据告警平台的设置，当数据落入后判断是否满足告警机制，满足则调用告警模块触发告警；查询视图，这部分就是一个前端可交互的界面，用户可以在这个平台查询监控信息；API 接口。
nginx配置转发时，提示no Route matched with those values
热门推荐
LQ0611的博客
10-20 2万+
近期，在使用nginx配置转发链接时，出现提示：no Route matched with those values。服务器这边用的时KONG网关。 问题原因： 配置带kong 服务的转发不能带 host会被后那边拦截。proxy_set_header Host $host; 这个。 ...
报错no Route matched with those values
weixin_58815788的博客
02-22 5175
konga网关配置服务没启动
KONG OPENRESTY.pdf
08-20
Kong OPENRESTY Kong 是一个开源的 API 管理层，用于保护、管理和扩展 API 和微服务。它提供了一种灵活的方式来管理 API 流量、身份验证、速率限制、分析和插件等功能。 API Gateway 模式是微服务架构中的一种常见...
kong3.4.0kong3.4.0kong3.4.0
05-07
kong3.4.0
Kong,微服务kong
11-19
Kong 的插件机制是其高可扩展性的根源，Kong 可以很方便地为路由和服务提供各种插件，网关所需要的基本特性，Kong 都如数支持
Kong入门指南.zip
10-10
Kong是开源的企业级API网关，它提供了一种在微服务架构中管理和保护API的方式。这个"Kong入门指南.zip"文件包含了一份PDF文档，帮助初学者了解并掌握Kong的基本概念、安装与配置，以及如何利用其特性来构建安全、可...
rails No route matches 错误的解决方法
01-02
有时候 rails 会出现: “No route matches”错误, 可以利用如下方法解决; 找到 config/routes.rb 文件, 打开编辑, 找到如下行: # See how all your routes lay out with “rake routes” 在这行下面添加一行, 内容如下: map.connect ”,:controller=>”index”,:action=>”index”解决no such file to load — Mysql 代码如下:> rails -d mysql myapp 您可能感兴趣的文章:
peertube-plugin-auth-oauth2:一个PeerTube服务器插件，通过OAuth 2.0提供程序添加了对外部身份验证的支持
05-11
适用于PeerTube的OAuth 2.0服务器插件 这个PeerTube服务器插件通过OAuth 2.0提供程序向PeerTube实例添加了对外部身份验证的支持。 依存关系 NodeJS> = 10.x PeerTube> = 2.2.0 OAuth 2.0提供程序要求 要正确使用此插件，OAuth 2.0提供程序必须支持机密客户端。 请参阅 。 注意：不支持OAuth2实现。 配置 此插件提供的重定向终结点可在/plugins/auth-oauth2/router/callback 。 在OAuth 2.0提供程序的callback URL或redirection URI设置中使用以下URI。 https://<your>/plugins/auth-oauth2/router/callback 注意：将<your instance hostn
kafka-testcases-ansible:Ansible手册，用于模拟您的Kafka集群的故障场景
04-16
kafka-testcases-ansible 该存储库包含可用于以下用途的Ansible剧本： 模拟节点/机架/直流故障 收集主题分区度量标准，例如当前领导者，首选领导者，ISR计数等。 启用JMX指标后，自动启动一组消费者和生产者 收集用于数据质量检查的关键客户端指标，例如，产生多少消息与消耗多少消息 要求 Ansible安装在控制节点上 在hosts.yml中指定所有代理和客户端主机名。 例如： [node-1] ip-10-0-0-218.ap-southeast-1.compute.internal [node-2] ip-10-0-0-199.ap-southeast-1.compute.internal [node-3] ip-10-0-0-221.ap-southeast-1.compute.internal [node-4] ip-10-0-0-198.ap-so
kong.tar镜像
10-30
kong.tar 镜像
难用的服务器配置Django
xiexvying的博客
03-10 828
忙毕设需要用到服务器，找学长找老师好不容易要来了一个账号使用学院的服务器，关于这个服务器使用平台是外面一个公司设计的，不稳定、容易崩、使用之前麻烦的配置这些暂且不提，重新安装基础环境、一个个包python包多麻烦，就在我部署了我的Django项目在服务器上，我想本机使用浏览器使用，这麻烦多了。这是一则自己的使用记录，怕以后自己使用的时候忘了，一般人可能不会碰到这个问题吧，对其他人可能没有帮助，就是顺便吐槽学校难用的服务器给人添这么多麻烦。后面登陆我的账号，发现有这样一个功能，端口映射，可能就是我要找的。
又肝了下微服务 API 网关“金刚”，也是蛮香的~
勇往直前的专栏
06-08 1270
“ 摘要: 原创出处 http://www.iocoder.cn/Kong/install/ 「芋道源码」欢迎转载，保留摘要，谢谢！ 1. 概述 2. 快速安装 3. Kong 控制台 4. 动态负载均衡 5. 限流限速 6. JWT 身份验证 666. 彩蛋 大家好，我是艿艿，一个很肝的小胖子~ 前端时间写了篇《国产微服务网关 APISIX，有点意思，直接开锤，换掉家门口的 Nginx》文章，有灰常多的留言让写写关于 Kong 的内
Kong系列-04-Helm安装Kong 1.3.0 with PostgreSQL and with Ingress Controller
twingao的专栏
01-22 1883
系统环境。 kubeadm version kubeadm version: &version.Info{Major:"1", Minor:"16", GitVersion:"v1.16.4", GitCommit:"224be7bdce5a9dd0c2fd0d46b83865648e2fe0ba", GitTreeState:"clean", BuildDate:"2019-12-11T...
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值