我们知道，关于服务注册和配置，比较常见的开源产品如Nacos/Consul都是基于微服务组件级别的注册，即注册时实际上相当于微服务的JAR包部署到Docker容器中，通过在代码中加入注解进入注入配置，两者都是采用通过 Spring Cloud 原生注解@EnableDiscoveryClient开启服务注册发现功能，而且Nacos和Consul都提供基于API和DNS两种方式的服务消费。

这里其实我们可以把这类产品的功能进行拆分一下：

1、 全局配置中心，在服务注册和配置中心设置的Key/Value值可以被多个微服务模块所共享使用。

2、 服务注册中心：所有微服务组件可以直接通过Nacos或Consul平台指定服务名的方式来消费服务，无须知道后端的服务地址。并且由Nacos和Consul来实现负载均衡和健康检查。

但是Nacos和Consul这类产品，只能基于IP和端口进行微服务组件的发现，对于类似/path 端点地址(API接口)的发现是做不到的。正式基于这一点，与kong网关的结合仅仅就局限在DNS层面了。

Kong与Consul的结合，可以通过指定kong的DNS_RESOLVER来实现。

如下图，实际上我们配置的参数就是Consul运行的IP和DNS的端口，启动Consul的时候需要带上端口号：

consul agent -dev -ui -client=192.168.52.1 -dns-port=53

还需指定kong的dns_order

DNS的优先级

　　DNS解析器按顺序开始解析以下记录类型：

　　> 1. 最后一个成功的类型优先解析；

　　> 2. SRV记录

　　> 3. A记录

　　> 4. CNAME记录

这样我们基本完成了kong与Consul的集成，现在我们可以新建服务来进行测试了。新建服务时，最关键的是在DNS SRV的配置以及kong的业务服务中host的设置。如何配置可参考https://www.jianshu.com/p/2fe45645e277这篇文章，本文就不再描述。

可以看到实际上和我们之前设想的一致，kong是通过DNS来实现IP和端口的负载均衡，不能实现端点和API的自动注册发现。

那么就衍生一个问题，如果一个企业全新上微服务，如果决定使用kong网关，那么有没有必要使用类似Consul和Nacos的服务注册配置中心呢？我的回答是如果你要使用服务配置中心功能，那就需要，如果仅仅使用服务注册中心，那么是完全没有必要的，因为kong为请求多个后端服务提供了多种负载均衡方案：一种是简单的基于DNS，另一种是更加动态的环形均衡器，在不需要DNS服务器的情况下也允许服务注册。

一、基于DNS的负载均衡

当使用基于DNS的负载平衡时，后端服务的注册是在Kong之外完成，也就是像类似Nacos和Consul之类的产品，而Kong只接收来自DNS服务器的更新。如果请求的API被解析为多个IP地址，则使用包含主机名（而不是IP地址）的upstream_url定义的每个API将自动使用基于DNS的负载平衡，但是这个前提是主机名未被解析为upstream名称，或者你的localhosts文件中的名称(DNS_Order中A排在SRV前)。

二、环形均衡器

使用环形平衡器时，后台服务的添加和删除将由Kong处理，不需要进行DNS更新。KONG将扮演服务注册的角色。可以通过单个HTTP请求添加/删除节点，并可立即启动/停止接收请求流量。

可以通过配置 upstream 和 target 属性来配置环形均衡器。

upstream： 在API中把一个虚拟主机名称配置到upstream属性里。例如：一个weather.service的主机可以接收所有类似于http://weather.service/path/xxx/…的请求。

target： 后台服务所在的IP和端口号的组合。例如：192.168.11.48:8080。每一个target都附加有一个weight属性来指示获得的相对负载。

并且kong同样提供主动健康检查和被动健康检查。

业务服务配置的HOST属性，只需配置上游服务的名称即可：

配置业务服务的/personroute路由后调用，即可看到效果：

每一个上游服务都有他自己的环形均衡器。每一个upstream都可以有多个target属性，代理到虚拟主机名的请求会被均衡到每个target上。环形平衡器具有预定义的槽数，基于target的权重，每个target会分配到一定数量的槽。进来的请求将会以加权循环方式进行代理。添加或删除一个target可以通过kong的管理平台直接进行操作，这种操作非常简单省事，但是如果改变了上游服务本身，则相对繁琐，要在网关上重建负载，重新分配槽数。

如果你是想基于网关的服务集中化管理模式，一定会偏好第二种方式，但是无论哪种方式，kong网关都能完全支撑。

原文链接：https://blog.csdn.net/u012821124/article/details/122120508