如何使用Spring Cloud Consul的其他配置和发现功能，不会来学

Posted 2021-06-23 jinggege795

其他配置和发现功能

前篇文中提到“服务发现”和“使用Spring Cloud Config”进行分布式配置”中讨论了大量有关服务发现和分布式配置的内容。我们详细讨论了两种解决方案，其中的第一个解决方案是Eureka,由Netlix Oss提供，并已被Spring Cloud用于服务发现; 第二个解决方案是Spring Cloud Config项目，仅专用于分布式配置。但是，市场上有一些有趣的解决方案有效地结合了这两个功能。目前，Spring Cloud支持其中两个。

 

口Consul: 该产品由HashiCorp构建。它是一种高度可用的分布式解决方案，旨在跨动态分布式基础架构连接和配置应用程序。Consul是一个相当复杂的产品，具有多个组件，但其主要功能是在任何基础架构中发现和配置服务。

口Zookeeper: 该产品由Apache Software Foundation构建。它是一个用Java编写的分布式、分层键/值存储。它旨在维护配置信息、命名和分布式同步。与Consul相比，它更像是一种原始的键/值存储而不是现代服务发现工具。但是, Zookeeper仍然非常流行，特别是对基于Apache Sofware堆栈的解决方案更是如此。对该领域其他两种受欢迎产品的支持仍处于开发阶段。以下项目尚未添加到官方Spring Cloud版本列车中。

口Kubernetes: 这是一 个开源解决方案，旨在实现最初由Google创建的容器化应用程序的自动化部署、扩展和管理。这个工具现在很受欢迎。最近，Docker 平台已经开始支持Kubermetes。

口Eted:这是一个分布式可靠的键/值存储，用于Go中编写的分布式系统的最关键数据。它被许多公司和其他软件产品用于生产，如Kubernetes。本章将仅介绍官方支持的解决方案，即Consul和Zookeeper。Kubernetes 不仅仅是一个键/值存储或服务注册表，本书将在第14章“Docker支持”中详细讨论它。

使用Spring Cloud Consul

Spring Cloud Consul项目可以通过自动配置为Consul和Spring Boot应用程序提供集成。通过使用众所周知的Spring Framework注解样式，开发人员可以在基于微服务的环境中启用和配置常见模式。这些模式包括:使用Consul代理进行服务发现、使用Consul键/值存储进行分布式配置、使用Spring Cloud Bus进行分布式事件以及使用Consul Events等。该项目还支持基于Netflix Ribbon的客户端负载均衡器和基于Nettlix Zuul的API网关。在开始讨论这些功能之前，必须先运行并配置Consul代理。

运行 Consul代理

我们将从在本地计算机上启动Consul代理的最简单方法开始。可以使用Docker容器轻松设置独立开发模式。以下命令将从Docker Hub上可用的官方Hashicorp 镜像启动Consul容器。

docker run -d --name consul -p 8500:8500 consul

在启动之后，Consul的地址为htp://9/168.99.100.85000 它公开了RESTful HTTP API,这也是它的主接口。所有API路由都以/VI/为前缀。当然，它不需要直接使用API。有一些编程库可以更方便地使用API,其中一个是consul-api,客户端用Java编写，内部也由Spring Cloud Consul使用。Consul 提供的Web用户界面仪表板在与HTTP API相同的地址下可用，但在不同的上下文路径/ui/上。它允许查看所有已注册的服务和节点，查看所有运行状况检查及其当前状态，以及读取和设置键/值数据。

如前文所述，我们将使用Consul的3个不同功能一代理、事件和键值存储。它们的对应端点分别是/agent. /event 和Av。 最有趣的代理端点是与服务注册相关的端点。表10.1是这些代理端点的列表。

 

/kv端点专用于管理简单的键/值存储，这对于存储服务配置或其他元数据特别有用。值得注意的是，每个数据中心都有自己的KV存储，因此，要在多个节点之间共享它，开发人员应该配置Consul复制守护进程。表10.2是管理键/值存储的3个端点的列表。

 

Spring Cloud使用Consul Events 提供动态配置重新加载。有两种简单的API方法。第一种是PUT /event/fire/:name,它将触发一个新事件。第二种是GET /event/list,它将返回一个事件列表，并且可以按名称、标记、节点或服务名称进行过滤。

在客户端集成

要在项目中激活Consul服务发现，应该在依赖项中包含spring 
cloud-tarter-consul-discovery启动器。如果要使用Consul 启用分布式配置，只需包含spring-cloud-starter-consul-confg.在某些情况下，开发人员可能会在客户端应用程序中使用这两个功能，这样的话就应该声明对spring cloud. starter consu-al工件的依赖。

<dependency>

<groupId>org. spr ingframework. cloud</groupId>

<artifactId>spring-cloud-starter-consul-all</arti factId>

</dependency>

默认情况下，Consul代理应在地址localhost:8500下可用。如果开发人员的应用程序有所不同，则应在application.yml或botstrap.yml文件中提供相应的地址。

spring:

cloud:

consul :

host: 192.168.99. 100

port: 18500

服务发现

通过使用通用Spring Cloud @EnableDiscoveryClient 注解main类，可以为应用程序启用使用Consul的服务发现。有关详细设置，可以参考之前文章提到的“服务发现"，因为它与Eureka相比没有区别，其默认服务名称也取自$ (spring application.name}属性。使用Consul作为发现服务器的示例微服务可以在GitHub存储库的
htptp:githubcom/piomin/sample- spring cloud-consulgit.上获得。该系统的架构与前面章节中的示例相同。它有4个微服务: order-service 服务、product-service 服务、customer-service 服务和account-service服务，API网关在gateway-service模块中实现。对于服务间通信，则将Feign客户端与Ribbon负载均衡器一起使用。

@SpringBootApplication

@EnableDiscoveryClient

@EnableFeignClients

public class CustomerApplication {

 

public static void main(stringl] args)

new

SpringApplicationBuilder (CustomerApplication.class).web(true).run(args) ;

}

}

默认情况下，Spring Boot 应用程序在Consul 中注册，其实例ID是通过从属性spring aplication.name. springprofiles active和server.port获取的值连接在一起而生成的。在大多数情况下，确保ID是唯一的就足够了，但如果需要自定义模式，则可以使用
spring.cloud.consul.discovery.instanceld 属性轻松设置。

spring:

cloud:

consul:

discovery:

instanceId:

$ (spring .application. name}:$ (vcap.application. instance id:$ (spring . appicat

ion.instance id:${random.valuelll} } }

在启动所有示例微服务之后，即可查看Consul用户界面仪表板。此时应该看到注册了4种不同的服务，如下面的屏幕截图10.1所示。

或者，开发人员也可以使用RESTful HTTP API端点GET /v1/agent/services查看已注册服务的列表。以下是JSON响应的片段。

"customer-service-zone1-8092":1

ID": "customer-service-zone1-8092",

"service": "customer-service",

"Tags": 1,

"Address"; "minkowp-l.p4.org","Port": 8092，

"EnableTagOverride": false,

"CreateIndex": 0,

"ModifyIndex": 0

)，

"order- service- zone1-8090”: {

"ID": "order-service-zone1-8090"，

"Service": "order-service" ，

"Tags": []，

"Address"; "minkowp-1.p4.org",

"Port": 8090，

"EnableTagOverride"; false,

"CreateIndex": 0,

"ModifyIndex": 0

}

 

现在，可以使用pl.piomin.services. order.rderCotollrTest JUnit 测试类通过向order-service服务发送一些测试请求来轻松测试整个系统。一切都应该工作得很好，和Eurcka的发现一样。

1.运行状况检查

Consul可以通过调用/health端点来检查每个已注册实例的运行状况。如果不希望在类路径中提供Spring Boot Actuator库，或者如果开发人员的服务存在一些问题，那么它将在Web仪表板上显示，如图10.2 所示。

如果运行状况检查端点由于任何原因在不同的上下文路径下可用，则可以使用spring cloud consuldiscovery healthCheckPath属性覆盖该路径。还可以通过使用模式定义halthCheckInterval来更改状态刷新间隔，例如，10s 表示10秒，2m 表示2分钟。

spring:

cloud:

consul :

discovery:

healthCheckPath: admin/health

healthCheckInterval: 20s

 

2.区域

本书在第4章“服务发现”中已经详细介绍了可用于Eureka发现的分区机制。当主机放置在不同的位置，而开发人员又希望在同一区域中注册的实例之间进行通信时，它非常有用。虽然Spring Cloud Consul的官方说明文档(tp:/cloud .spring 
io/spring-cloud-static/spring-cloud-consul/1.2.3.RELEASE/single/spring-cloud-consul.html)对这样的解决方案未置一词，但幸运的是这并不意味着它无法实现。Spring Cloud 可以提供基于Consul标记的分区机制。开发人员可以使用spring cloud. consul.discovery.instanceZone属性配置应用程序的默认区域。它使用传递的值设置spring cloud.consu.discovery. defaultZoneMetadataName属性中配置的标记。默认元数据标签的名称为zone。

现在继续讨论示例应用程序。我们已经使用两个配置文件(zonel 和zone2)扩展了所有配置文件。以下是order -service服务的botstrap.yml文件。

spring:

application:

name: order-service

cloud:

consul :

host: 192.168. 99.100

port: 8500spring:

profiles: zone1

cloud:

consul ;

discovery:

instanceZone: zone1

server:

port: S{PORT:8090}

---

spring:

profiles: zone2

cloud:

consul :

discovery:

instanceZone: zone2

server :

port: $IPORT:90901

在两个不同区域中注册的每个微服务都有两个运行实例。使用mvncleaninstall命令构建整个项目后，应该启动具有活动配置文件zonel或zone2的Spring Boot应用程序，如java jar -spring profils active-zonel targe/order- service-1.0-SNAPSHOTjar.开发人员可以在NODES(节点)中看到使用区域标记的已注册实例的完整列表。如图10.3所示为此时的Consul仪表板视图。

 

本架构中的最后一个元素是基于Zuul的API网关。我们还将在不同的区域中运行两个gateway-service服务实例。我们希望在Consul中省略注册，并且只允许获取配置, Ribbon客户端在执行负载均衡时使用该配置。以下是gateway -service服务的bootstrap.yml文件的片段。它已经通过将spring cloud. consu.discovery .register和spring cloud consul 
discovery.registertHealthCheck属性设置为false 禁用了注册。

---

spring:

profiles: zone1

cloud:

consul:

discovery:

instanceZone: zonel

register: false

registerHealthCheck: false

server:

port: ${PORT:8080}

---

spring:

profiles: zone2

cloud:

consul:

discovery:

instanceZone: zone2

register: false

registerHealthCheck: false

server:

port: ${PORT:9080}

3.客户端自定义设置

可以通过配置文件中的属性自定义Spring Cloud Consul客户端。其中一些设置已在本章前面的小节中介绍过。其他有用的设置已在表10.3 中列出。所有这些都以
spring.cloud.consul.discovery为前缀。

 

 

4.以集群模式运行

到目前为止，我们通常会启动一个单独的Consul实例。但这只是开发模式中的合适解决方案，对于生产模式来说是不够的。在生产模式中，我们会希望拥有一个可扩展的生产级服务发现基础架构，其中包含一些在集群内部协同工作的节点。Consul 提供了对集群的支持，它将在成员之问通信时使用Gossip协议，在选举领导时使用Raft共识协议。在此我们不想介绍该过程的细节，但是应该说明一些关于Consul架构的基础知识。

我们已经讨论过Consul代理，但它究竟是什么，以及它的作用是什么并没有得到解释。代理是Consul集群的每个成员长期运行的守护程序。它可以在客户端或服务器模式下运行。所有代理都负责在全局范围内运行检查并保持在不同节点和同步中注册的服务。

本节的主要目标是使用Docker镜像设置和配置Consul集群。首先,我们将启动容器,它充当集群的领导者。当前使用的Docker命令与独立的Consul服务器只有一个区别。我们设置了环境变量CONSUL. _BIND_ INTERFACE-eth0， 以便将集群代理的网络地址从127.0.0.1更改为可用于其他成员容器的网络地址。笔者的Consul服务器现在在内部地址172.17.0.2.上运行。要查看你的地址(它应该是相同的)，可以运行命令docker logs consul.容器启动后将记录适当的信息。

docker run -d --name consul-1 -P 8500:8500一白CONSUL BIND_ INTERFACE eth0

consul

了解该地址非常重要，因为现在我们必须将它作为集群连接参数传递给每个成员容器启动命令。我们还通过将0.0.0.0设置为客户端地址将其绑定到所有接口。现在，可以使用-p参数轻松地在客户端代理API之外公开客户端代理API。

docker run -d --name consul-2 -P 8501:8500 consul agent -server

client=0.0.0.0 -join=172.17.0.2

docker run -d --name consul-3 -P 8502:8500 consul agent -server

client=0.0.0.0 -join=172.17.0.2

在使用Consul代理运行两个容器之后，可以通过在领导者(Leader) 的容器上执行如图10.4所示的命令来检查集群成员的完整列表。

 

Consul服务器代理在8500端口上公开，而成员代理在端口8501和8502上公开。即使微服务实例将自身注册到成员代理，集群的所有成员也可以看到它，如图10.5 所示。

 

开发人员可以通过更改配置属性轻松更改SpringBoot应用程序的默认Consul代理地址。

spring:

application:

name: customer-service

cloud:

consul :

host: 192.168.99.100

port: 8501

分布式配置

对于在类路径中使用Spring Cloud Consul Config库的应用程序来说，它们将在引导阶段从Consul键/值存储中获取配置。也就是说，默认情况下，会存储在/config文件夹中。当开发人员要创建一个新键值时，必须设置-个文件夹路径。该路径将用于标识键值并将其分配给应用程序。Spring Cloud Config会尝试根据应用程序名称和活动配置文件解析存储在文件夹中的属性。假设我们已经在bosrp.ym文件中将spring apcationamnn属性设置为order-service,并将sprigprofiles. active运行参数设置为zonel," 那么它会尝试按以下顺序查找属性源: config/order-service. zonel/、 config/order-service/. config/ pplication、zone1/、configapplication/. 对于所有没有与服务相关的属性源的应用程序来说，包含前缀confgapplication的所有文件夹就是它们的默认配置。

1.管理Consul中的属性

向Consul添加单个键值的最便捷方式是通过其Web仪表板。另一种方法是使用/kvHTTP端点，这在本章开头已经介绍过。在使用Web控制台时，必须转到KEY/VALUE(键/值)视图，然后就可以查看所有当前存在的键和值，并通过以任何格式提供其完整路径和值来创建新的键，如图10.6所示。

 

每个键值都可以更新或删除，如图10.7所示。

 

要访问使用Consul中存储的属性源的示例应用程序，应该切换到与上一个示例相同的存储库中的分支配置。我们已经为每个微服务创建了键值server.port 和spring cloud.consul. discovery instanceZone,而不是在application.yml或bootstrap.yml文件中定义它。

2.客户端定制

可以使用以下属性自定义Consul Config 客户端，这些属性以
spring.cloud.consul.config为前缀。

口enabled: 通过将此属性设置为false,可以禁用Consul Config。如果已经包含了
spring-cloud-starter-consulall,那么这将非常有用，因为后者会启用发现和分布式配置。

口fail-fast:设置是否在配置查找期间抛出异常或在连接失败时抛出日志警告。将其设置为true允许应用程序正常继续启动。

口prefix: 这将设置所有配置值的基本文件夹，默认情况下为/config.

口defaultContext: 这将设置所有没有特定配置的应用程序使用的文件夹名称，默认情况下为/application。例如，如果将其覆盖到app,则应在/config/apps文件夹中搜索属性。

口profileSeparator: 默认情况下，使用逗号将应用程序名称分隔为配置文件。该属性允许覆盖该分隔符的值。例如，如果将其设置为::。则应创建文件夹/onfgroedr-reiece:zone1/。.以下就是一个示例。

spring:

cloud:

consul:

config:

enabled: true

prefix: props

de faultContext: app

profileSeparator: “ :: ”

有时，开发人员会希望存储以YAML或Properties格式创建的一堆属性，而不是单个键/值对。在这种情况下，应该将spring cloud consul.config.format属性设置为YAML或PROPERTIES。然后，应用程序将查找位于具有数据键的文件夹内的配置属性，如configorder-service、zone 1/data、config/order-service/data、 configapplication、 zone1/data 或cofigapplication/data.可以使用spring cloud. consul.config data-key属性更改默认数据键。

3.观察配置更改

此前讨论的示例将在应用程序启动时加载配置。如果开发人员希望重新加载该配置，则应将HTTP POST发送到/refresh 端点。为了检查这样的刷新对示例应用程序的影响方式，我们修改了负贵创建一些测试数据的应用程序代码片段。到目前为止，它已作为存储库@Bean提供，其中包含一些硬编码的内存中的对象。来看以下代码。

@Bean

CustomerRepository repository() {

CustomerRepository repository new CustomerRepository0 ;

repository. add (new Customer ("John Scott", Cus tomerType .NEW)) :

repository. add (new Customer ("Adam Smith", CustomerType . REGULAR));

repository. add (new Customer ("Jacob Ryan", CustomerType .VIP)):

return repository;

}

我们的目标是使用Consul键/值功能将上述代码移动到配置存储。要完成此目标，必须为每个对象创建3个键，其名称分别为id、name 和type.配置则是从具有repository前缀的属性加载的。

@RefreshScope

@Repository

@ConfigurationProperties (prefix - "repository")

publie class Custome rRepository

private List<customer> customers = new ArrayL1st<>( ;

public List<Customer> getCustomers() (

return customers;

}

public void setCustomers (List<Customer>. customers) {

this.customers = customers;

}

// ...

}

下一步是使用ConsulWeb仪表板为每个服务定义适当的键值。如图10.8所示的是包含Customer对象的列表的示例配置。该列表将在应用程序启动时初始化。开发人 员可以更改每个属性的值。由于Consul能够查看键值前缀，更新事件将自动发送到应用程序。如果存在新配置数据，则刷新事件将发布到队列。所有队列和交换消息都是在Spring Cloud Bus的应用程序启动时创建的，它作为spring cloud-sarter consulall的依赖项包含在项目中。如果应用程序接收到此类事件，那么它会在日志中打印以下信息.

Refresh keys changed: [ reposi tory. customers [1]。name ]

觉得文章不错的朋友可以转发此文关注小编，有需要的可以扫码下方获取；