코드에서 Reactive 시스템 아키텍처를 버린 이유는 무엇입니까?
- 王林원래의
- 2024-08-30 06:00:351022검색
이 기사에서는 소프트웨어 프로젝트에서 반응형 아키텍처를 벗어나기로 한 결정을 살펴봅니다. 리액티브 시스템의 핵심 원칙, 비차단 I/O의 이점, 리액티브 접근 방식에서 직면한 과제를 자세히 살펴보겠습니다.
리액티브 아키텍처 스타일 이해
Reactive는 다음과 같은 특징을 지닌 반응형 분산 시스템 및 애플리케이션 구축을 목표로 하는 일련의 원칙과 지침을 포함합니다.
- 응답성: 부하가 심한 경우에도 신속하게 요청을 처리할 수 있습니다.
- 복원력: 다운타임을 최소화하면서 장애를 복구할 수 있습니다.
- 탄력성: 그에 따라 리소스를 확장하여 변화하는 워크로드에 적응할 수 있습니다.
- 메시지 기반: 비동기 메시징을 활용하여 내결함성을 향상하고 구성 요소를 분리합니다.
리액티브 시스템의 주요 이점 중 하나는 비차단 I/O를 사용한다는 것입니다. 이 접근 방식은 I/O 작업 중에 스레드 차단을 방지하여 단일 스레드가 여러 요청을 동시에 처리할 수 있도록 합니다. 이는 기존 차단 I/O에 비해 시스템 효율성을 크게 향상시킬 수 있습니다.
기존 멀티스레딩에서 차단 작업은 시스템 최적화에 심각한 문제를 야기합니다(그림 1). 과도한 메모리를 소비하는 탐욕스러운 애플리케이션은 비효율적이며 다른 애플리케이션에 불이익을 주며 메모리, CPU 또는 더 큰 가상 머신과 같은 추가 리소스를 요청해야 하는 경우가 많습니다.
그림 1 – 기존 멀티스레딩
I/O 작업은 현대 시스템의 필수 요소이며 탐욕스러운 행동을 방지하려면 I/O 작업을 효율적으로 관리하는 것이 무엇보다 중요합니다. 리액티브 시스템은 비차단 I/O를 사용하여 적은 수의 OS 스레드를 사용하여 수많은 동시 I/O 작업을 처리할 수 있습니다.
반응적 실행 모델
비차단 I/O는 상당한 이점을 제공하지만 기존 프레임워크와는 다른 새로운 실행 모델을 도입합니다. 이 문제를 해결하기 위해 반응형 프로그래밍이 등장했는데, 이는 차단 작업 중 플랫폼 스레드 유휴의 비효율성을 완화하기 때문입니다(그림 2).
그림 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은 잠재적으로 많은 경우에 대응적 접근 방식의 필요성을 제거할 수 있습니다.
"Loom 프로젝트는 리액티브 프로그래밍을 죽일 것입니다"
―브라이언 괴츠
결론
결론적으로 우리는 프로젝트의 장기적인 유지 관리에 대한 실용적인 접근 방식인 반응형 아키텍처 스타일에서 벗어나기로 결정했습니다. 반응형 시스템은 잠재적인 이점을 제공하지만 특정 상황에서는 이러한 이점보다 우리 팀에 제시된 과제가 더 컸습니다.
중요한 것은 이러한 변화가 성과를 저하시키지 않았다는 것입니다. 이는 잘 설계된 비반응형(명령형) 아키텍처가 우리의 경우 반응형 아키텍처와 관련된 복잡성 없이 필요한 성능을 제공할 수 있음을 보여주기 때문에 긍정적인 결과입니다.
미래를 내다보면서 기능적일 뿐만 아니라 모든 경험 수준의 개발자가 이해하고 유지 관리하기 쉬운 코드베이스를 구축하는 데 중점을 두고 있습니다. 이는 개발 시간을 단축할 뿐만 아니라 팀 내에서 더 나은 협업과 지식 공유를 촉진합니다.
아래 그래프에서 X축은 코드베이스가 발전하면서 점점 복잡해지는 것을 나타내고, Y축은 이러한 개발 변화에 필요한 시간을 나타냅니다.
위 내용은 코드에서 Reactive 시스템 아키텍처를 버린 이유는 무엇입니까?의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!