마이크로 서비스 아키텍처에서 대용량 파일 / 데이터 전송

22

우리 회사는 현재 마이크로 서비스 아키텍처 채택을 위해 노력하고 있지만 그 과정에서 약간의 고통 (충격)이 발생하고 있습니다. 우리가 직면하고있는 주요 경합 포인트 중 하나는 서로 다른 서비스간에 많은 양의 데이터를 전달하는 방법입니다.

약간의 배경 지식으로 회사 전체에서 처리해야 할 모든 문서의 저장소 역할을하는 문서 저장소가 있습니다. 상기 상점과의 상호 작용은 클라이언트에게 고유 ID 및 문서를 스트리밍 할 위치를 제공하는 서비스를 통해 수행된다. 나중에 제공된 ID로 조회를 통해 문서의 위치에 액세스 할 수 있습니다.

문제는 이것입니다-모든 마이크로 서비스가 문서와 상호 작용할 목적으로 API의 일부로이 고유 ID를 수락하는 것이 합리적입니까? 나에게 이것은 본질적으로 잘못된 느낌입니다. 서비스는 더 이상 독립적이지 않으며 문서 저장소의 서비스에 의존합니다. 필자는 이것이 API 디자인을 단순화하고 결과적으로 커플 링의 이점을 상쇄하는 것보다 성능이 약간 향상 될 수 있음을 인정합니다.

무지개 유니콘 (Netflix, Amazon, Google 등)이 서비스 간 대용량 파일 / 데이터 교환을 처리하는 방법을 아는 사람이 있습니까?

— 프리미엄 티어
소스

고 가용성 문서 / 파일 저장소에 무엇을 사용하고 있습니까?

— Terence Johnson

@TerenceJohnson 우리는 지금 집에서 만든 솔루션을 사용하고 있습니다. 우리는 고유 한 문서 ID와 위치 (불필요한 내부 네트워크 부담을 방지하기 위해 스트림이 아닌 클라이언트에 제공됨) 만 유지하는 RESTful Api를 활용하는 솔루션으로 마이그레이션하고 있습니다. 실제 지속성은 AWS를 통해 수행됩니다.

— PremiumTier

7

무지개 유니콘 (Netflix, Amazon, Google 등)이 서비스 간 대용량 파일 / 데이터 교환을 처리하는 방법을 아는 사람이 있습니까?

불행히도 나는 그들이 그러한 문제를 어떻게 다루는 지 모른다.

문제는 이것입니다-모든 마이크로 서비스가 문서와 상호 작용할 목적으로 API의 일부로이 고유 ID를 수락하는 것이 합리적입니까?

이는 마이크로 서비스 아키텍처의 본질적인 단일 책임 원칙을 위반합니다. 하나의 마이크로 서비스- 하나 를 나타내는 논리적으로 하나의 물리적으로 많은 인스턴스는 하나의 주제를 다루어야 합니다.

문서 저장소의 경우 문서에 대한 모든 쿼리가 이동하는 지점이 있습니다 (물론이 논리 단위를 여러 종류의 문서에 대해 여러 문서 저장소로 분할 할 수 있음).

"응용 프로그램"이 문서에서 작동해야하는 경우 해당 마이크로 서비스를 요청하고 결과를 처리합니다.
다른 서비스에 실제 문서 또는 그 일부가 필요한 경우 문서 서비스를 요청해야합니다.

우리가 직면하고있는 주요 경합 포인트 중 하나는 서로 다른 서비스간에 많은 양의 데이터를 전달하는 방법입니다.

이것은 건축상의 문제입니다.

대량의 데이터 전송 필요성 감소

이상적으로 각 서비스에는 모든 데이터가 있으며 단순히 요청을 처리하기 위해 전송할 필요가 없습니다. 이 아이디어의 확장으로서-데이터를 전송할 필요가 있다면, 중복성을 생각하십시오 (* 긍정적 인 방식으로) : 많은 곳에서 데이터를 중복시키는 것이 합리적입니까? 불일치가 프로세스에 어떤 영향을 줄 수 있는지 생각해보십시오. 실제로 없음 보다 더 빠른 전송은 없습니다 .
데이터 자체의 크기를 줄입니다

데이터 압축 방법을 생각해보십시오 . 실제 압축 알고리즘부터 스마트 데이터 구조 까지 시작 합니다. 전선을 적게 통과할수록 더 빠릅니다.

— 토마스 정크
소스

2

문서 저장소에서 리턴 한 ID 가 시스템 전체에서 문서를 참조 하는 방법 인 경우 서비스가 어떤 문서를 사용해야하는지 알아야하는 경우 모든 서비스가 API에서 '문서 ID'를 승인하는 것이 좋습니다.

이것이 반드시 필요한 것보다 서비스 사이에 긴밀한 연결을 만들 필요는 없습니다. 문서에 액세스해야하는 서비스는 문서 저장소 서비스에 액세스해야하며 상점에 액세스 할 문서를 알려주려면 해당 ID가 필요합니다.
문서에 직접 액세스하지 않는 서비스는 문서 ID를 전달해야 할 수도 있지만 이러한 서비스에는 종속성을 생성하지 않는 임의의 문자열 일뿐입니다.

— 바트 반 인겐시나 우
소스

당신의 답변에 감사드립니다. 또한 내부 문서 저장소를 활용하지 않으려는 외부 소비자에게 마이크로 서비스를 제공함으로써 잠재적으로 이익을 얻을 수 있다고 덧붙여 야합니다. 이를 염두에두고이 방법이 최선의 방법이라고 생각하십니까?

— PremiumTier

@PremiumTier : 예. 그러나 이러한 외부 고객은 내부 상점과 동일한 API를 지원하는 자체 상점을 제공하여 서비스가 협력 할 수 있도록해야합니다.

— Bart van Ingen Schenau

이해가 되긴하지만 서비스가 문서 참조 대신 스트림, 바이트 배열 또는 json blob을 허용하는 것보다 여전히 번거 롭습니다. 이 경우 후속 서비스를 호출하기 전에 '어댑터'서비스를 먼저 호출하여 파일 스트림을 확보 할 수 있습니다. 나는 논쟁의 여지가 아니라 오히려이 접근법의 장점을 이해하려고 노력하고 있습니다 :)

— PremiumTier

2

개인적으로 별도의 문서 저장소 서비스와 문서 ID를 사용하지 않고 적절한 헤더 인증으로 문서에 액세스하기위한 URL을 사용하고 싶습니다. 이 접근 방식을 사용하면 문서 서비스에 의존하기 위해 다른 서비스가 필요하지 않고 전체 URL을 사용하여 문서에 액세스 할 수있을뿐만 아니라 확장과 관련하여 여러 문서 저장소를 사용할 수 있습니다. 스토리지가 커지고 URL을 제공 할 때

그러나 문서를 업로드하고 URL을 얻으려면 서비스가 필요할 수 있습니다.

— 낮은 비행 펠리컨
소스

1

무지개 유니콘 (Netflix, Amazon, Google 등)이 서비스 간 대용량 파일 / 데이터 교환을 처리하는 방법을 아는 사람이 있습니까?

Amazon S3 REST API 사양을 확인하면 전체 객체를 바이트 단위로 반환하는 것 같습니다. 마이크로 서비스를 설계하는 경우 많은 옵션이없는 것 같습니다. Amazon S3 응답 형식 링크

— 확실한
소스