Kafka 아키텍처: 동기식에서 비동기식으로 [2]

오늘 우리는 귀하의 사례에 따라 동기식 애플리케이션 간의 통신을 보다 효율적으로 만드는 3가지 사례 중 두 번째 사례를 볼 것입니다.

이 솔루션은 데이터 보안이 강화되었으며 그 이유를 이해하게 될 것입니다.

두 번째 솔루션 - 모두가 솔루션을 읽습니다.

이론적으로 이 솔루션은 매우 쉽습니다.



이전 예에서와 같이 TOPIC REQUEST에 대한 요청을 보내고 TOPIC RESPONSE에 대한 응답을 기다리는 API X의 인스턴스가 2개 있습니다.

그러나 이번에는 API의 각 인스턴스에 자체 그룹이 있으므로 각 인스턴스가 각 메시지를 읽습니다.

따라서 API의 인스턴스 1이 http 요청을 수신하면 응답할 수 있습니다!

이것을 설정하는 방법?

ACL에서 API의 소비자 그룹에 대해 "접두사"를 정의합니다.

그런 다음 API의 각 인스턴스에 ACL에서 선언한 항목이 접두사로 붙은 고유한 소비자 그룹이 있는지 확인해야 합니다.

이 게시물에서 설명했듯이 Java에서는 매우 쉽습니다.

consumer_group: consumerGroupApiX${random.uuid}

이와 같이 서비스 인스턴스가 2개 또는 100개인지는 중요하지 않으며 각 포드에는 고유한 소비자 그룹이 있습니다.

장단점

장점
단점


첫 번째 솔루션보다 더 안전한 데이터 보안
서비스를 다시 시작할 때 여전히 문제가 있습니다.

각 API 인스턴스는 모든 메시지를 사용합니다.


데이터에 대해서는 더 안전하지만 프로세스가 길거나 요청량이 매우 많은 경우 첫 번째 솔루션과 동일한 문제가 발생합니다.

첫 번째 솔루션보다 이 솔루션의 장점은 확장 시 문제가 발생하지 않는다는 것입니다. 축소할 때 몇 가지 문제가 발생할 수 있지만 이를 제한하는 데 도움이 되는 몇 가지 솔루션이 있습니다.


마지막 부분에서 우리는 이런 종류의 문제를 피하기 위한 최상의 솔루션을 볼 것입니다!

그것이 당신을 도울 수 있기를 바랍니다! 🍺