предисловие
Ранее мы узнали, как использовать Nacos для управления конфигурацией в Spring Boot, что в целом относительно просто.
Чтобы более удобно использовать Nacos в Spring Cloud, сегодня я расскажу, как использовать Nacos в Spring Cloud просто, быстро и удобно.
использовать
В проект необходимо добавить зависимость Maven от spring-cloud-starter-alibaba-nacos-config.
<dependencyManagement>
<dependencies>
<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-dependencies</artifactId>
<version>Greenwich.SR2</version>
<type>pom</type>
<scope>import</scope>
</dependency>
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-parent</artifactId>
<version>2.1.6.RELEASE</version>
<type>pom</type>
<scope>import</scope>
</dependency>
</dependencies>
</dependencyManagement>
<dependencies>
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-web</artifactId>
</dependency>
<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-starter-alibaba-nacos-config</artifactId>
<version>0.9.0.RELEASE</version>
</dependency>
</dependencies>
Пожалуйста, обратитесь к следующим спецификациям для выбора версии:
Поскольку Spring Boot 1 и Spring Boot 2 имеют большие изменения в интерфейсе и аннотациях модуля Actuator, а spring-cloud-commons также претерпел серьезные изменения с версии 1.xx до версии 2.0.0, мы принимаем версию SpringBoot. версия с тем же номером:
Версия 1.5.x для Spring Boot 1.5.x Версия 2.0.x для Spring Boot 2.0.x Версия 2.1.x для Spring Boot 2.1.x
Настройте информацию Nacos в bootstrap.properties, помните, что bootstrap.properties — это не application.properties, вы можете проверить это сами.
# 应用名称，用于配置文件命名
spring.application.name=example
# Nacos server 的地址
spring.cloud.nacos.config.server-addr=127.0.0.1:8848
# 配置内容的数据格式
spring.cloud.nacos.config.file-extension=properties
# 指定对应的环境
spring.profiles.active=test
В Nacos Spring Cloud полный формат dataId выглядит следующим образом:
${prefix}-${spring.profile.active}.${file-extension}
Префикс по умолчанию имеет значение spring.application.name, и его также можно настроить с помощью элемента конфигурации spring.cloud.nacos.config.prefix.
Затем создаем конфигурацию в фоновом режиме Nacos, dataId — example-test.properties
useLocalCache=false
Создайте еще один пример-dev.properties
useLocalCache=true
Тестовый код:
@RestController
@RequestMapping("/config")
@RefreshScope
public class ConfigController {
@Value("${useLocalCache:false}")
private boolean useLocalCache;
@RequestMapping("/get")
public boolean get() {
return useLocalCache;
}
}
Если изменения конфигурации необходимо обновить, не забудьте добавить аннотацию @RefreshScope. Конфигурация загрузки соответствующей среды загружается согласно значению spring.profiles.active=test, когда мы указываем test, значение useLocalCache равно false, а когда spring.profiles.active=dev значение useLocalCache равно true .
Удобство заключается в том, что нет необходимости указывать пространство имен, чтобы различать среду при запуске, но оно интегрировано с spring.profiles.active в Spring Boot.
Использование нескольких идентификаторов данных
Если нам нужно загрузить несколько файлов конфигурации, мы можем использовать ext-config для настройки
spring.cloud.nacos.config.ext-config[0].data-id=app.properties
spring.cloud.nacos.config.ext-config[0].group=multi-data-ids
spring.cloud.nacos.config.ext-config[0].refresh=true
spring.cloud.nacos.config.ext-config[1].data-id=user.properties
spring.cloud.nacos.config.ext-config[1].group=multi-data-ids
spring.cloud.nacos.config.ext-config[1].refresh=true
конечная точка nacos-config
Spring-cloud-starter-alibaba-nacos-config имеет встроенную конечную точку nacos-config. Вы можете просмотреть информацию, связанную с конфигурацией, через конечную точку nacos-config. Исходный код находится по адресу org.springframework.cloud.alibaba.nacos.endpoint. .NacosConfigEndpoint
{
"NacosConfigProperties": {
"serverAddr": "127.0.0.1:8848",
"encode": null,
"group": "DEFAULT_GROUP",
"prefix": null,
"fileExtension": "properties",
"timeout": 3000,
"endpoint": null,
"namespace": null,
"accessKey": null,
"secretKey": null,
"contextPath": null,
"clusterName": null,
"name": null,
"sharedDataids": null,
"refreshableDataids": null,
"extConfig": [
{
"dataId": "example.properties",
"group": "DEFAULT_GROUP",
"refresh": true
},
{
"dataId": "student.properties",
"group": "DEFAULT_GROUP",
"refresh": true
}
]
},
"RefreshHistory": [],
"Sources": [
{
"lastSynced": "2019-08-18 13:07:42",
"dataId": "student.properties"
},
{
"lastSynced": "2019-08-18 13:07:42",
"dataId": "null-test.properties"
},
{
"lastSynced": "2019-08-18 13:07:42",
"dataId": "null.properties"
},
{
"lastSynced": "2019-08-18 13:07:42",
"dataId": "example.properties"
}
]
}
NacosConfigHealthIndicator
spring-cloud-starter-alibaba-nacos-config имеет встроенную реализацию проверки состояния работоспособности Nacos. Когда Nacos дает сбой, он может вовремя предоставить обратную связь через привод/здоровье. Исходный код находится на org.springframework.cloud.alibaba .nacos.endpoint.NacosConfigHealthIndicator
"status": "UP",
"details": {
"diskSpace": {
"status": "UP",
"details": {
"total": 249795969024,
"free": 12436131840,
"threshold": 10485760
}
},
"nacosConfig": {
"status": "UP",
"details": {
"dataId: 'student.properties', group: 'DEFAULT_GROUP'": "config is empty",
"dataId: 'null-test.properties', group: 'DEFAULT_GROUP'": "config is empty",
"dataId: 'null.properties', group: 'DEFAULT_GROUP'": "config is empty",
"dataId: 'example.properties', group: 'DEFAULT_GROUP'": "config is empty",
"dataIds": [
"student.properties",
"null-test.properties",
"null.properties",
"example.properties"
]
}
},
"refreshScope": {
"status": "UP"
}
}
}
В настоящее время, когда я смотрю на это сам, я чувствую, что в этой области есть небольшая проблема.Явление заключается в том, что после того, как все службы Nacos остановлены, состояние здоровья Nacos все еще ВВЕРХ, а не ВНИЗ, как мы ожидали.
Я посмотрел исходный код и нашел причину.Информация UP устанавливается в последней строке.Даже если DOWN установлен в начале, он в конечном итоге станет UP.Я не знаю, является ли это ошибкой, ха-ха. . .
@Override
protected void doHealthCheck(Health.Builder builder) throws Exception {
for (String dataId : dataIds) {
try {
String config = configService.getConfig(dataId,
nacosConfigProperties.getGroup(),
nacosConfigProperties.getTimeout());
if (StringUtils.isEmpty(config)) {
builder.down().withDetail(String.format("dataId: '%s', group: '%s'",
dataId, nacosConfigProperties.getGroup()), "config is empty");
}
}
catch (Exception e) {
builder.down().withDetail(String.format("dataId: '%s', group: '%s'",
dataId, nacosConfigProperties.getGroup()), e.getMessage());
}
}
// 问题出在这边
builder.up().withDetail("dataIds", dataIds);
}
Я думаю, что в последнюю строку следует добавить суждение: если раньше было установлено значение DOWN, здесь не следует устанавливать значение UP.
if( builder.build().getStatus() != Status.DOWN ) {
builder.up().withDetail("dataIds", dataIds);
}
После модификации здесь все еще есть проблема, то есть у Nacos фактически есть информация о конфигурации кеша локально.Конечно, я не читал код для этого времени истечения, и я не знаю, как долго он истечет. То есть, когда все службы Nacos приостановлены, статус работоспособности не может быть установлен вовремя на DOWN, потому что при configService.getConfig конфигурация сначала будет получена из локального кеша, поэтому конфигурация может быть получена. , в этом случае проверка работоспособности недействительна.
Я лично считаю, что поскольку проверка работоспособности должна быть выполнена, то не следуйте этой логике.Самый простой способ - каждый раз читать напрямую из службы Nacos, и вы можете установить его в DOWN, когда чтение ненормально.Это то, что просто.
Не говоря уже о том, чтобы зайти на Github, чтобы поднять вопросы и спросить у больших парней. …