Java: использование приложения Spring WebFlux из приложения Play Framework - PullRequest
Новая
       43

Java: использование приложения Spring WebFlux из приложения Play Framework

2 голосов
/ 12 мая 2019

У меня возникли вопросы по использованию приложения Spring WebFlux из приложения Play Framework через HTTP, не могли бы вы помочь?

Микросервис A - это реактивный Spring WebFlux, написанный на Java 8, SpringBoot 2.1.4, который предоставляет этот API: 

@Autowired private ReactiveCustomerRepository customerRepository;

@GetMapping("/customers")
public Flux<Customer> getAllCustomers() {
    Flux<Customer> c = customerRepository.findAll().delayElements(Duration.ofMillis(5000));
    return c;
}

Я бы хотел использовать это, реагируя способом из микро-сервиса B Play Framework, через HTTP.

Не могли бы вы дать несколько советов или небольшой фрагмент, как этого добиться?

Спасибо за вашу помощь.

Ответы [ 2 ]

1 голос
/ 13 мая 2019

Вы можете попробовать использовать другой тип контента, который поддерживает потоковую передачу - application/stream+json.Spring WebFlux будет сериализовать отдельные элементы Flux и отправлять их по одному по проводам.Посмотрите на следующую ветку SO об этом: Поведение Spring WebFlux Flux с не потоковым приложением / json

На стороне воспроизведения вы сможете получить эти данные как Source[T].

0 голосов
/ 12 мая 2019

Я не специалист в этой области, но постараюсь составить конструктивное мнение на основе моего опыта.

Учитывая перспективу двух отдельных реактивных микросервисов, которые являются Spring Webflux / Play Framework, они оба представляют нам концепцию неблокирующего / параллельного клиента для выполнения HTTP-запросов. Будучи независимыми от протокола, эти системы сохраняют принципы реактивности в своих соответствующих средах, где каждый HTTP-запрос будет обрабатываться асинхронно и отдельно от блокировки выполнения приложения. Поэтому я ищу узкое место в самом HTTP, а не хорошее соединение между WebFlux <-> Play.

Я бы предложил поискать более эффективные альтернативы коммуникации, чем обычный HTTP, в пользу HTTP / 2 и / или RPC (особенно это закрытое / отдельное окружение обмена данными между микросервисами).

Эти публикации могут быть полезны:

И еще более масштабируемо с GRPC - высокопроизводительная универсальная среда RPC с открытым исходным кодом .

Это мой взгляд на действительно реактивное , соединяющее два реактивных микроуслуга. В противном случае это просто не отличается от стандартного запроса HTTP GET. Я рад принять конструктивную критику в комментариях.

...