Transferência grande de arquivos / dados em uma arquitetura de microsserviço

Minha empresa está atualmente trabalhando na adoção de uma arquitetura de microsserviço, mas estamos enfrentando algumas dores de crescimento (choque!) Ao longo do caminho. Um dos principais pontos de discórdia que enfrentamos é como comunicar grandes quantidades de dados entre nossos diferentes serviços.

Como pano de fundo, temos um repositório de documentos que serve como repositório para qualquer documento com o qual possamos precisar lidar com toda a empresa. A interação com a referida loja é feita através de um serviço que fornece ao cliente um ID exclusivo e um local para transmitir o documento. A localização do documento pode ser acessada posteriormente através de uma pesquisa com o ID fornecido.

O problema é este: faz sentido que todos os nossos microsserviços aceitem esse ID exclusivo como parte de sua API para fins de interação ou não com documentos? Para mim, isso parece inerentemente errado - os serviços não são mais independentes e dependem do serviço da loja de documentos. Embora reconheça que isso pode simplificar o design da API e talvez até ter alguns ganhos de desempenho, o acoplamento resultante mais do que contrabalança os benefícios.

Alguém sabe como os unicórnios do arco-íris (Netflix, Amazon, Google, etc.) lidam com grandes trocas de arquivos / dados entre seus serviços?

Alguém sabe como os unicórnios do arco-íris (Netflix, Amazon, Google, etc.) lidam com grandes trocas de arquivos / dados entre seus serviços?

Infelizmente, não sei como eles lidam com esses problemas.

O problema é este: faz sentido que todos os nossos microsserviços aceitem esse ID exclusivo como parte de sua API para fins de interação ou não com documentos?

Ele viola o princípio de responsabilidade única, que deve estar inerentemente na arquitetura do seu microsserviço. Um microsserviço - logicamente um, fisicamente muitas instâncias representando um - deve estar lidando com um tópico .

No caso do seu repositório de documentos, você tem um ponto em que todas as consultas de documentos ocorrem (é claro que você pode dividir essa unidade lógica em vários repositórios de documentos para vários tipos de documentos).

• Se o seu "aplicativo" precisar trabalhar em um documento, ele solicitará o respectivo microsserviço e processará seus resultados.

• Se outro serviço precisar de um documento real ou de partes dele, ele deverá solicitar ao serviço de documentos.

Um dos principais pontos de discórdia que enfrentamos é como comunicar grandes quantidades de dados entre nossos diferentes serviços.

Este é um problema de arquitetura:

1. Diminuir a necessidade de transferir grandes quantidades de dados

   Idealmente, cada serviço possui todos os seus dados e não precisa de transferência para simplesmente atender às solicitações. Como uma extensão dessa idéia - se você precisar transferir dados, pense em redundância (* de maneira positiva_): faz sentido ter os dados redundantes em muitos lugares (onde eles são necessários)? Pense em como possíveis inconsistências podem prejudicar seus processos. Não há transferência mais rápida do que realmente nenhuma .

2. Diminuir o tamanho dos próprios dados

   Pense em como você pode compactar seus dados: começando com algoritmos de compactação reais até estruturas de dados inteligentes . Quanto menos o fio passar, mais rápido você será.

Se o ID retornado pelo seu repositório de documentos é a maneira de fazer referência a documentos em todo o sistema, faz sentido que todos os serviços aceitem esse 'ID do Documento' em sua API quando o serviço precisar saber com qual documento ele deve trabalhar.

Isso não cria necessariamente um acoplamento mais estreito entre os serviços do que o necessário. Os serviços que precisam acessar documentos precisam acessar o serviço de armazenamento de documentos de qualquer maneira e precisam desse ID para informar à loja qual documento acessar.
Os serviços que não acessam documentos diretamente podem precisar repassar a ID do documento, mas para esses serviços seria apenas uma sequência arbitrária que não cria uma dependência.

Pessoalmente, prefiro não usar um serviço de armazenamento de documentos e uma identificação de documento separados, mas uma URL para acessar os documentos (com autenticação de cabeçalho adequada). Com essa abordagem, você não precisará de outros serviços para confiar no serviço de documentos, mas pode usar a URL completa para acessar o documento.E também faz sentido quando se trata de dimensionar também, você pode usar vários armazenamentos de documentos quando o armazenamento aumentar e fornecer o URL.

No entanto, você pode precisar de um serviço para fazer upload de um documento e obter seu URL.

Alguém sabe como os unicórnios do arco-íris (Netflix, Amazon, Google, etc.) lidam com grandes trocas de arquivos / dados entre seus serviços?

Confira as especificações da API REST do Amazon S3, aparentemente elas retornam o objeto completo em bytes. Parece não haver muitas opções se você estiver projetando um microsserviço. Link de formato de resposta do Amazon S3