如何使用Spring Cloud Config进行分布式配置，知道一个算你牛

使用Spring Cloud Config进行分布式配置

现在是在我们的架构中引入新元素的最佳时机，这个新元素就是分布式配置服务器(Distributed Configuration Server)。与服务发现类似，这是围绕微服务的关键概念之一。在本书第4章中，已经详细讨论了如何在服务器端和客户端上准备发现。但是到目前为止，我们始终是使用放置在胖JAR文件中的属性为应用程序提供配置。这种方法有一个很大的缺点，那就是它需要重新编译和重新部署微服务的实例。Spring Boot支持另一种方法，它假定使用存储在胖JAR之外的文件系统中的显式配置。使用spring .config. location属性可以在启动期间为应用程序轻松配置它。这种方法不需要重新部署，但它也不是没有缺点。在使用大量微服务的情况下，基于放置在文件系统中的显式文件的配置管理可能真的很麻烦。另外，如果每个微服务都有很多实例，而每个实例又都有一个特定的配置。那么，采用这种方法的麻烦程度简直不敢想象。

 

无论如何，分布式配置是云原生环境中非常流行的标准。Spring Cloud Config可以为分布式系统中的外部化配置提供服务器端和客户端支持。通过该解决方案，开发人员可以在一个中心位置管理所有环境中的应用程序的外部属性。这个概念非常简单，而且易于实现。服务器只是公开HTTP和基于资源的API 接口，它们将以JSON、 YAML或properties格式返回property 文件。此外，它还会对返回的属性值执行解密和加密操作。客户端需要从服务器获取配置设置，并且如果在服务器端启用了加密之类的功能，则客户端还需要对它们进行解密处理。

 

配置数据可以存储在不同的存储库(Repository) 中。EnvironmentRepository 的默认实现将使用Git后端(Backend)。也可以设置其他版本控制系统(Version Control System,VCS)，如SVN。如果开发人员不想利用VCs系统提供的功能作为后端，则可以使用文件系统或Vault。 Vault 是一种用于管理机密的工具，它可以用于存储和控制对令牌、密码、证书和API密钥等资源的访问。

本章将要讨论的主题包括:

口由 Spring Cloud Config Server公开的HTTP API。

口服务器端的不同类型的存储库后端。

口与服务发现集成。

口使用SpringCloudBus和消息代理自动重新加载配置。

HTTPAPI资源简介

Config Server将提供HTTP API,它可以通过各种方式调用。以下端点都是可用的。

口application}/profle}[/{lbel}]: 以JSON格式返回数据; label 参数是可选的。

口/application}- {profile}.yml:返回YAML格式。

口/{abel}/application)- {profile}.yml: 这是前一个端点的变体，开发人员可以传递一个可选的label参数。

口/{application}-{profile}. properties: 返回properties 文件使用的简单键/值格式。

口 /{abel}/application)- {profile} .properties: 这是前一个端点的变体，开发人员可以传递一个可选的label参数。

从客户端的角度来看，aplication 参数是应用程序的名称，它取自spring. aplication.name或springconfig.name的属性，profile 是活动配置文件或以逗号分隔的活动配置文件列表。最后一个可用的参数label是一个可选属性，只有在使用Git作为后端存储时才很重要。它将设置Git分支的名称以进行配置，默认为master.

 

现在可以从最简单的基于文件系统后端的例子开始。默认情况下，Spring Cloud Config Server将尝试从Git存储库获取配置数据。要启用原生配置文件，开发人员应该将spring profiles active选项设置为native来启动服务器。它将搜索存储在以下位置的文件:classpath:/. casspath:/config. fle:/. fle:/config. 这意味着properties 或YAML文件也可以放在JAR文件中。为测试起见，我们已经在src/main/resourcee中创建了一个 config文件夹。我们的配置文件将存储在该位置中。现在需要回到本书第4章的示例中。在第4章中已经介绍了集群发现环境的配置，该环境中的每个客户端服务实例都在不同的区域中启动。它有3个可用区域和3个客户端实例，每个实例都在application.yml文件中有自己的配置文件。该示例的源代码在config分支中可用，以下是其链接。

https://gi thub。com/piomin/ 
sample-spring-cloud-netflix/tree/config

我们当前的任务是将该配置迁移到Spring Cloud Config Server.这里不妨自我提醒一下这个示例的属性。以下是用于客户端应用程序的第一个实例的配置文件设置。根据所选的配置文件，有一个修改实例运行的端口、默认发现服务器URL和区域名称。

---

spring：

profiles: zonel

eureka:

instance :

metadataMap :

zone: zonel

client :

serviceUrl:

defaultZone: http://localhost:8761/eureka/

server:

port:

$(PORT:80811}

在前面所介绍的示例中,为简单起见，已经将所有配置文件设置放在单个aplication.yml文件中。该文件也可以分为3个不同的文件，其名称包括配置文件application 
zonel.yml.pplicao-zone2.ymo和pplication zone3.yml.当然，这样的名称对于单个应用程序来说是唯一的，因此，如果决定将文件移动到远程配置服务器中，则应该注意它们的名称。客户端应用程序名称是从spring.aplication.name 注入的，在这种情况下，它是client-service。因此，总而言之，笔者已经在src/main/resources/config目录中创建了名为client-service-zone[n].yml的3个配置文件，其中，[m]是实例的编号。现在，当开发人员调用http:oh/o:/88/clie/ service/zone端点时，将接收到以下JISON格式的响应。

{

"name":"client-service"，

"profiles":[" zone1"]，

"label" :null ,

"version" :null,

"state"" :nul1,

"propertySources":[{

"name" :"classpath:/config/client- service-zonel . yml",

"source":{

"eureka . instance . metadataMap . zone" :"zone1",

"eureka. client. serviceUrl . defaultZone" :"http://localhost: 8761/eureka/"，

"server . port":"$ {PORT:8081}"

}

}]

}

还可以为第二个实例调用
ht:t/t/los5/888/client-servicee -zone2.properties,它将以下响应作为属性列表返回。

eureka . client. serviceUrl . defaultZone: http: //localhost: 8762/eureka/

eureka. instance。me tada taMap. zone: zone2

server .port: 8082

HTTP API端点的最后一个可用版本
htt:ol/os/8889/client/servce-zone3.yml将返回与输入文件相同的数据。以下是第三个实例的结果。

eureka :

client:

serviceUrl:

defaultZone: http: //localhost: 8763/eureka/

ins tance :

me tada taMap :

zone: zone3

server :

port: 8083

总结

因为文章包含的内容实在是太多了，就不给大家做过多的介绍了，需要这份文档来学习的小伙伴，可以转发此文关注小编。

扫码来获取就可以了！