ZMQ pub/sub 신뢰할 수있는/확장 가능한 설계

Question

저는 ZMQ를 사용하여 pub/sub 아키텍처를 설계하고 있습니다. 나는 최대한의 신뢰성과 확장 성을 필요로하며, 제공되는 가능성들에서 길을 잃어 가고 있습니다.

현재 브로커가 연결되어있는 게시자와 구독자가 있습니다. 브로커는 게시자 용 프론트 엔드를 노출하는 간단한 전달자 장치이며 구독자 용 백엔드입니다.

브로커가 충돌하거나 연결이 끊어지면 케이스를 처리하고 전반적인 확장 성을 향상시켜야합니다.

좋아, 그래서 여러 브로커를 추가 생각, 발행인은 메시지를 보내 브로커 라운드 로빈 것입니다, 그리고 가입자는 모든 브로커에 가입 것입니다.

그런 다음 가능한 브로커 목록을 검색하는 방법이 필요했습니다. 따라서 브로커 목록을 제공하는 이름 서비스를 작성했습니다. 게시자와 구독자는 어떤 브로커에 연결할지이 서비스에 요청합니다.

또한 메인 이름 서비스가 실패 할 경우 신뢰할 수있는 이름 서비스 인 "lazy pirate"를 작성했습니다 (즉, 시도/재 시도).

코드베이스가 크기와 복잡성이 증가하지 않기 때문에 내가 잘못 설계하고 있다고 생각하기 시작했습니다. 나는 ZMQ가 제공하는 가능성의 정글에서 길을 잃었습니다.

라우터/딜러를 기반으로하는 것이 유용할까요?

대단히 감사합니다.

Answer 1

귀하의 질문에 직접 답할 수는 없습니다. 많은 가정에 근거하고 있기 때문에 직접 대답 할 수 없습니다. 그 중 많은 부분은 틀릴 수도 있습니다.

잘못된 접근 방식을 사용하고 있기 때문에 길을 잃어 가고 있습니다. 0MQ를 언어로 생각해보십시오. 아직 잘 모르는 언어입니다. "최대의 신뢰성과 확장 성"을 쓰려고하면 먼저 고질라의 구토로 끝날 것입니다.

그래서 가이드에서 사용하는 방법을 사용하십시오. 핵심 메시지 흐름에 대한 최소한의 솔루션부터 시작하여 제대로 작동하도록하십시오. 사용할 소켓의 종류에 대해 매우 신중하게 생각하십시오. 그런 다음 실제로 테스트 할 때마다 실제로 진행중인 작업을 이해할 수 있도록 점진적 개선을하십시오. 코드가 성장함에 따라 정기적으로 코드를 리팩토링하십시오. 안정된 최소 버전 1이 될 때까지 계속하십시오. 처음에는 "최대"를 목표로하지 마십시오.

마지막으로, 문제가 더 잘 이해되면 다시 처음부터 다시 시작하여 몇 가지 단계로 작업 모델을 작성하십시오.

완전히 문제를 지배하고 해결 방법을 찾을 때까지 반복하십시오.

Answer 2

대부분의 복잡성은 오류 발생시 브로커 서비스를 지속하려는 것으로 보입니다. 응용 프로그램 수준에서이를 해결하면 최고 수준의 유연성을 얻을 수 있지만 처음부터 다시 시작하려면 최대한의 노력이 필요합니다.

대신 응용 프로그램 수준에서 처리하는 대신 네트워크 수준에서 처리 할 수 ​​있습니다. 다른 간단한 네트워크 서비스처럼 브로커를 다루고 IP 페일 오버 메커니즘 (예 : 맥박 조정기/corosync, UCARP 등)을 사용하여 주 서버를 사용할 수 없게되면 보조 IP 주소로 가상 IP 주소를 실패하게 만듭니다.

네임 서비스가 필요 없기 때문에 게시자와 가입자가 크게 단순 해집니다. 그들은 단지 하나의 가상 IP 주소에 대해서 알 필요가 있습니다. ZMQ는 필요할 때 (즉, 장애 극복이 발생할 때) 서비스에 재 연결을 처리합니다.