어떤 조건에서 웹 서비스 대신 메시지 큐를 통해 말하는 앱을 선호 하는가?
로컬 네트워크에서 두 앱간에 대화해야합니다. 하나는 웹 앱이며 다른 하드웨어에서 실행되는 다른 앱에서 명령을 요청해야합니다. 요청은 사용자 작성, 파일 이동 및 디렉토리 작성과 같은 것입니다. 메시지 대기열을 사용하는 것보다 XML 웹 서비스 (또는 직접 TCP 등)를 선호하는 조건은 무엇입니까?
웹 응용 프로그램은 Ruby on Rails이지만 질문이 그보다 광범위하다고 생각합니다.
답변
웹 서비스를 사용하면 클라이언트와 서버가 있습니다.
- 서버가 실패하면 클라이언트는 오류를 처리해야합니다.
- 서버가 다시 작동하면 클라이언트는 서버를 다시 보내야합니다.
- 서버가 호출에 응답하고 클라이언트가 실패하면 작업이 손실됩니다.
- 경합이 없습니다. 즉, 수백만 명의 클라이언트가 한 서버에서 한 번에 웹 서비스를 호출하면 서버가 다운 될 수 있습니다.
- 서버에서 즉각적인 응답을 기대할 수 있지만 비동기 호출도 처리 할 수 있습니다.
RabbitMQ, Beanstalkd, ActiveMQ, IBM MQ Series, Tuxedo와 같은 메시지 큐를 사용하면 다른 내결함성 결과를 기대할 수 있습니다.
- 서버가 실패하면 큐는 메시지를 유지합니다 (선택적으로 시스템이 종료 된 경우에도).
- 서버가 다시 작동하면 보류중인 메시지를받습니다.
- 서버가 호출에 응답하고 클라이언트가 실패하면 클라이언트가 응답을 인식하지 못하면 메시지가 지속됩니다.
- 경합이 있으며 서버가 처리하는 요청 수를 결정할 수 있습니다 (대신 작업 자라고 함).
- 즉각적인 동기 응답을 기대하지는 않지만 동기 호출을 구현 / 시뮬레이트 할 수 있습니다.
Message Queues에는 훨씬 더 많은 기능이 있지만 이는 오류 조건을 직접 처리 할 것인지 아니면 Message Queue에 남겨 둘 것인지 결정하는 몇 가지 규칙입니다.
답변
REST HTTP 호출이 메시지 큐 개념을 대체 할 수있는 방법을 고려한 최근의 많은 연구가있었습니다.
프로세스 및 작업 개념을 리소스로 도입하면 중간 메시징 계층에 대한 필요성이 사라지기 시작합니다.
전의:
POST /task/name
- Returns a 202 accepted status immediately
- Returns a resource url for the created task: /task/name/X
- Returns a resource url for the started process: /process/Y
GET /process/Y
- Returns status of ongoing process
작업에는 여러 단계의 초기화가있을 수 있으며 프로세스는 폴링시 상태를 반환하거나 완료되면 콜백 URL로 POST 할 수 있습니다.
이것은 매우 간단하며, 중간 계층없이 실행중인 모든 프로세스 및 작업의 rss / atom 피드에 가입 할 수 있다는 것을 알게되면 매우 강력 해집니다. 모든 큐잉 시스템에는 어쨌든 일종의 웹 프론트 엔드가 필요하며이 개념은 다른 사용자 정의 코드 계층없이 내장되어 있습니다.
리소스는 삭제할 때까지 존재하므로 프로세스 및 작업이 완료된 후 오랫동안 기록 정보를 볼 수 있습니다.
복잡한 프로토콜없이 여러 단계를 수행하는 작업에 대해서도 서비스 검색 기능이 내장되어 있습니다.
GET /task/name
- returns form with required fields
POST (URL provided form's "action" attribute)
서비스 검색은 HTML 형식으로, 사람이 읽을 수있는 범용 형식입니다.
전체적으로 사용되는 도구를 사용하여 프로그래밍 방식으로 또는 사람이 전체 흐름을 사용할 수 있습니다. 클라이언트 중심이므로 RESTful입니다. 웹용으로 작성된 모든 도구는 비즈니스 프로세스를 이끌 수 있습니다. 별도의 로그 서버 배열에 비동기식으로 POST하여 대체 메시지 채널이 계속 있습니다.
잠시 동안 생각해 본 후, 휴식을 취하고 REST가 메시징 큐와 ESB의 필요성을 완전히 제거 할 수 있음을 깨닫기 시작합니다.
답변
메시지 대기열은 처리하는 데 시간이 오래 걸릴 수있는 요청에 이상적입니다. 요청은 대기열에 있으며 클라이언트를 차단하지 않고 오프라인으로 처리 할 수 있습니다. 클라이언트에게 완료 알림을 받아야하는 경우 클라이언트가 요청 상태를 주기적으로 확인하는 방법을 제공 할 수 있습니다.
메시지 대기열을 사용하면 시간이 지남에 따라 더 잘 확장 할 수 있습니다. 실제 처리가 시간에 따라 분산 될 수 있기 때문에 많은 활동의 버스트를 처리하는 능력이 향상됩니다.
메시지 대기열과 웹 서비스는 직교 개념입니다. 즉 상호 배타적이지 않습니다. 예를 들어, 메시지 큐에 대한 인터페이스 역할을하는 XML 기반 웹 서비스를 가질 수 있습니다. 나는 당신이 찾고있는 차이점은 Message Queues 대 Request / Response라고 생각합니다. 후자는 요청이 동 기적으로 처리 될 때입니다.
답변
메시지 대기열은 비동기식이며 배달이 실패하면 여러 번 재 시도 할 수 있습니다. 요청자가 응답을 기다릴 필요가없는 경우 메시지 큐를 사용하십시오.
“웹 서비스”라는 문구는 HTTP를 통한 분산 구성 요소에 대한 동기 호출을 생각합니다. 요청자에게 응답이 필요한 경우 웹 서비스를 사용하십시오.
답변
일반적으로 차단 작업에 대한 웹 서비스 (더 많은 코드를 실행하기 전에이 작업을 완료해야 함)와 비 차단 작업에 대한 메시지 대기열 (시간이 오래 걸릴 수 있음)을 원한다고 생각합니다. 기다릴 필요가 없습니다).
답변
