느슨하게 연결된 마이크로 서비스 아키텍처에서 종속성을 어떻게 추적합니까?

현대적인 프로그램에서 널리 사용되는 고급 아키텍처는 REST 기반 마이크로 서비스 시스템입니다. 이는 느슨한 결합, 쉬운 재사용, 사용 가능한 기술 제한, 높은 확장 성 등과 같은 몇 가지 장점이 있습니다.

그러나 이러한 아키텍처에서 예상되는 문제 중 하나는 응용 프로그램의 종속성에 대한 가시성이 부족하다는 것입니다. 예를 들어 매일 한 세트의 REST 호출을 사용하는 애플리케이션이 있다고 가정 해 봅시다. 이 애플리케이션은 또한 두 번째 REST 호출 세트를 사용하지만 분기마다 한 번만 사용합니다. 지난 주에 로그를 스캔하면 모든 일일 계산이 표시되지만 분기 별 통화는 표시되지 않을 것입니다. 리팩토링 할 때가되면 분기 별 통화가 중단 될 위험이 높습니다.

이 위험을 줄이고 느슨하게 결합 된 아키텍처의 종속성에 대한 가시성을 높이기 위해 어떤 패턴이나 도구를 사용할 수 있습니까?

이 위험을 줄이기 위해 사용할 수있는 패턴 또는 도구

API 및 비즈니스 기능을 이전 버전과 호환되도록 유지하십시오.

느슨하게 결합 된 아키텍처의 종속성이 무엇인지 더 잘 파악

건강 검진.

내 서비스는 월별 API 기능에 대한 클라이언트입니다. 그러나 내 서비스는 내 서비스가 실행될 때마다 귀하의 API 클라이언트입니다. 따라서 내 서비스는 10 분마다 또는 그 밖의 모든 것이 월간 API에 연결되고 프로토콜을 실행하여 서비스에 필요한 기능을 계속 사용할 수 있는지 확인합니다.

따라서 로그에는 제공하는 각 특정 서비스가 실제로 얼마나 자주 사용되는지를 보여주는 것처럼 다른 서비스가 제공하는 각 특정 서비스가 여전히 사용 가능한지 확인하는 빈도가 표시됩니다.

종속성을 찾을 수있는 위치가 두 개 이상 있습니다.

• 구성. 외부 API에 액세스하려면 해당 API 각각에 대한 많은 정보를 알아야합니다. 액세스 ID, 비밀 키, 엔드 포인트 이 모든 수 와 같은 정보가 있기 때문에, 코드가 될 것이다 변경합니다. 예를 들어, 최근에 모든 마이크로 서비스를 SSL로 마이그레이션하기 시작했습니다. 이는 마이그레이션중인 서비스에 의존하는 모든 서비스가 https://대신 버전 을 가리 키도록 재구성되어야 함을 의미합니다 http://. 엔드 포인트가 하드 코딩되지 않고 구성에있어 기쁘다.

• 인터페이스. API 버전이 변경되고 다른 API로 전환하기로 결정할 수도 있기 때문에 코드에서 직접 서비스에 액세스하지 않습니다. 대신 추상화 계층을 만들고 인터페이스를 통해 종속성을 사용합니다. 해당 인터페이스를 작성할 때 공통 논리를 따르면 나중에 종속성을 검색 할 때 더 쉽게 생활 할 수 있습니다.

리팩토링 할 때가되면 분기 별 통화가 중단 될 위험이 높습니다.

이것이 회귀 테스트의 목적입니다.

코드를보고, 바꾸고, 아무것도 깨지지 않았다고 스스로 믿을 수는 없습니다. 마이크로 서비스 아키텍처에서는 작동하지 않습니다. 이것은 모 놀리 식 응용 프로그램에서도 작동하지 않습니다. 컴파일러는 코드를 수정할 때 발생하는 일부 오류를 포착 할 수 있습니다. Haskell과 같은 일부 언어에서는 컴파일러가 매우 유능하며 대부분의 오류를 포착 할 수 있습니다. 그러나 주류 언어를위한 컴파일러는 그다지 도움이되지 않습니다. 테스트가 없으면 문제가 해결 된 것입니다. 마이크로 서비스의 존재는 관련이 없습니다.

REST API는 느슨하게 지정되므로 어느 시점에서 gRPC, google protobufs 또는 Thrift로 이동하여 RPC 인터페이스를 정의한 다음 버전을 지정하는 것이 유용 할 수 있습니다.