런타임에만 알려진 전이 종속성 충돌에 어떻게 접근합니까? [닫은]

일반적으로 대규모 소프트웨어 프로젝트에서 런타임에 발생하는 전이 종속성 문제에 어떻게 접근합니까?

지난 3 주 동안 소프트웨어의 다른 구성 요소 내에서 큰 소프트웨어 구성 요소를 시작하려고했지만 런타임에만 알려진 전이 종속성 문제로 인해 간헐적으로 죽습니다.

전 이적 의존성 문제는 특정 프로젝트의 종속성에 대한 특정 종속성이 런타임에 다른 종속성과 충돌하여 불안정성 또는 즉각적인 오류를 유발한다는 것을 의미합니다.

사용중인 수백 가지의 의존성에는 수백 가지가 있으며, 모든 모듈이 서로 밀접하게 중첩되어있는 다른 팀에 의해 독립적으로 작업되는이 도구와 관련된 약 50 개의 하위 프로젝트가 있습니다. 프로젝트의 규모와 복잡성을 감안할 때 모든 하위 프로젝트가 무엇에 사용되는지는 아무도 모릅니다.

이 상황에서 영향을받는 구성 요소의 각 종속성에 대한 DAG의 시각적 표현을 생성하고 런타임시 충돌이 발생할 수있는 위치를 결정하려고합니까? 다른 하위 프로젝트에서 종속성을 관리하는 방법을 제어 할 수 없으며 다른 개발자가 작성한 Java 코드를 변경할 수 없습니다

내가 제시 한 솔루션은 1 ~ 2 시간 동안 만 작동 한 다음 업스트림 구성 요소의 변경으로 인해 작동이 중지됩니다. 업스트림 구성 요소의 예로는 내가 작업하고있는 프로젝트가 CI 파이프 라인의 초기 단계에서 빌드 된 프로젝트에 의존하는 아티팩트가 있습니다.

다른 사람들의 요청에 , 나는 너무 많은 정보를 제공하기 위해 질문을 닫을 위험이 있거나, 신체가 너무 길어질 때 사용되는 기술에 대한 정보를 포함시킬 것입니다.

• Maven은 종속성 관리에 사용됩니다. 과
• 스프링은 DI 컨테이너로 사용됩니다.
• 대부분의 종속성 문제는 런타임에로드되는 다른 모듈의 컨텍스트 결과로 겹치는 Bean 컨텍스트와 관련됩니다.
• 제품이 제대로 작동하고 프로그램의 기능적 정확성을 피하기 위해 여러 가지 단위 테스트 및 통합 테스트가 있습니다.

일반적으로 주어진 프로젝트 종속성의 가능한 모든 조합을 열거하지 않고 종속성 충돌을 해결하는 방법을 식별하는 언어 독립적 인 방법을 찾고 있습니다 .

프로젝트를 다시 설계하거나, 추가 품질 게이트를 추가하거나, 회사 전체의 패러다임 전환을 추진하거나, 언어를 해결책으로 전환 할 수 없습니다.

사용자 정의 클래스 로더를 사용하여 애플리케이션의 각 모듈에 고유 한 실행 환경을 제공하여 문제점을 해결할 수 있습니다.

기본적으로, 응용 프로그램의 작은 커널과 보편적으로 합의 된 모든 종속성 및 모듈이 서로 통신하는 데 필요한 모든 인터페이스로 구성된 핵심 환경을 정의합니다. 그런 다음로드하는 각 모듈은 (1) 런타임 환경의 클래스, (2) 응용 프로그램 코어의 클래스 및 (3) 해당 모듈의 클래스 및 해당 직접 종속성에 액세스 할 수있는 자체 클래스 로더를 가져옵니다. 모든 모듈 간 통신은 코어에 정의 된 인터페이스를 통과하므로 다른 모듈에 직접 의존하는 모듈이 없습니다.

이 기술은 응용 프로그램 서버에서 응용 프로그램이 충돌 할 수있는 종속성을 갖도록하는 데 사용되므로 Tomcat과 같은 기술의 실제 구현을 볼 수 있습니다. 운이 좋으면 Tomcat을 사용할 수 있습니다. 거의 변경하지 않고 구현).

필자는 Maven 또는 Spring과 함께 일한 적이 없지만 일반적인 질문에 대한 일반적인 대답을 제공합니다. 종속성 문제와 관련하여 시스템은 가능한 한 가장 빠른 시점에 문제 를 감지하도록 설계되어야합니다. 가능한 원인을 포함하여 즉시 신호를 보내야합니다.

이상적으로이 시점은 "제작 런타임"이 아닙니다. 가장 좋은 시점은 "빌드 타임"이지만 귀하의 경우에는 불가능한 것 같습니다. 두 번째로 좋은 옵션은 런타임 테스트입니다. "통합 테스트"가 있지만 종속성 문제를 감지하지 못해 불완전하거나 일반적으로 종속성 충돌을 테스트하지 않습니다. 그곳에서 문제 해결을 시작해야합니다.

또한 테스트를보다 효과적으로 수행하려면 종속성 문제가 발생할 때 구성 요소가 "빠르게"실패 해야 합니다. 즉, 종속성이 해결되고 구성 요소가로드 되 자마자 잠재적 인 종속성 충돌을 확인하고 즉시 신호를 보내야합니다. 충돌이 감지되기 ​​전에 시스템이 처음 한 시간 동안 실행되면 문제의 원인을 파악하기가 매우 어려워집니다. Maven / Spring이 이미 내장 된 "실패"전략을 제공하는지는 모르겠지만, 그렇지 않은 경우에는 그 방향으로 생각하십시오.

생산 문제를 완화하려면 덜 중요한 하위 구성 요소와의 종속성 충돌이 발생할 때 시스템이 완전히 죽지 않도록 설계해야합니다. 물론 장애는 ​​가려져서는 안되지만 시스템은 이상적으로 해당 구성 요소의 로딩을 거부하고 문제를 기록 및 / 또는 신호를 보내 안정 상태를 유지해야합니다. 구성 요소가 먼저로드되면 시스템이 불안정 해지고 나중에 문제를 감지하면 시스템을 완전히 종료했다가 다시 시작해야 할 것이므로 피하고 싶을 것입니다.

예를 들어, 시스템이 웹 상점이고 "뉴스 레터 구독"에 대한 서브 모듈을 몇 시간 동안로드 할 수없는 경우 전체 상점이 더 이상 작동하지 않는 것처럼 더 쉽게 허용 될 수 있습니다.

마지막으로, 이것은 귀하의 경우 옵션이 아닐 수도 있지만 구성 요소를 서로 더 잘 격리하여 실행할 수 있고 종속성 충돌을 피할 수 있다면 고려해야 할 접근법 일 수 있습니다.

여기서 크게 생각하고 있다고 생각하십시오. 요구 사항 / 시간 제약 조건에 따라 다음을 고려할 수 있습니다.

1) 인터페이스 및 해당 구현 목록 작성 (사용 가능한 경우 리플렉션 사용)

2) DI 주위에 일종의 래퍼를 만듭니다. DI에 구체적인 구현을 요청하면 DI 규칙이 이미 있는지 확인하십시오. 규칙이 존재하면 DI가 제공하는 것을 반환하십시오. 그렇지 않으면 인터페이스의 단일 구현이 있고 인스턴스 로그를 생성하고 인스턴스를 반환 할 수있는 경우 그렇지 않으면 로그 및 실패.

어떻게 참여하고 싶은지에 따라, 아마도 당신은 무엇을 필요로하는지에 대한 완전한 목록을 원합니다.이 솔루션은 결국 그 목록을 생성합니다.

그러나 이것은 많은 작업이며 신뢰할 만하지 않습니다. 푸른 달에 한 번 특정 종속성이 필요한 이상한 조건이있는 경우 어떻게해야합니까?

"업스트림 구성 요소의 변경"이라고 할 때 무엇을 의미합니까?

내가 당신을 올바르게 따르면 문제는 사용하는 코드가 Spring XML로 표현 된 모듈에 런타임 의존성을 가지고 있지만 maven에 대해서는 알려지지 않았다는 것입니다. 따라서 그것들을 사용할 때 필요한 것들 (전 이적 의존성)은 클래스 패스에 없으며, 그들이해야 할 일을하지 않습니다.

동료에게 '어떻게 작동하게합니까?'라고 물 을 때 '35 개 모듈 및 버전 목록이 필요 합니다 . 어떻게 알 수 없습니까? '

아마도 통합 테스트가 완료되면 필요한 모듈이 테스트 종속성으로 선언됩니다. 따라서 체계적인 솔루션은 통합 테스트 폼에 대한 검사를 설정하여 테스트 종속성으로 선언 된 타사 테스트 도구가 없는지 확인하는 것입니다. 이것은 maven 집행자 플러그인에 의해 자동화 될 수도 있습니다 .

분명히 당신은 그렇게 할 수 없으므로 최선의 선택은 여기 에서 찾을 수 있습니다 .