Предисловие

Недавно что-то пошло не так при использовании конечной точки проверки работоспособности, предоставленной Spring-Boot-актуатором в проекте Webflux. Поэтому я провел всесторонний обзор структуры проекта и принципа работы Spring-Boot-actuator. Причина, по которой указано в названии. Работа со здоровьем Принцип заключается в том, что Spring-boot-actuator - это действительно большой проект, помимо предоставления конечных точек работоспособности, он также включает в себя env, log, dump и многие другие функции. Ниже мы сосредоточимся на части проверки работоспособности и ее изучении. это подробно.

Разделение функций привода и интеграция

Обычно при использовании привода с пружинной загрузкой используется следующий стартер.

<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-actuator</artifactId>
</dependency>

Этот стартер будет содержать две зависимости, одна из которых — реализация функции Spring-Boot-Actuator.

    <dependency>
      <groupId>org.springframework.boot</groupId>
      <artifactId>spring-boot-actuator</artifactId>
      <version>2.1.0.RELEASE</version>
    </dependency>

Существует также конфигурация конфигурации, интегрированная с Spring Boot, а также зависимости от автоматической сборки Bean, а именно:

    <dependency>
      <groupId>org.springframework.boot</groupId>
      <artifactId>spring-boot-actuator-autoconfigure</artifactId>
      <version>2.1.0.RELEASE</version>
    </dependency>

автоматическая загрузка привода

Найдите зависимость Spring-boot-actuator-autoconfigure, найдите ее в пакете org.springframework.boot.actuate.autoconfigure.health и имейте следующую структуру:

Класс автоматической настройки HealthEndpointAutoConfiguration.java, указанный стрелкой, является входом при запуске работоспособности в приводе. Исходный код выглядит следующим образом:

@Configuration
@EnableConfigurationProperties({ HealthEndpointProperties.class,
      HealthIndicatorProperties.class })
@AutoConfigureAfter(HealthIndicatorAutoConfiguration.class)
@Import({ HealthEndpointConfiguration.class,
      HealthEndpointWebExtensionConfiguration.class })
public class HealthEndpointAutoConfiguration {

}

Чтобы прочитать приведенный выше код, вам необходимо понять механизм автоматической загрузки Spring. Вот краткое объяснение. Во-первых, @Configuration включает функцию настройки @EnableConfigurationProperties, позволяющую настраивать свойства конечных точек проверки работоспособности и индикаторов проверки работоспособности. определяет автоматическую сборку проверки работоспособности. После HealthIndicatorAutoConfiguration @Import содержит два класса автозагрузки. Три основных класса конфигурации подробно описаны ниже:

Конфигурация индикатора проверки работоспособности (HEALTHINDICATORAUTOCONFIGURATION)

Индикаторы проверки работоспособности определяют, какие компоненты необходимо обнаружить. К общим индикаторам относятся источник данных JDBC (DataSourceHealthIndicator.java), индикатор работоспособности диска (DiskSpaceHealthIndicator.java) и т. д. Каждый индикатор соответствует автоматически собираемому классу, который инициализируется в соответствии с условиями инициализации Bean. Например, условия инициализации источника данных JDBC следующие:

Когда контекст Spring содержит реализацию DataSource, включается индикатор проверки работоспособности JDBC. Эти индикаторы в конечном итоге будут собраны в регистр индикаторов DefaultHealthIndicatorRegistry.java.

Конфигурация индикатора проверки работоспособности завершает инициализацию регистра индикатора. Код выглядит следующим образом:

	@Bean
	@ConditionalOnMissingBean(HealthIndicatorRegistry.class)
	public HealthIndicatorRegistry healthIndicatorRegistry(
			ApplicationContext applicationContext) {
		return HealthIndicatorRegistryBeans.get(applicationContext);
	}
    ——————————————————————————————————————————————————————————————————————————————————————————————
	public static HealthIndicatorRegistry get(ApplicationContext applicationContext) {
		Map<String, HealthIndicator> indicators = new LinkedHashMap<>();
		indicators.putAll(applicationContext.getBeansOfType(HealthIndicator.class));
		if (ClassUtils.isPresent("reactor.core.publisher.Flux", null)) {
			new ReactiveHealthIndicators().get(applicationContext)
					.forEach(indicators::putIfAbsent);
		}
		HealthIndicatorRegistryFactory factory = new HealthIndicatorRegistryFactory();
		return factory.createHealthIndicatorRegistry(indicators);
	}

Как видите, просто перейдите в контекст приложения Spring ApplicationContext, чтобы найти экземпляр типа Bean HealthIndicator.class. Если в проекте используется webFlux, будут зарегистрированы дополнительные индикаторы, связанные с Reactive.

Конфигурация конечной точки проверки работоспособности

Конфигурация конечной точки относительно проста: необходимо создать экземпляр HealthEndpoint.java. В конечном итоге все функциональные входы проверки работоспособности будут абстрагированы и объединены в этот экземпляр. Код конфигурации выглядит следующим образом:

@Configuration
@ConditionalOnSingleCandidate(HealthIndicatorRegistry.class)
class HealthEndpointConfiguration {

	@Bean
	@ConditionalOnMissingBean
	@ConditionalOnEnabledEndpoint
	public HealthEndpoint healthEndpoint(HealthAggregator healthAggregator,
			HealthIndicatorRegistry registry) {
		return new HealthEndpoint(
				new CompositeHealthIndicator(healthAggregator, registry));
	}
}

Как видите, необходимым условием является наличие одноэлементного экземпляра регистра индикатора работоспособности.

реализация проверки здоровья

В Spring-boot-actuator аннотация @Endpoint определена для объявления конечной точки исполнительного механизма. То же самое относится и к конечной точке работоспособности. Интерфейс /actuator/health предоставляется через @Endpoint(id="health"). И три метода отображаются через аннотацию @ReadOperation следующим образом:

• Health health()

При доступе к http://127.0.0.1:8080/actuator/health этот метод будет выполнен, будут вызваны все реализации индикатора работоспособности и возвращены результаты.

• Health healthForComponent(@Selector String component)

Этот метод будет выполнен при доступе к http://127.0.0.1:8080/actuator/health/${comComponent}. Соответствующий индикатор будет найден на основе значения компонента, и возвращенный результат будет проверен.

• Health healthForComponentInstance(@Selector String component, @Selector String instance)

Этот метод будет выполнен при доступе к http://127.0.0.1:8080/actuator/health/${comComponent}/${instance}. Соответствующие индикаторы будут найдены на основе значений компонента и экземпляра, а также возвращенные результаты будут проверены. Где компонент — это имя компонента, а экземпляр — значение имени экземпляра компонента. Имя компонента указывается аннотацией @ConditionalOnEnabledHealthIndicator в классе конфигурации компонента исполнительного механизма. В настоящее время включены следующие компоненты индикатора:

Давайте посмотрим на индикатор Redis RedisHealthIndicator.java, чтобы увидеть, как окончательный индикатор определяет работоспособность компонента. Реализация следующая:

public class RedisHealthIndicator extends AbstractHealthIndicator {

	static final String VERSION = "version";

	static final String REDIS_VERSION = "redis_version";

	private final RedisConnectionFactory redisConnectionFactory;

	public RedisHealthIndicator(RedisConnectionFactory connectionFactory) {
		super("Redis health check failed");
		Assert.notNull(connectionFactory, "ConnectionFactory must not be null");
		this.redisConnectionFactory = connectionFactory;
	}

	@Override
	protected void doHealthCheck(Health.Builder builder) throws Exception {
		RedisConnection connection = RedisConnectionUtils
				.getConnection(this.redisConnectionFactory);
		try {
			if (connection instanceof RedisClusterConnection) {
				ClusterInfo clusterInfo = ((RedisClusterConnection) connection)
						.clusterGetClusterInfo();
				builder.up().withDetail("cluster_size", clusterInfo.getClusterSize())
						.withDetail("slots_up", clusterInfo.getSlotsOk())
						.withDetail("slots_fail", clusterInfo.getSlotsFail());
			}
			else {
				Properties info = connection.info();
				builder.up().withDetail(VERSION, info.getProperty(REDIS_VERSION));
			}
		}
		finally {
			RedisConnectionUtils.releaseConnection(connection,
					this.redisConnectionFactory);
		}
	}

}

Видно, что сначала определяется тип соединения, будь то режим кластера или автономный режим, а затем отдельно вызывается команда info для получения информации о версии Redis.

Пользовательский индикатор проверки работоспособности

Зная это, можно легко настроить проверку работоспособности компонента. Сначала пользовательский индикатор наследует класс AbstractHealthIndicator, реализует метод doHealthCheck, а затем определяет класс конфигурации пользовательского индикатора и наследует CompositeHealthIndicatorConfiguration. Псевдокод выглядит следующим образом:

@ConditionalOnEnabledHealthIndicator("myDb")
@Configuration
public class MyHealthIndicatorAutoConfiguration extends CompositeHealthIndicatorConfiguration<DataSourceHealthIndicator,DataSource> {

    @Bean
    @ConditionalOnMissingBean(name = "myDbHealthIndicator")
    public HealthIndicator dbHealthIndicator() {
        return new MyHealthIndicator();
    }
}
class MyHealthIndicator extends AbstractHealthIndicator{
    @Override
    protected void doHealthCheck(Health.Builder builder) {
        //Здесь определяем логику построения здоровья
        builder.up();
    }
}

здоровье Другие сведения об использовании

В дополнение к упомянутой выше проверке работоспособности можно указать не только конечную точку /actuator/health, но и проверку компонента, она также предоставляет множество функций, которыми можно управлять посредством конфигурации, например, переключение индикатора, когда отображать данные проверки здоровья и т. д., а именно:

management.endpoints.web.base-path=/actuator
management.endpoint.health.enabled=true
management.endpoint.health.show-details=never
management.endpoint.health.roles=admin
management.health.db.enabled=true

Вывод в конце статьи

Используйте каждый компонент с пользой,Принцип не упускать из виду никаких деталей реализации,Я проанализировал принцип реализации работоспособности в Spring-Boot-Actuator. Но актуатор действительно большой парень,Только индикатор проверки работоспособности реализован 18 раз.,В частности, следующее,для здоровья,При выполнении индикатора проверки работоспособности,ОтличитwebиwebFlux。Основная причина в том, чтоwebFluxпод окружающей средой,Связанные компоненты также будут иметь реактивные клиенты.,Например, Redis может использовать Lettuce в webFlux.