교차 장부my blog article.
지난 몇 년 동안'반응식 서버 응용 프로그램'의 아이디어는 대대적으로 보급되었는데, 특히 새로운 구조를 통해.자바 세계에서는 줄곧 RxJava, vert.x, 그리고 최근Spring WebFlux이다.
비록 나는 대체적으로 이러한 잠재적인 생각을 좋아하지만, 나는 작가와 사용자가 이러한 생각을 추진하는 방식에 모두 문제가 있다는 것을 발견했다.저와 트위터에서 대화를 한 번 나눈 후에 그 이유를 설명하고 싶습니다.
그것을 둘러싸고 두 개의 신화가 있는데, 가장 중요한 것은...

동기화 부호 느림/무효 부호 빠름

이거 진짜야?
그렇다면 우선 동기화는 무엇을 의미하는가?초기에 코드는 컴퓨터에서 순서대로 실행되었다.코드가 끝날 때까지 명령을 하나하나 내리다.한 번에 여러 개의 프로그램을 실행해야 한다.이것은 절차에 대한 수요가 생겼다.현재 여러 개의 프로그램이 동시에 실행될 수 있으며, 반드시 병행 실행되는 것은 아니다.프로세서는 프로그램 실행 사이를 왔다 갔다 하며 메모리를 분리하기만 하면 된다.
그리고 한 프로그램에서 동시에 작업을 수행해야 합니다.생성된 스레드는 프로그램의 여러 부분을 동시에 실행할 수 있지만 메모리를 공유할 수 있습니다.
동기화 코드는 프로세스와 전용 라인에서만 실행됩니다.
반응식 프로그래밍 모델은 집중 처리 프로그램이 드나드는 모든 사물(I/O)을 가정한다.한 라인은 통상적으로 여러 가지 임무를 수행하여 발생할 수 있는 일을 순환적으로 처리한다.새 TCP 연결이 있습니까?내 바이트가 흐름에 기록됩니까?파일이 디스크에서 로드됩니까?일단 완성되면, 그것은 등록된 코드를 통지할 것이다.이것은 리셋 함수가 될 것이다.
그럼 이 동기화 코드는 반응 코드보다 느립니까?사실 동기화 코드는 두 가지 사이에서 다른 일을 하는 데 사용되지 않기 때문에 더 빠르다.현재 TCP 흐름을 쓰고 있는 것처럼 프로그램의 다른 부분을 파일에서 읽으려고 하기 때문에 전송 바이트를 중단하는 것은 없습니다.따라서 이상적인 파이프라인(예를 들어 무한한 입출력 처리량)이 있다고 가정하면 동기화 코드가 더욱 빠를 것이다.그러나 대부분의 경우 입력/출력이 계산보다 훨씬 느리다는 것은 입력/출력이 완성되기를 기다리는 동시에 다른 일을 할 시간이 많다는 것을 의미한다.

노선이 매우 비싸다

현재, 당신은 하나의 라인을 동시에 사용하여 다른 일을 할 수 있습니다.왜 이게 문제야?음, 하나의 라인을 만드는 데는 수천 바이트의 RAM이 필요하고, 여러 라인 사이에서 상하문을 전환하는 것도 비싸다.
예를 들어, 참조here.어떤 경우, 그것은 당신의 모든 메모리와 CPU를 먹게 될 것이다.

반응성이 더 좋아요.

고전적인 웹 서버에서 전송된 모든 웹 요청에 대해 새 라인을 시작하거나 탱크에서 새 라인을 다시 사용한 다음 이 라인에서 모든 처리, DB 호출 등을 완료합니다.이것은 네가 더 높은 부담을 받을 때까지 여전히 문제없다.RAM 사용과 일부 운영 체제의 제한으로 인해 무한한 스레드를 가질 수 없습니다.제한은 수천 개의 라인 정도일 수 있다.따라서 프로그램의 메모리가 부족하거나 (강제 실행 루틴 제한이 없거나) 느린 처리 응답 (유한된 루틴 탱크) 을 받을 수 있습니다. 왜냐하면 일부 요청은 사용할 루틴이 풀릴 때까지 기다려야 하기 때문입니다.
문제는 이 한계에 도달하려면 행운의 사람이 되어야 한다는 것이다.Spring Boot 응용 프로그램의 단일 인스턴스 (예:) 에서도 상당한 로드를 제공할 수 있으며 응답 시간이 매우 느립니다.
이 제한에 도달하면 응용 프로그램의 여러 실례를 생성하고 부하 평형기를 사용할 수 있습니다.
즉, 반응식 응용 프로그램은 낮은 부하에서 응답 시간이 느릴 수 있지만, 더 많은 전송 요청에 대해서는 이 응답 시간을 일정하게 유지할 수 있다.그것은 서버의 기존 자원을 더욱 효과적으로 사용할 수 있다.
너는 here과here의 두 문장에서 이 점을 찾을 수 있다.

프로그래밍 모델

비동기식 I/O 처리를 사용하는 것은 좋은 생각인 것 같지만, 모든 상황에서'더 좋다'는 것은 아니지만, 코드를 작성하는 방식을 완전히 바꾸었다는 심각한 결함이 있다.가장 유행하는 프로그래밍 언어에서, 당신은 비동기적일 뿐만 아니라, 매우 좋다.
내가 전에 언급한 바와 같이 답전의 개념이 있다.그래서 개념적으로.

    someFunction() {
        value = getValue()
        print(value)
    }

너는 이렇게 해야 한다.

    someFunction() {
        getAsyncValue(callback)
    }

    callback(myValue) {
        print(myValue);
    }

그러나 이것은 단지 가장 기본적인 상황일 뿐이다.만약 플러그인 호출이 있다면, 상황은 더욱 나빠질 것이다.

    someFunction() {
        getAsyncValue(valueCallback)
    }

    valueCallback(myValue) {
        getUserFromDbAsync(dbCallBack)
    }

    dbCallback(user) {
        print(user + myValue);
    }

이것은 두 개의 호출된 조합입니다. 아이고, 제가 어떻게 myValue 함수를 dbCallback 함수에 전달합니까?
이제 lambda와 패키지 동결 코드의 부동점 값을 사용할 수 있습니다.

    someFunction() {
        getAsyncValue(myValue -> {
            getUserFromDbAsync(user -> {
                print(user + myValue)
            })
        })
    }

이게 더 좋아요?그럼 오류 처리는요?용이성:

    someFunction() {
        getAsyncValue(myValue -> {
            getUserFromDbAsync(user -> {
                print(user + myValue)
            }).onError(() -> {
                print("can't get user")
            }
        }).onError(() -> {
            print("can't get value")
        })
    }

리셋 중인 DB 사용자 오류를 처리하려면 어떻게 해야 합니까?보세요my vert.x 2 review article.그것은 매우 낡았지만, 본문의 몇 가지 생각을 포괄하였다.
WebFlux와 같은 리액션 스택의 경우 체인식 위조 함수를 사용하여 호출할 수 있습니다. 예를 들어

    someFunction() {
        getAsyncValue()
            .map(myValue -> print);
    }

그러나 상술한 호출을 조합하고 오류 핸들을 추가하려면 까다로워집니다.당신은 긴 체인getAsyncValue,.map,flatMap을 가지고 있습니다. 비동기적인 버전에 비해 많이 개선되지 않을 것입니다. 동기화된 버전에 비해 좋지 않습니다.예제 here 를 참조하십시오.실제로 하나의 방법은 체인을 12줄로 호출하는데 위조 if-else 호출을 포함한다.
상기 모든 상황에서 함수 인용, lambda 또는 반응식 확장을 사용하면 코드는 다음과 같은 측면에서 영향을 받는다.

가독성

뚜렷하고 코드가 더 길다

복잡성

더 이상 순서 흐름이 없습니다.또는 이렇게 말하면 코드는 원본 코드에서 다른 순서로 실행된다.

서비스 용이성

기능 추가 어려움

이 코드를 디버깅하는 것은 훨씬 복잡하다.너는 간단하게 그것을 뛰어넘을 수 없다

테스트 가능

1 또는 2개 클래스의 호출 방법을 간단하게 모의할 수 없다.비동기식 비동기식 비동기식 객체를 작성해야 합니다.

코드 품질

읽기로 코드를 소화하기 어려워서 동기화 코드보다 더 많은 버그가 있습니다.

개발 속도

매우 간단한 작업, 예를 들어 서로 다른 반환 유형을 가진 두 개의 REST 요청, 서로 구축해야 하는 작업(예를 들어 주 데이터를 얻고 관련 데이터가 풍부하게 사용되며 UI로 되돌아오는 것)

간단하게 말하면 너는 네 생각에 따라 글을 쓸 수 없다

나는vert로 전문 응용 프로그램을 쓴 적이 있다.x, RxJava, 최근의 Spring-WebFlux 및 상기 문제는 서로 다른 버전에서 찾을 수 있습니다.

이제 어떡하지?

실제로 쓰기 및 읽을 수 있는 코드를 동기화해야 하지만 기본 실행 시 기존 오류 처리를 지원하는 비동기식으로 수행해야 합니다.

    someFunction() {
        try {
            myValue = getAsyncValue()
            user = getUserFromDbAsync()
            print(user + myValue)
        } catch (ComputationException e) {
            print("can't get value")
        } catch (DbException e) {
            print("can't get user")            
        }

현재, 당신은 세 줄 내의 좋은 경로와 독립적인 오류 처리를 가지고 있습니다.코드는 이해하기 쉽다.DB가 데이터를 반환할 때까지 실행 중지 zip 가 발생합니다.이 라인은 다른 작업에 사용될 것입니다.
Erlang는 배우 모델과 BEAM VM에서 이를 실현했다.파일에서 읽을 때, 호출 getUserFromDbAsync 만 하면 결과를 얻을 수 있습니다.VM은 현재 actor와 Erlang 프로세스를 종료합니다. (이것은 몇 바이트 메모리만 사용하는 경량급 라인입니다.)
JVM의 경우 현재 Project Loom JVM에서 연속성을 시도하고 있으며 파이버(Fiber)라는 추상이 JDK의 일부로 사용되고 있습니다.나로서는 전도가 유망해 보이지만, 시간이 좀 걸릴 뿐만 아니라, 자바의 일부가 될지는 아직 백 퍼센트 확실하지 않다.
Pythonasyncio은 자바보다 더 높은 언어 특성을 제공했지만 여전히 너무 노출되어 있다. IMHO.

결론

내 글에서 내가 강조하고 싶은 것은 반응식 프로그래밍이 결코 만능이 아니라는 것이다.네가 무엇을 하고 있는지, 그리고 네가 왜 그것을 필요로 하는지 반드시 알아야 한다.
나와 조쉬의 토론에서 발췌한 것이다.

𝙹𝚊𝚗 𝚆𝚎𝚍𝚎𝚕

나의 관점은 WebMVC와 WebFlux는 모두 존재하는 이유가 있지만, 대부분의 프로젝트에 있어서 WebMVC는 당신이 충분한 이유가 있고 자신이 무엇을 하고 있는지 알지 않는 한 더 좋은 선택이라고 생각한다.이것은 마치 테슬라의 미친 모드를 사용하는 것과 같다.🚗
2018년 6월 22일 오전 04:21
현재 소수의 장면만 완전 반응식 서버 응용 프로그램을 구축해야 한다고 본다.그렇지 않으면 고전적인 방법을 견지하기만 하면 된다.
문제는 네가 반응 해머로 프로그램을 한동안 작성한 후에 (학습 곡선이 가파르다) 모든 임무를 못으로 간주할 수 있다는 것이다.만약 코드의 질이 영향을 받지 않았지만 객관적으로 확실히 영향을 받게 된다면 이것도 상관없다.
그리고 경험이 없는 개발자에게는 쿨해 보일 수도 있다. 이해하기 어렵기 때문이다.가장 우수한 개발자만이 그것을 이해할 수 있을 것 같다.하지만 나를 믿어라, 사실은 그렇지 않다.가장 좋은 언어와 API 디자인은 쉽게 이해하고 작성하며 읽을 수 있는 디자인이다.