Microsserviços e bibliotecas compartilhadas


9

Estamos projetando um sistema baseado em microsserviços independentes (conectados via um barramento RabbitMq). O código (pelo menos para os primeiros componentes) será escrito em python (python2 e python3). Já temos um aplicativo monolítico implementando parte da lógica de negócios, que queremos refatorar como microsserviços e estender. Uma pergunta que me preocupa é:

Qual é a melhor maneira de compartilhar código entre os diferentes microsserviços. Temos funções auxiliares comuns (processamento de dados, log, análise de configuração, etc.), que devem ser usadas por vários microsserviços.

Os próprios microsserviços serão desenvolvidos como projetos separados (repositórios git). As bibliotecas comuns também podem ser desenvolvidas como um projeto independente. Como compartilho essas bibliotecas entre os microsserviços?

Eu vejo várias abordagens:

  • copie a versão da biblioteca necessária para cada microsserviço e atualize conforme necessário
  • libere as bibliotecas comuns para um PyPi interno e liste essas bibliotecas como dependências nos requisitos do microsserviço
  • incluir o repositório da biblioteca como um submódulo git

Gostaria de ler um pouco mais sobre abordagens sugeridas, melhores práticas, experiências passadas antes de decidir como proceder. Você tem alguma sugestão ou link?


Eu não sou versado o suficiente em microsserviços (minha empresa recentemente começou a fazer algo semelhante) para responder, mas aqui está um link para uma apresentação sobre por que o que você está descrevendo é uma bandeira vermelha e pode levar a um "monólito distribuído" . Os microsserviços não devem ter exigido bibliotecas compartilhadas. Eles realmente só devem se comunicar entre uma API bem definida como o Swagger (agora chamada Open API ).
Capitão Man

@ CaptainMan: Claro, mas digamos que você tenha essa função simples: fib(n)(implementação da série fibonacci). Você não deseja repetir essa implementação em cada microsserviço. Pertence a uma utilsbiblioteca (com versão, para recursos e correções). Esse não é um monólito distribuído, é apenas uma camada de funcionalidade comum. Minha pergunta é como lidar com essa camada no nível de implementação?
precisa saber é o seguinte

Nossos microsserviços compartilharam bibliotecas para garantir que eles conversem com todos os outros microsserviços em nosso sistema da mesma maneira. Não tenho certeza de como seria possível fazer isso com bibliotecas não compartilhadas; no mínimo, todos precisariam de algumas bibliotecas de manipulação XML / JSON / etc. Ainda não assisti à apresentação, mas você tinha um significado mais específico de "biblioteca compartilhada" em mente do que o que estou pensando?
Ixrec 15/04

11
@ jeckyll2hide Estamos usando C ++, mas nossa infraestrutura para isso é aproximadamente equivalente ao seu segundo ponto: repositório separado, todos declaram suas dependências, sistema de compilação padrão que sabe como encontrar essas dependências no momento da compilação, etc.
Ixrec

11
Sinto-me um idiota, sua pergunta não é realmente sobre microsserviços que compartilham bibliotecas especificamente, é realmente perguntar sobre como compartilhar as bibliotecas de sua equipe com a equipe. Eu sei o suficiente sobre isso para postar uma resposta.
Capitão Man

Respostas:


5

Sua segunda opção é definitivamente o caminho a percorrer. Divida as bibliotecas comuns e instale-as no servidor PyPi local.

A opção 1 é horrível, porque será difícil propagar melhorias nas bibliotecas para outras pessoas que possam usá-la.

A opção 3 é semelhante à opção 1.

O padrão comum é configurar o Jenkins para que, quando você passar para o mestre de um repositório de biblioteca, ele crie uma compilação python e faça o upload automaticamente para o repositório PyPi. Depois de escrever esse script de construção, você nunca precisará se preocupar com as bibliotecas de empacotamento e com o upload manual delas no PyPi. E com esta opção, todas as atualizações da biblioteca estarão instantaneamente disponíveis para serem possivelmente atualizadas em outros microsserviços.

A configuração do seu próprio servidor PyPi é muito fácil. Eu gosto deste guia


11
Concordo que a opção 2 é a melhor, mas a opção 3 com os submódulos tem muito mais em comum com a opção 2 do que a opção 1.
8bittree

@ 8bittree: sim, a opção 3 é semelhante à opção 2, mas o servidor git (o controle remoto "central") é o mecanismo de distribuição de pacotes. Por um lado ele está usando git de algo não ment (gerenciamento de dependência), por outro lado, reduz o número de componentes (não há necessidade de PyPI privada)
dangonfast

2

Não é um cara Python, mas o servidor PyPi parece a melhor opção. Uma rápida pesquisa no Google parece que é análogo a um repositório Nexus para os jars Java da equipe.

Desde que esteja sendo implantado em algum tipo de repositório central (para o escritório / equipe) com o qual sua ferramenta de gerenciamento de dependência pode trabalhar (ler e implantar), é uma boa opção.

A opção 1 é realmente a pior, você nunca deve ter que lidar manualmente com dependências. É uma dor. Na faculdade, antes que eu soubesse sobre Maven, e quando pensei que o Git era muito complicado, fizemos tudo manualmente, desde a fusão do código de todos até a criação de caminhos de classe, passando pelas dependências. Foi uma dor, eu seriamente não gostaria que ninguém passasse por uma fração desse problema, especialmente em um ambiente de trabalho onde a eficiência é importante.

A opção 3 provavelmente funcionaria bem, mas não possui benefícios reais em relação a um PyPi local (além de talvez ser mais fácil de configurar, mas os benefícios de um sistema de gerenciamento de dependências real são muito melhores).


1

Antes de tudo, dividir um monólito em microsserviços sempre será difícil. Consulte Gerenciamento de dados descentralizado - encapsulando bancos de dados em microsserviços para ter uma idéia do porquê.

Dito isto, existem várias receitas de como fazê-lo de forma relativamente saudável. Um deles é http://12factor.net/ . Quem diria que você deve manter cada biblioteca e aplicativo independentemente e depois gerenciar explicitamente as dependências. Se você seguir esse caminho, recomendo vivamente que você tenha um comando simples que atualize todas as dependências para o que estiver atual e execute-o regularmente para cada microsserviço. É importante ter um processo de versão sensato em que você bloqueia versões de bibliotecas em produção. No entanto, você realmente, realmente , realmente não quer estar em uma posição em que as dependências ficam obsoletas e você não sabe o que está por aí.

Também se concentre em tornar suas bibliotecas de apoio o mais restritas e focadas possível. Sempre haverá uma atração natural para começar a adicionar itens às bibliotecas principais para facilitar o compartilhamento. Faça isso e você rapidamente puxará toda a bola de espaguete existente para as bibliotecas compartilhadas e voltará efetivamente à bagunça que você tem agora. Portanto, é melhor corrigir em sentido contrário.


0

Você deve poder ficar sem servidor apontando diretamente de um arquivo de dependência de pacote Python para os repositórios particulares do GitHub que contêm as bibliotecas. Pipenv e Poeta apoiam isso, acredito.

Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.