MVC4에서 AppHarbor에서 실행되는 웹 응용 프로그램을 빌드하는 방법을 살펴 봅니다. 응답 성 및 성능 측면에서 메시지 대기열에 메시지를 넣으면 약간 더 오래 실행되는 작업 (일반적으로 전자 메일 생성/전송, 이미지 크기 조정, 지불 트랜잭션 처리 등)이 처리됩니다.ASP.NET MVC 및 작업자 응용 프로그램에서 RabbitMQ를 사용하기위한 좋은 인터페이스 설계
결과적으로 처리해야하는 모든 작업과 메시지를 큐에서 빼고 처리하는 작업자가 하나 이상있을 수도 있습니다. 중앙 대기열 처리 메커니즘은 RabbitMQ, 특히 AppHarbor을 통해 사용할 수있는 호스팅 된 CloudAMQP 서비스입니다. 이론적으로이 아키텍처는 더 많은 직원을 추가함으로써 "무한"확장 성을 허용합니다.
좋은 아키텍처, 테스트 가능성 등을 고려하여 RabbitMQ를 쉽게 조롱 할 수있는 하나 이상의 인터페이스 뒤에 배치하려고합니다. 이러한 인터페이스를 정의 할 때 고려할 몇 가지 고려 사항이 있습니다.
- 유료 사용자가 생길 때까지 무료 CloudAMQP 오퍼링으로 제한됩니다. 즉 최대 3 개의 동시 연결을 의미합니다.
- 위의 제약 조건을 감안할 때 애플리케이션 당 하나의 연결로 제한하려고 노력하고 싶습니다. 하나는 MVC 앱용으로 하나는 작업자 당 하나. 그게 전부 야.
- RabbitMQ의 연결은 오랫동안 살아 있도록 설계되었습니다. 그럼에도 불구하고 많은 예제가 명시 적으로 연결 (채널)을 열고 메시지를 보낸 다음 다시 닫는 코드를 보여줍니다.
- 멀티 스레딩의 경우 동일한 연결을 사용할 수 있지만 동일한 채널을 사용할 수는 없습니다. 내가 이해하는 한, 멀티 스레드 응용 프로그램에서 연결을 공유 한 다음 여러 채널 (예 : 스레드 당 하나의 채널)을 열어도됩니다.
- 내 MVC 앱은 일반적으로 게시자 만 사용할 수 있습니다. 작업자 응용 프로그램은 소비자와 게시자가 될 수 있습니다. 예를 들어 작업자가 지불을 처리하라는 메시지를받을 수 있습니다. 그러면 성공 또는 실패를 나타내는 전자 메일 메시지를 사용자에게 보내는 메시지가 게시됩니다.
- MVC 응용 프로그램의 경우 연결은 대개 매우 짧은 시간 동안 만 - 메시지 대기열로 사용됩니다.
- 근로자에게 나는 장기간 연결을 생각하며, 평생 동안 평생 열리게됩니다.
괜찮 았네. 이 프로젝트를 시작하기 전에 RabbitMQ에 대한 경험이 없기 때문에 몇 가지 추가 사항이 있습니다.
- 인터페이스 분리 원리. 이것을 IQueueServiceConsumer 및 IQueueServiceProducer와 같은 두 개의 분리 된 인터페이스로 나누어야합니까? 아니면 너무 멀리하는 것이 있습니까? SRP 등을 사용하여 더 많은 원자 단위로 나눌 수 있다는 것을 알았습니다. Bob 삼촌이 나를 사냥하고 싶지는 않지만 (인터페이스 이름보다 더 많이), 나는 내가 얼마나 멀리 있어야하는지 궁금합니다. 가져가.
- 적어도 하나의 웹 서버 만 갖게 될 것이라는 점을 감안할 때 적어도 처음에는 웹 응용 프로그램의 대기열에 실제로 긴 수명의 연결을 갖는 것이 좋을까요? 그것들을 열고 닫으면 충돌과 잠재적 인 메시지가 손실된다는 것을 의미하는 여러 가지 일이 이론적으로 일어납니다. 분실 한 메시지는 허용되지 않습니다.
- 이 경우 연결의 수명을 어떻게 처리합니까? 내 Ninject 모듈 (내 인터페이스가 RabbitMQ 특정 구현에 실제로 바인딩되어있는 곳)에서 열어서 애플리케이션이 재활용 될 때 어떻게 든 연결을 끊으시겠습니까? 어떻게 그런 짓을 할 수 있니?
- 근로자에게는 인생이 더 쉬워 보입니다.인터페이스에 메소드를 연결하여 연결을 연 다음 메시지 수신을 위해 스레드에 채널을 제공하십시오. 적절하게 CloseConnection을 호출하여 응용 프로그램이 제대로 작동하는지 확인하십시오. 또는 IDisposable을 구현하십시오.
- 미래에는 RabbitMQ가 다른 것으로 대체 될 가능성이 있습니다. 그렇기 때문에 인터페이스가 특정 서비스 버스에 너무 한정적 이길 원하지는 않습니다. 그것을 사용하여) 구현.
비슷한 응용 프로그램을 만들 때 다른 사람이 이미 동일한 문제를 해결 했습니까? 메시지 대기열에 대한 인터페이스의 아키텍처 및 실제 구현을위한 조언이 있습니까? 나는 이것에 대해 신경증 적이거나 인정할 가치가있는 나의 걱정입니까?
현재의 메시징 요구 사항은 단방향 메시지로 처리되므로 처리가 완료되면받은 메시지를 확인하는 것 외에 응답 할 필요가 없습니다.
모든 통계를 제공해 주셔서 감사합니다.
흥미 롭군요. 고마워요, 고마워요! –