코드에서 Reactive 시스템 아키텍처를 버린 이유는 무엇입니까?-java지도 시간-php.cn

코드에서 Reactive 시스템 아키텍처를 버린 이유는 무엇입니까?

王林

풀어 주다： 2024-08-30 06:00:35

원래의

910명이 탐색했습니다.

이 기사에서는 소프트웨어 프로젝트에서 반응형 아키텍처를 벗어나기로 한 결정을 살펴봅니다. 리액티브 시스템의 핵심 원칙, 비차단 I/O의 이점, 리액티브 접근 방식에서 직면한 과제를 자세히 살펴보겠습니다.

리액티브 아키텍처 스타일 이해

Reactive는 다음과 같은 특징을 지닌 반응형 분산 시스템 및 애플리케이션 구축을 목표로 하는 일련의 원칙과 지침을 포함합니다.

응답성: 부하가 심한 경우에도 신속하게 요청을 처리할 수 있습니다.
복원력: 다운타임을 최소화하면서 장애를 복구할 수 있습니다.
탄력성: 그에 따라 리소스를 확장하여 변화하는 워크로드에 적응할 수 있습니다.
메시지 기반: 비동기 메시징을 활용하여 내결함성을 향상하고 구성 요소를 분리합니다.

리액티브 시스템의 주요 이점 중 하나는 비차단 I/O를 사용한다는 것입니다. 이 접근 방식은 I/O 작업 중에 스레드 차단을 방지하여 단일 스레드가 여러 요청을 동시에 처리할 수 있도록 합니다. 이는 기존 차단 I/O에 비해 시스템 효율성을 크게 향상시킬 수 있습니다.
기존 멀티스레딩에서 차단 작업은 시스템 최적화에 심각한 문제를 야기합니다(그림 1). 과도한 메모리를 소비하는 탐욕스러운 애플리케이션은 비효율적이며 다른 애플리케이션에 불이익을 주며 메모리, CPU 또는 더 큰 가상 머신과 같은 추가 리소스를 요청해야 하는 경우가 많습니다.

Why we discarded Reactive systems architecture from our code?

그림 1 – 기존 멀티스레딩

I/O 작업은 현대 시스템의 필수 요소이며 탐욕스러운 행동을 방지하려면 I/O 작업을 효율적으로 관리하는 것이 무엇보다 중요합니다. 리액티브 시스템은 비차단 I/O를 사용하여 적은 수의 OS 스레드를 사용하여 수많은 동시 I/O 작업을 처리할 수 있습니다.

반응적 실행 모델

비차단 I/O는 상당한 이점을 제공하지만 기존 프레임워크와는 다른 새로운 실행 모델을 도입합니다. 이 문제를 해결하기 위해 반응형 프로그래밍이 등장했는데, 이는 차단 작업 중 플랫폼 스레드 유휴의 비효율성을 완화하기 때문입니다(그림 2).

Why we discarded Reactive systems architecture from our code?

그림 2 – 반응형 이벤트 루프

Quarkus와 리액티브

Quarkus는 Eclipse Vert.x 및 Netty로 구동되는 반응형 엔진을 활용하여 비차단 I/O 상호 작용을 촉진합니다. Quarkus를 사용하여 반응형 코드를 작성하는 데 선호되는 접근 방식인 Mutiny는 수신된 이벤트에 의해 반응이 트리거되는 이벤트 중심 패러다임을 채택합니다.

Mutiny는 두 가지 이벤트 중심 유형과 게으른 유형을 제공합니다.

Uni: 결과가 0개 또는 1개 있는 비동기 작업을 나타내는 데 적합한 단일 이벤트(항목 또는 실패)를 내보냅니다.
다중: 잠재적으로 무한한 항목 스트림을 나타내는 여러 이벤트(n개 항목, 1개 실패 또는 1개 완료)를 발생시킵니다.

리액티브의 과제

반응형 시스템은 이점을 제공하지만 개발 과정에서 몇 가지 문제에 직면했습니다.

패러다임 전환: 반응형 프로그래밍에는 개발자 사고방식의 근본적인 변화가 필요하며, 이는 특히 명령형 프로그래밍에 익숙한 개발자에게는 어려울 수 있습니다. Streams API와 같은 보조 도구와 달리 반응형 접근 방식에는 완전한 사고방식 점검이 필요합니다.
코드 가독성 및 이해: 반응형 코드는 신규 개발자가 이해하기 어려워 코드를 해독하고 이해하는 데 더 많은 시간을 소비하게 합니다. 반응형 패러다임으로 인해 발생하는 복잡성으로 인해 이 문제가 더욱 복잡해졌습니다.

"실제로 읽는 시간과 쓰는 시간의 비율은 10:1이 훨씬 넘습니다. 우리는 새로운 코드를 작성하려는 노력의 일환으로 오래된 코드를 끊임없이 읽고 있습니다. ...[그러므로] 읽기 쉽게 하면 쓰기 편해요."
― 로버트 C. 마틴, Clean Code: A Handbook of Agile Software Craftsmanship

디버깅 과제: 반응 코드 디버깅은 대부분의 코드를 캡슐화하는 람다로 인해 표준 IDE 디버거로는 거의 불가능합니다. 또한 예외 중에 의미 있는 스택 추적이 손실되면 디버깅 노력이 더욱 방해됩니다. 개발 및 테스트 노력 증가: 반응형 코드에 내재된 복잡성으로 인해 작성, 수정 및 테스트에 필요한 시간으로 인해 개발 주기가 길어질 수 있습니다.

다음은 복잡성을 설명하기 위해 Mutiny를 사용하는 반응형 코드의 예입니다.

Multi.createFrom().ticks().every(Duration.ofSeconds(15))
    .onItem().invoke(() - > Multi.createFrom().iterable(configs())
    .onItem().transform(configuration - > {
  try {
    return Tuple2.of(openAPIConfiguration,
        RestClientBuilder.newBuilder()
            .baseUrl(new URL(configuration.url()))
            .build(MyReactiveRestClient.class)
            .getAPIResponse());

  } catch (MalformedURLException e) {
    log.error("Unable to create url");

  }
  return null;
}).collect().asList().toMulti().onItem().transformToMultiAndConcatenate(tuples - > {

  AtomicInteger callbackCount = new AtomicInteger();
  return Multi.createFrom().emitter(emitter - > Multi.createFrom().iterable(tuples)
      .subscribe().with(tuple - >
          tuple.getItem2().subscribe().with(response - > {
              emitter.emit(callbackCount.incrementAndGet());

  if (callbackCount.get() == tuples.size()) {
    emitter.complete();
  }
                    })
                ));

}).subscribe().with(s - > {},
Throwable::printStackTrace, () - > doSomethingUponComplete()))
    .subscribe().with(aLong - > log.info("Tic Tac with iteration: " + aLong));

로그인 후 복사

미래 전망 - 프로젝트 Loom 및 그 너머

Java 생태계에서 최근 개발된 프로젝트 Loom은 차단 작업과 관련된 문제를 완화할 것을 약속합니다. 하드웨어 변경 없이 수천 개의 가상 스레드 생성을 가능하게 함으로써 Project Loom은 잠재적으로 많은 경우에 대응적 접근 방식의 필요성을 제거할 수 있습니다.