Лучший способ опроса конечной точки привода пружинного ботинка (потоковая передача вместо опроса?)

Я программирую веб-интерфейс, который отслеживает другое приложение Java в Spring Boot, поддерживаемый Spring Actuator.

Прямо сейчас я могу опросить конечные точки Spring Actuator из другого клиентского веб-приложения Sprint Boot, используя обычный запрос Get (через метод Spring WebFlux WebClient.get ()).

Но если некоторые данные изменяются, скажем, одна из конечных точек метрики (т.е. использование ЦП, которое всегда изменяется), я должен «обновить» запрос на получение. Я могу установить его на запланированный таймер с помощью аннотации @Scheduled, но я чувствую, что есть способ сделать это лучше?

Я знаю, как получить поток из запроса на получение данных с постоянным потоком, но на сервере необходимо создать поток. Может ли Spring Boot Actuator предоставить поток показателей, чтобы я мог их транслировать?

Вот некоторый код, в настоящее время я вызываю этот метод с помощью запланированного метода, который проверяет его каждые 500 мс.

private Flux<Health> getHealth(String baseUrl) {

    var fallbackValue = new Health();
    fallbackValue.setStatus("Unknown");
    return webClient.get().uri(baseUrl + "/actuator/health").retrieve().bodyToFlux(Health.class)
            .onErrorReturn(fallbackValue);

}

Но он обновляется, только если я вызываю его и использую запланированную аннотацию, чтобы всегда обновлять его:

@Scheduled(fixedDelay = 500) // I want to remove this, instead of refreshing, I want the data to stream
public void pollCapHandlers() {

    getHealth("http://localhost:8080").subscribe(health -> {
        ui.access(() -> {
            healthStatusTextField.setValue(health.getStatus()); // this doesn't update in real time
        });
    })

spring-boot spring-boot-actuator server-sent-events spring-webflux spring-webclient
person Armando Perea    schedule 27.11.2019    source источник

Ответы (1)


arrow_upward
2
arrow_downward

Во-первых, вам следует избегать слишком частого вызова конечных точек исполнительных механизмов, особенно когда ваше приложение не использует данные. Если ваше приложение является приборной панелью, оно не должно получать данные, если кто-то не просматривает эту информационную панель в данный момент. Это исключает использование @Scheduled, которое случается несмотря ни на что. Кроме того, данные привода могут быть кэшированы или могут создавать некоторую нагрузку на приложение, в зависимости от конечной точки. Это следует тщательно продумать.

Теперь вы можете добиться этого в потоковом режиме, например, в своем приложении для опроса:


@GetMapping(path = "/status/{application}", produces = MediaType.TEXT_EVENT_STREAM_VALUE)
public Flux<Status> streamStatus() {
  return Flux.interval(interval).flatMap(i -> getHealth(...));
}

Это позволяет вам периодически опрашивать удаленную конечную точку и передавать результат в браузер (с помощью SSE), не добавляя ненужной нагрузки удаленным приложениям.

person Brian Clozel    schedule 27.11.2019
comment
Спасибо, попробую. Я определенно не хочу использовать @scheduled, я вставил это как временный хакер, пока не смогу сделать это правильно! : D - person Armando Perea; 05.12.2019