다운되거나 다운되는 서비스를 돕는 데 사용할 수있는 디자인 패턴이나 실습이 있습니까?
마이크로 서비스가 3 개 있는데 그 중 2 개가 양호하고 하나가 POST 도중에 죽으면 어떻게합니까? 2 개는 POST를 받고 1 개는 그렇지 않습니다. 요청을 서비스로 배송하기 때문에 거래를 할 수 없다고 생각합니다.
이를 위해 어떻게 설계합니까? 다양한 데이터베이스에서 고아 데이터를 원하지 않습니다.
6
해결해야 할 간단한 문제는 아닙니다. 나는 서비스에 대한 대기열 (최종 일관성)로 구현되는 것을 보았습니다. 대부분 귀하가 서비스를 제어하지 못하고 거래 관리자 또는 거래 기능을 부과하는 것은 기껏해야 쓰레기 처리이며 아마도 좋은 생각은 아닙니다. SOA 환경에서. 나는 주로 당신이 당신의 목적지에 연결되어 있거나 연결되어 있지 않을 수있는 모바일 푸시 주변에서 이것을 보았습니다.
—
Mike
마이크로 서비스에 대한 산성은 까다로운 너트이며, 또 다른 옵션은 redis publish / subscribe 또는 대기열 디자인을 사용하고 인바운드 채널에서 한 번 게시 한 다음 버스 서비스, 서비스 프록시가 대상에 푸시되어 성공을보고하는 일종의 버스 일 수 있습니다. 실패. 실패를 모니터링하고 그에 대한 흐름도 필요합니다. 트랜잭션이 한 서비스에서는 유효하지 않지만 다른 두 서비스에서는 유효하지만 실패해야 할 또 다른 실패 흐름에서는 실패 할 수도 있습니다.
—
Tim Cederquist
"큐 관리자"와 같은 것을 사용하지 않습니까? Redis가 병목 현상을 일으킬 것이라고 생각합니까? 아니면 적어도 잠재력도 높습니까? 나는 당신이 설명한 것 외에 다른 방법을 알고 있습니다.
—
johnny
데이터 흐름의 양에 따라 성공이보고 될 때까지 전송을 재 시도하거나 실패한 알림을 게시하고 중단에 대한 SMS 경보를 보내는 큐 관리자를 구현했습니다. 나는 그것이 예상되는 정전 기간에 약간 의존 할 것이라고 생각합니다 (얼마나 오래).
—
htm11 시간
이것이 rabbitmq와 같은 것입니까?
—
johnny