I. 소개

온라인 서비스 간 호출 지연이 있어 링크 트래킹을 통해 X 서비스가 요청을 보내고 Y 서비스가 약 1초 만에 요청을 받는 것을 알 수 있다. 손실 재시도, 그 과정에서 여전히 많은 문제가 있고 단계별로 방향을 확인하고 최종적으로 결론을 내리는 패킷 캡처 실험도 매우 흥미 롭습니다.

둘, 조사

1. 히스트릭스

의심되는 첫 번째 방향은 Hystrix 스레드 풀이 가득 차 있고 실행 시간이 상대적으로 길고 대기열이 대기 중이므로 지연이 있다는 것입니다.

x를 보내고 y를 받는 사이의 직접적인 간격은 1초이므로 대기열에서 기다리지 않을 것입니다. 그리고 스레드 풀이 실제로 꽉 차서 대기열이 그렇게 오랜 시간 동안 대기하는 경우 이 높은 확률로 인해 후속 요청이 융합되고 경보가 울립니다.

히스트릭스는 제외.

2、유레카

Eurkea의 대상 IP 획득도 의심되었는데, x-cache 레지스트리가 만료되어 eurkea에서 IP를 획득하는 속도가 느리지만 Hystrix와 마찬가지로 배제할 수도 있습니다.

3. 서비스 그리드

이 시점에서 우리는 운영 및 유지 관리 작업이 필요한 패킷만 캡처할 수 있으며 패킷 캡처는 여전히 롤링으로 처리되므로 개발자는 링크 추적을 주시하고 운영 및 유지 관리가 파일을 적시에 복사하도록 해야 합니다. 발생할 때.

코드와 미들웨어의 차원에서 그 이유를 찾을 수 있다면 기본적으로 패킷 캡처를 선택하지 않을 것이므로 너무 번거롭습니다.

서비스 메시는 서비스 간의 통신을 위한 컨트롤러입니다. Istio는 Google, IBM 및 Lyft에서 만든 서비스 메시의 오픈 소스 구현입니다.

Istio는 다음을 수행할 수 있습니다. 트래픽 관리. 서비스 간의 종속성과 서비스 호출의 흐름 방향을 가져옵니다. 서비스의 ID를 인증하고 서비스에 대한 트래픽을 보호하는 기능을 제공합니다.

x에서 127.0.0.1 로컬로 이동하는 것은 실제로 통신 서비스 그리드의 프로세스입니다.

따라서 서비스 요청 x->y는 실제로 x->x.Istio->y.Istio->y이므로 서비스 그리드 간의 통신 문제 또는 서비스와 로컬 그리드 간의 통신 문제가 있을 수 있으며, 그러나 tcp 패키지에서는 그렇지 않은 것처럼 보입니다. 다음 단계는 이유를 찾기 위해 tcp 메시지를 주의 깊게 확인하는 것입니다.