다중 계층 이기종 시스템의 REST 또는 메시지 큐?

Client application-> Front-end API cloud server-> 와 같은 3 계층 시스템을위한 REST API를 설계하고 user's home API server (Home)있습니다.

Home는 가정용 기기이며 Front-endWebsocket 또는 긴 설문 조사 를 통해 연결을 유지해야합니다 (이것은 우리가 REST를 위반하는 첫 번째 장소입니다. 나중에 더 악화됩니다) . Front-end대부분 연결 Client요청을 터널링 Home하고 일부 호출 자체를 처리합니다. 때때로에 Home알림을 보냅니다 Client.

Front-end와 Home기본적으로 동일한 API를 가지고; LAN을 통해 직접 Client연결되었을 수 있습니다 Home. 이 경우 자체 에 Home일부 Client작업 을 등록해야 Front-end합니다.

이 시스템에서 REST의 장점은 다음과 같습니다.

• REST는 사람이 읽을 수 있습니다.
• REST에는 CRUD와 같은 동사, 명사 및 응답 코드가 프로토콜 오브젝트에 올바르게 정의되어 있습니다.
• HTTP를 통해 작동하며 가능한 모든 프록시를 전달합니다.

REST 대조는 다음과 같습니다.

• 요청-응답 커뮤니케이션 스타일뿐만 아니라 발행-구독도 필요합니다.
• 3 계층 통신 오류를 처리하기에는 HTTP 오류 코드가 충분하지 않을 수 있습니다. 필요한 연결이 끊어 졌어 야한다는 것을 알기 위해 비동기 호출로 Front-end돌아갈 수 있습니다 .202 AcceptedHome503
• Home에 메시지를 보내야합니다 Client. Client폴링 Front-end하거나 연결을 유지해야합니다.

Websocket을 통한 WAMP / Autobahn 을 고려 하여 발행 / 구독 기능을 얻을 수 있습니다. 이미 메시지 대기열처럼 보입니다.

일종의 메시징 큐를 전송으로 평가할 가치가 있습니까?

메시지 대기열 대조는 다음과 같습니다.

• 메시지 수준에서 CRUD 동사와 오류 코드를 직접 정의해야합니다.
• "높은 유지 보수 비용"에 대한 내용을 읽었지만 그 의미는 무엇입니까?

이러한 고려 사항은 얼마나 심각합니까?

연결 상태 인 경우 특정 구조와 형식의 메시지를 보내려면 자체 프로토콜 (어려운 작업이 아님)을 정의해야하지만 메시지 대기열을 사용하십시오.

유지 보수의 문제점은 일반적으로 클라이언트와 서버가 개별적으로 빌드되므로 동일한 메시지 정의를 사용하여 양쪽 끝을 유지하도록주의해야하지만 충분히 구성되지 않은 경우 REST에서 사용하는 것과 동일한 XML을 사용하는 것입니다. 서비스.

인터넷을 통해 포트 80 및 http 만 있고 '단방향'통신으로 연결 문제가있는 경우 REST 스타일 시스템이 가장 좋습니다. 콜백 데이터를 보내거나 폴링하거나 웹 소켓을 가져 오지만 일반적으로 시스템을 클라이언트 / 서버로 설계하십시오. 연결을 할 수 있다면 메시징 시스템이 좋습니다.

내가 함께 갈 것 ZeroMQ 메시징 시스템을 위해, 그 구성에 충분한 내결함성을 포함한 시나리오의 모든 방식으로 비틀 수 있습니다. 그래도 http를 통해 작동 하는지 확실하지 않습니다 .

아우토반이 당신이하려는 일에 잘 맞는 것 같습니다. 사용 가능한 다른 도구도 있습니다. 아웃 확인 윈도우 Azure 서비스 버스 (자바, .NET, PHP, 파이썬, NodeJS, 루비에 대한 클라이언트 프레임 워크가 있습니다).

내장 된 휴식 메시지가 유용하지만. 응용 프로그램이 기본 CRUD 작업을 능가 할 것입니다. 예를 들어 응용 프로그램이 은행 시스템 인 경우를 예로들 수 있습니다. 대신에

계정 업데이트 54321 잔액 = 잔액-20.00 업데이트 계정 98765 잔액 = 잔액 + 20.00

아마도 하나의 메시지를 원할 것입니다.

계정 54321에서 계정 98765로 20.00 전송

나중에 지금이 아니라 REST로이 장애를 발견하는 것이 가장 좋습니다. 애플리케이션 내에서 메시징을위한 더 풍부한 모델을 작성하는 방법에 대해 설명하는 Greg Young의 이벤트 중심 을 확인하십시오 .