마이크로 서비스에서 개인 파일을 처리하는 방법

Question

우리는 백엔드 프로젝트를 진행하고 있으며 마이크로 서비스 개발로 이동하기 시작했습니다. 이미 몇 가지 서비스가 있습니다. 그 중 하나는 파일을 저장하고 가져 오는 FileService입니다 (기본 Amazon S3 스토리지 사용). 또한 FileService는 파일 체크섬, 인증 및 재시도 메커니즘을 제공하며 서비스와 클라이언트간에 파일을 공유하는 데 사용됩니다.

이제 우리는 새로운 서비스를 만들고 있습니다.이 서비스의 개인 데이터의 일부는 서비스가 저장하고 비즈니스 로직을 위해 사용하는 파일입니다. 우리는 FileService를 사용하여 파일을 저장하거나 가져와야하는지의 딜레마가 있습니다. 서비스 내에서 파일의 저장 및 페치를 처리합니다.

FileService를 사용하는 이유는 무료 (재시도, 체크섬 등) 서비스에 구현 된 모든 기능을 얻는 것입니다. 사용하지 않는 이유는 새 서비스가 자율적으로 작동하고 FileService를 사용하여 새 서비스를 연결하기를 원하기 때문입니다 (파일을 가져 오거나 업로드하기 위해 OAuth2 인증을 처리해야하며 FileService와 AuthService를 배포해야합니다. 이 서비스는 배포됩니다.

저는 개인이 마이크로 서비스 환경에 개인 파일을 저장하는 가장 좋은 방법이 있는지 알고 싶었습니다. 장단점이있는 가장 좋은 방법은 무엇입니까?

Answer 1

in-process FileService 구성 요소를 마이크로 서비스로 변환하면 단점은 물론 장점이 있습니다. 몇 가지를 나열했지만 가장 중요한 것은 귀하의 비즈니스 및 도메인에 적용 가능한 비용/혜택 분석 매트릭스를 작성해야한다는 것입니다. 여기에는 "모범 사례"접근법이 없습니다.

비용 :

• 당신이 응답 시간을 증가하는 괜찮습니다? 이제는 파일을 두 번 전송해야하기 때문에 : s3 -> fs 마이크로 서비스 -> 클라이언트 마이크로 서비스
• 노드 간의 연결이 끊어 질 가능성이 얼마나 되는가?
• 파일의 크기는 얼마나됩니까? 마이크로 서비스 간의 신뢰할 수없는 연결이 문제가 될 수 있습니까?
• 얼마나 자주 해당 파일에 액세스해야합니까? 로컬 캐시를 사용하여 프로세스 속도를 향상시킬 수있는 능력을 잃을 수 있습니까?
는

장점을 구현하고 별도의 인증의 microservice을 지원하거나 당신의 방화벽에서이 서비스를 허용 목록에 당신 괜찮아 :

• 모든 종속 구성 요소마다 재배치 필요가 없습니다 파일을 저장하거나 재 시도를하는 논리가 변경됩니다.
• 앞으로 재배포하지 않고도 다른 클라우드 제공 업체로 이동할 수 있습니다 (필요한 경우).
• 는 다른 구성 요소가 서로 다른 기술 스택
을 사용하여 구현 될 수있다 이기종 환경에서 재사용

결론 :

실제로 비즈니스 사람과 논의 위험과 이야기하지 않고 그 질문에 대답 할 수있는 방법이 없습니다 그러한 변화를 둘러싼.