Distributed Architecture Reconstruction of Polyglot and Multi-Repository Microservice Projects
Este artigo apresenta um novo framework para reconstrução de arquitetura estática distribuída que supera limitações existentes ao utilizar extratores modulares e específicos de tecnologia para unificar dados e gerar documentação precisa para projetos de microsserviços poliglotas e de múltiplos repositórios.
Artigo original sob licença CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). Esta é uma explicação gerada por IA do artigo abaixo. Não foi escrita nem endossada pelos autores. Para precisão técnica, consulte o artigo original. Ler aviso legal completo
Imagine que você tem uma cidade enorme e movimentada, composta por centenas de pequenos bairros independentes. Cada bairro (um microsserviço) é construído por uma equipe diferente, usando materiais diferentes (linguagens de programação) e seguindo seu próprio estilo único. Alguns são feitos de tijolo (Java), outros de madeira (Python) e outros de vidro (Go).
O problema? Ninguém tem um mapa completo da cidade. As plantas originais foram perdidas, estão desatualizadas ou foram escritas em uma linguagem que apenas os construtores originais entendem. Como esses bairros mudam muito rápido e são construídos separadamente, tentar desenhar um mapa gigante de toda a cidade de uma só vez é um pesadelo. Se você tentar olhar para a cidade inteira de uma vez, fica preso no trânsito e, se um bairro muda, você tem que redesenhar o mapa inteiro.
Este artigo apresenta uma nova ferramenta chamada ModARO para resolver este problema. Veja como ela funciona, usando analogias simples:
1. Os "Exploradores Especializados" (Extratores)
Em vez de contratar um robô gigante e superinteligente para entender todos os tipos de materiais de construção da cidade, os autores criaram uma equipe de exploradores especializados chamados Extratores.
- Como eles funcionam: Cada explorador é especialista em apenas uma coisa. Um explorador só sabe ler plantas de "Java". Outro só conhece contêineres "Docker". Outro só conhece arquivos de configuração "YAML".
- A Magia: Você não precisa ensinar o explorador de Java a ler Python. Você apenas envia o explorador de Java para o bairro de Java. Eles olham ao redor, encontram os detalhes importantes e os anotam em um bloco de notas padronizado.
- Sem Memória: Esses exploradores são "amnésicos". Eles não lembram do que viram no bairro anterior. Eles apenas olham para o edifício específico à frente deles naquele momento. Isso os mantém rápidos e evita que fiquem confusos.
2. O "Bloco de Notas Universal" (O Modelo)
Quando um explorador termina seu trabalho, ele não guarda as notas para si. Ele escreve as descobertas em um Bloco de Notas Universal (um modelo JSON).
- Este bloco de notas possui um formato específico com o qual todos concordam.
- Se o explorador de Java encontrar uma "porta" (um endpoint de API), ele a anota. Se o explorador de Python encontrar uma "janela" (uma conexão de banco de dados), ele anota isso também.
- Como todos usam o mesmo formato de bloco de notas, as informações do bairro de Java e do bairro de Python podem, eventualmente, ser combinadas.
3. O "Orquestrador" (O Algoritmo)
Existe um maestro (o Algoritmo de Reconstrução) que gerencia os exploradores.
- O maestro diz: "Ok, vamos olhar para este edifício".
- O explorador de Java verifica o edifício e adiciona as notas.
- O maestro vê que novas notas foram adicionadas e diz: "Ah, agora que sabemos que há um arquivo Java aqui, vamos chamar o explorador de Docker para ver se há um contêiner também".
- Isso acontece em um loop até que nenhuma informação nova seja encontrada. O maestro garante que, se dois exploradores tentarem escrever coisas contraditórias na mesma linha, o sistema pare e levante uma bandeira (um erro), para que os humanos possam corrigir, em vez de deixar o mapa bagunçado.
4. O "Mapa Distribuído" (Reconstrução Multi-Repositório)
Esta é a maior inovação do artigo. Antigamente, para desenhar um mapa, você tinha que reunir todas as plantas de cada bairro em uma única sala gigante e olhar para todas elas juntas. Isso é lento e quebra o "espírito independente" da cidade.
A nova abordagem é Distribuída:
- Trabalho Independente: Cada bairro desenha seu próprio mini-mapa enquanto constrói ou atualiza suas próprias casas. Eles não precisam esperar que os outros bairros terminem.
- A Montagem: Mais tarde, esses mini-mapas são trazidos e encaixados como peças de LEGO.
- As "Conexões Fantasmas": Às vezes, um bairro diz: "Nós enviamos correspondência para um lugar chamado 'Serviço-Teste'". Eles ainda não sabem o endereço ou o ID exato desse lugar porque ele está em outro bairro. O sistema permite que eles escrevam: "Enviar correspondência para qualquer um chamado 'Serviço-Teste'". Assim que todos os mini-mapas são encaixados, o sistema conecta os pontos automaticamente, combinando o remetente "Serviço-Teste" com o receptor "Serviço-Teste".
Por que isso é melhor?
- Sem "Tamanho Único": Você não precisa de um sistema complexo e frágil que tente entender todas as linguagens de programação de uma vez. Você apenas adiciona um novo explorador (extrator) sempre que uma nova linguagem aparece.
- Velocidade: Como cada bairro trabalha em seu próprio mapa, você pode atualizar o mapa de um serviço sem interromper a cidade inteira.
- Flexibilidade: Você pode usar ferramentas existentes. Se você já possui uma ferramenta que analisa código Java, basta envolvê-la em uma "roupa de explorador" e ela poderá se juntar à equipe.
Em resumo, este artigo constrói um sistema onde pequenas equipes especializadas podem documentar de forma independente suas próprias partes de um sistema complexo e, em seguida, costurar automaticamente essas peças em uma imagem completa e precisa de toda a arquitetura, sem precisar saber tudo sobre as outras partes enquanto trabalham.
Afogado em artigos na sua área?
Receba digests diários dos artigos mais recentes que correspondam às suas palavras-chave de pesquisa — com resumos técnicos, no seu idioma.