Consul 클러스터에서 마이크로서비스의 반복 등록 문제 해결

더 이상 고민하지 말고 yaml부터 시작해 보겠습니다.

다중 서버 등록 방식으로 인해 consul 클러스터의 에이전트에 서비스를 등록할 때 문제가 있습니다. 오류 메시지가 나타납니다. 동일한 인스턴스 ID가 다른 노드에 반복적으로 등록됩니다. 이는 노드 수만큼 중복된 서비스 인스턴스가 있을 수 있다는 것을 의미하는 큰 함정입니다. 물론 실제로는 하나만 필요하므로 중복된 인스턴스를 삭제해야 하지만 실제 작업은 생각보다 간단하지 않습니다.

영사의 공식 문서에는 다음과 같은 설명이 있습니다:

에이전트는 로컬 서비스의 상태를 관리하고 로컬 서비스에 대한 업데이트를 서버에 전송하여 글로벌 카탈로그가 동기화됩니다.

일반적인 의미는 각 에이전트가 자체 노드에 등록된 서비스를 유지하고 이를 다른 서비스로 보내 글로벌 카탈로그에서 동기화한다는 것입니다.

이는 각 에이전트가 실제로 자신의 노드에 등록된 서비스를 유지한다는 의미입니다. 동일한 서버 이름과 인스턴스 ID가 서로 다른 노드에 등록되면 서로 다른 서비스로 간주되며 이는 당연한 일이 아닙니다. 각 인스턴스 ID는 고유한 것으로 간주되며 반복적으로 등록되면 덮어쓰게 됩니다. 실제로 영사 클러스터는 이와 같이 처리되지 않습니다. 덮어쓰기 작업은 동일한 노드에 등록된 경우에만 발생합니다. 이 설명은 정말 비밀스럽습니다. 따라서 이보다 더 간단할 수는 없습니다. 인터넷에는 관련 정보가 없으므로 모두 인식에 의존합니다.

따라서 consul은 실제로 서로 다른 매개변수가 필요한 두 개의 등록 인터페이스인 /agent/service/register 및 /catlog/register를 제공합니다. 자세한 내용은 consul 문서를 참조하세요.

이 아이디어에는 문제가 없지만 실제로는 함정이 많습니다.

먼저 consul에서 제공하는 삭제 서비스 API 인터페이스를 살펴보겠습니다.

1. /agent/service/deregister/:service_id

2. / 카탈로그/등록 취소

첫 번째는 괜찮아 보이지만 실제로는 그렇습니다. 고가용성을 고려하면 k8s에서는 서비스를 사용하여 모든 영사를 프록시하므로 로드 밸런싱이 이루어집니다. 현재 consul 서버 노드의 서비스를 삭제하고 다른 노드의 서비스는 삭제하지 않으므로 이 인터페이스를 직접 사용할 수 없습니다.

두 번째 인터페이스는 정상적으로 보입니다. 예 catlog를 통해 삭제합니다. 해당 노드의 서비스가 실제로 삭제되었습니다. 잠시 후 삭제된 서비스가 다시 나타납니다. 실제로 catlog의 캐시만 삭제되었을 뿐입니다. 실제 노드의 서비스는 삭제되지 않았습니다. .. 잠시 후 노드가 이 서비스의 정보를 동기화했습니다.

이때 이미 욕하고 싶었습니다. ! ! ! ! 직접 삭제한다는 생각은 먼저 포기하고 다른 해결 방법이 있는지 알아보는 수밖에 없습니다.

두 가지 주요 아이디어가 있습니다:

1. 너무 많으면 삭제

영사가 제공하는 인터페이스를 본 후 실제로 첫 번째 반응은 다음과 같습니다. 실제로 문제를 해결하려면 영사에서 제공하는 API 인터페이스를 통해 해결할 수 있습니다. 실제로 이 방법을 통해서만 해결할 수 있는 경우는 다음과 같습니다.

2. 등록하기 전에 확인하세요.

저는 springcloud를 사용하고 있기 때문에 등록 인터페이스만 다시 작성하면 됩니다

이 방법은 서비스를 로그아웃하기 위해 해당 에이전트의 인터페이스를 직접 호출해야 한다는 한계가 있는데, 이는 서비스가 에이전트에 직접 접근할 수 있어야 한다는 뜻이고, 그렇지 않으면 구현할 수 없다는 뜻이다.

위에서 언급한 것처럼 consul은 실제로 두 개의 등록 인터페이스를 제공합니다. 기본 인터페이스는 /agent/service/register이고 시간 문제로 인해 /catlog/register 인터페이스는 사용되지 않습니다. 나중에 시간이 나면 catlog 인터페이스를 통해 이 문제가 발생하지 않는지 테스트하겠습니다.