단명의 동기 통신을 쟁취하다

서비스와 상호작용할 때, 비동기 통신은 통상적으로 가장 좋은 방식이다.이라는 책은 바로 이렇게 말했다(본문의 나머지 부분에서도TL;DR;)

With synchronous communication, the caller must wait for the receiver to finish processing the call before the caller can receive the result and continue. In this way, the caller can only make calls as fast as the receiver can perform them. On the other hand, asynchronous communication allows the sender to batch requests to the receiver at its own pace, and for the receiver to consume the requests at its own different pace. This allows both applications to run at maximum throughput and not waste time waiting on each other (at least until the receiver runs out of messages to process).

그러나 어떤 경우에는 동기화 통신이 불가피하다.이 예를 보여 주세요.

서비스 간 통신

만약 우리가 파일을 업로드하고 처리하는 시스템이 있다면그것은 우리가 제어할 수 없는 유류 모듈로 구성되어 있다.이 모듈은 파일 시스템에서 파일을 가져와 HTTP를 통해 지정한 단점으로 업로드하고 업로드에 성공하면 보충 메타데이터 파일을 업로드합니다.
우리는 유류 모듈을 제어할 수 없기 때문에 동기화 통신을 견지하는 것 외에 다른 선택이 없다.일단 파일이 우리 시스템에 업로드되면, 우리는 대량의 처리 활동을 실행할 것이며, 이것은 대량의 시간을 소모할 것이다.
우리는 아래의 도표로 현재의 상황을 총결할 수 있다.

장시간 실행된 작업을 단독 작업으로 추출

네가 그것을 축소하지 않는 한, 평소와 같이, 이 디자인은 아무런 문제가 없다.그러나 만약에 대량의 파일을 업로드해야 한다면 분명히 병목은 유류 모듈이 매번 우리의 코드가 파일을 저장하고 처리할 때까지 기다려야 추가 파일을 업로드할 수 있다는 것이다.따라서 수요를 충족시키기 위해서는 상호작용 시간을 줄여야 한다.그리고 모든 HTTP 요청이 처리되기를 기다리는 것이 얼마나 낭비인지 알아차리기 시작합니다.구제 방법은 가능한 한 빨리 응답을 되돌려 백그라운드에서 처리하는 것이다.

여기에는 점선 화살표로 비동기 통신을 표시한다.파일을 저장하면 파일이 프로세서 모듈에 저장되었음을 알리는 메시지가 전송됩니다.이를 위해 AMQP를 사용하여 취향을 구현할 수 있습니다.메시지가 비동기적이기 때문에, 우리는 프로세서의 응답을 기다릴 필요가 없고, 응답을 전통적인 업로드 구성 요소로 더 일찍 되돌릴 수 있다.
이 두 구성 요소는 모두 하나의 프로세스 내에서 통신한다는 것을 주의하십시오.이것은 내가 다음 절에서 소개할 이유다.

수평 배율 솔루션

지금까지 일부 독자들은 "두 개의 구성 요소를 분리할 수 있는데 왜 그것들을 한 서비스에 남겨 두어야 합니까?"라는 질문을 제기할 수 있다.
비록 마이크로 서비스가 몇 년 전에는 핫이슈였지만, 오늘날 점점 더 많은 조직들이 마이크로 서비스를 정확하게 사용하는 것이 어렵다는 것을 깨닫기 시작했다.그것은 일정한 공사 능력(분포식 로그 기록, 고장 복구)과 조직 능력(코드 소유권 분리, 유지보수 서비스 간의 최신 계약, 안정적인 배치 전략)이 필요하다.마이크로 서비스만 도구로 삼아 코드 라이브러리를 관리하기 쉬운 부분으로 나누는 사람들에게는 이 모든 것이 예방 조치가 되어야 한다.이것이 바로 내가 프로세스 간 통신을 기본적인 체계 구조 스타일로 고수하기로 결정한 이유이다.
그럼에도 불구하고, 어떤 경우, 높은 부하로 인해, 더 큰 부하를 견딜 수 있도록 해결 방안을 확장해야 합니다.따라서 자연스러운 해결 방안은 파일 업로드를 병행 처리하는 것이다.그러나 하나의 서버 실례에서 병행 처리는 그 자체의 한계가 있기 때문에 최종적으로 여러 서비스에 서비스를 배치할 것입니다. (수준 확장)이런 상황에서 파일을 데이터베이스에 영구화하는 IO 집약형 부분은 수평 확장에 도움이 되고 프로세서 부분은 수직 확장에 도움이 될 수 있다(예를 들어 더 강한 프로세서를 추가해서 계산 집약형 논리를 실행하는 것).
시스템 부분을 독립적으로 확장하는 능력은 마이크로 서비스 체계 구조 스타일을 사용하는 관건적인 원인 중 하나이다.(또 하나는 inverse Conway maneuver이지만 본문의 범위를 넘어섰다.
이런 상황에서 시스템의 두 부분은 모두 독립적으로 배치되고 메시지 대기열을 통해 통신을 한다. 아래 그림과 같다.

HTTP 요청 기간 단축

또 다른 흥미로운 분야는 고객을 위한 UI 애플리케이션입니다.대량의 연구는 페이지의 마운트 시간의 증가가 어떻게 고객의 불만을 야기하는지를 보여 주었다.HTTP 호출 지속 시간은 페이지 불러오는 시간의 한 구성 부분이기 때문에, 우리도 당연히 그것을 줄이기를 희망합니다.
다음 가설 코드를 살펴보자. 응용 프로그램에 사용자를 등록하는 것을 책임진다.

public async Task<IActionResult> FlushTemporary(CancellationToken token)
{
    if (validator.IsValid(user))
    {
        await _repository.SaveUser(user, token);
        await _mailingService.SendConfirmationEmail(user, token);
    }
    return Ok();
}

위의 코드는 asynchronous programming model라는 기능을 이용했지만 실제로는 호출자의 측면에서 볼 때 동기화되었다. 왜냐하면 호출자는 사용자가 데이터베이스에서 오래 지속되고 확인 전자메일을 보낼 때까지 기다려야 하기 때문이다!
말할 것도 없이, 이것은 등록 단계에서 고객을 추가로 기다리게 할 것이다.여기에서, 위의 예와 같이, 우리는 전자메일을 백엔드 작업에 추출하는 것을 확인해야 하며, 이 작업은 등록 절차 후에 실행될 것이다.

결론

동기화 통신이 도입된 대기 시간은 시스템 간 통신이나 고객을 대상으로 하는 응용 프로그램에서 불필요할 수 있습니다.동기 통신의 어느 부분을 이해하는 것이 불가피하고, 어느 부분을 이후에 완성할 수 있는지가 매우 중요하다.뒷부분에 있어서 백엔드 프로세서는 이 문제를 처리하는 교묘한 기교이다.