Pub-Sub 패턴 및 메시지 브로커, 모든 구독자가 이벤트 작업을 완료했는지 확인하는 방법

더 많은 조사와 몇 시간 동안 침대에 누워 잠에서 깼다. 나는 게시자가 보낸 메시지의 상태를 추적하기 위해 응답 / 승인을 받고자하는 경우 한 주제 / 주제에 여러 구독자를 갖는 것은 나쁜 습관으로 간주되어야한다는 결론에 도달했습니다. 요청 / 메시지 / 이벤트.

몇 가지 더 생각한 끝에 동일한 주제에 대한 여러 구독 서비스가 거의 필요하지 않다는 결론에 도달했습니다. 적어도 서비스를 올바르게 설계하는 한 내 시나리오에서는 그렇습니다. 내가 생각할 수있는 유일한 시나리오는 이미 배포 된 서비스를 건드리지 않고 나중에 특정 기능을 추가하는 것입니다. 이것은 부적합한 서비스 디자인에 대한 수정처럼 느껴집니다.

그런 다음 어떻게 관리 할 수 ​​있을지 생각하고 3 가지 접근 방식을 생각해 냈습니다.

먼저 표준 구조

더 이상의 설명이 필요하지 않습니다. 일부 방법의 세부 사항은 신경 쓰지 마십시오. 확실히 이상적이지 않은 브레인 스토밍 버전입니다. 패턴을 표시하는 것으로 충분합니다.

접근 방식 1-Aggregator가 응답을 수집합니다.

브로커는 모든 구독자를 추적하기 때문에 예상되는 응답 수를 항상 알고 있거나 쉽게 계산할 수 있습니다. 따라서 응답 또는 성공 메시지가 필요한 메시지를 보내거나 게시 할 때 자동으로 생성되는 Aggregator Subject로 응답 메시지를 리디렉션 할 수 있습니다 (일부 고객 데이터의 업데이트를 생각해보십시오. 메시지가 통해 성공적으로 처리됨).

Of course, the Aggregator could always be inbetween even if there's just one response coming back. That'd reduce the amount of cases to cover. The Aggregator is basically some sort of proxy. It still adds complexity to the Broker though.

Approach 2 - Broker publishes acknowledge messages

First of all: don't mind the mess with the connections on the right. It works for me as a sketch but is far from tidy.

Every message that is being published is being answered with an acknowledge message by the Broker. That message is being put on the messages individual subject stack. Since the Broker knows how many Subscribers every Subject has, it can send back how many responses a Publisher should expect. Acknowledge messages in general are also usefull to notify Publishers wether their message/event/request was accepted or not as well (think of a authentication and authorization pattern here).

This will work as long as the Publisher always wants a response. If it doesn't messages could stick around for quite a while. A timeout could solve this.

Approach 3 - Transport Protocol Responses

This is very similar to approach 2 with the difference that the transport protocol is being used to inform the Publisher about the status of the sent request and the potential number of responses to expect.

Since most if not all protocols suitable for this kind of topography offer some way of response messages and since those should be used anyway to verify that the message has been successfully sent in the first place, the answer could also contain a payload informing the client not only about the successful transfer but also about how many responses to expect.

Conclusion

Aggregator 접근 방식은 오버 헤드가 너무 많고 전송 프로토콜이나 메시지 시스템 자체를 사용하는 것보다 더 많은 추가 코드가 필요하다고 말하고 싶습니다. Aggregator는 클라이언트가 서비스에 대해 완전히 알 수 없어서 분리되기 때문에 흥미 롭습니다.

메시지 시스템의 사용은 로깅 목적 (잠재적 디버깅) 및 Sagas 구현 (이벤트 체인)에서도 흥미 롭습니다.

노트

이러한 접근 방식을 모범 사례로 홍보하지 않습니다. 내 연구 결과로 내 질문에 답하고 싶습니다.