RPC의 편리한 구현은 여기에 있습니다 : https://github.com/gaevoy/Gaev.Rpc/tree/master/Gaev.Rpc.Rebus. 이 구현에는 많은 단점이 있습니다. 예를 들어 클라이언트가 수백 명이면 유용한 응답이 1 % 미만으로 표시되고 서버는 필요한 것보다 수백 배 더 많은 데이터를 보냅니다.전송 RabbitMQ와 함께 Rebus를 사용할 때 원격 프로 시저 호출의 일반적인 구현은 무엇입니까?
Rebus with transport RabbitMQ를 사용할 때 원격 프로 시저 호출의 일반적인 구현은 무엇입니까? the tutorial on RabbitMQ에 주어진 RPC 구현과 같은 것입니다.
이상하게도 WCF와 유사하게 요청을 처리 할 때 서버에서 발생할 수있는 강력한 형식의 작업 결과 또는 예외를 반환하는 구현이 필요합니다.
Rebus를 사용하여 RPC (*)를 구현하지 마십시오.
실제로 동기가없는 것을 구현하기 위해 내구성있는 메시징 기반 기술을 사용하지 않는 것이 좋습니다. - IMHO RabbitMQ와 같은 내구성이 강한 중앙 브로커를 사용하여 "안정적인 HTTP"를 구현하는 것은 매우 어리석은 일입니다. 그러나 그것은 여기에 포함하기에는 너무 큰 토론입니다 ...)
Rebus가 비동기 성 및 내구성에 대한 생각으로 가득 차 있기 때문에 Rebus를 사용하여 RPC를 구현하지 않는 것이 좋습니다. 왜냐하면 원시 성능을 희생해야하기 때문입니다 그 곳에서 살아야하는 곳은 its delivery guarantee입니다.
Task 기반의 요청/응답 유형의 API (로컬 프록시 및 마샬링 된 메서드 호출을 사용하는 완전한 RPC 프로토콜의 기본 구성 요소 일 것임)를 확실히 구현할 수 있지만 꽤 이는 Rebus의 API에 내재 된 의도를 많이 위반하는 것이므로 믹스에 더 많은 오버 헤드가 추가됩니다.
요약 : Rebus는 비동기 메시징에 사용하기위한 것으로, HTTP와 같은 경량 요청/응답 유형의 통신 채널을 사용하여 "원격 메소드 호출"을 구현하는 것이 좋습니다.
내가 그 의미 :
(*) "RPC"으로 만드는 희망, 나는 할 수있다 (이 함수 호출과 같은, 즉 동기 호출 사이트에 척 프로그래밍 API를 의미 가정 여전히 Task 기반)
답장을 보내 주셔서 감사합니다! 당신 말이 맞아요. 대기중인 모든 클라이언트에게 주기적으로 새로운 결과를 보내는 자체 복제 작업을 실행하는 것이 좋습니다. – Mentor