Skip to main content

Microsserviço 3

· 3 min read
Leandro Andrade
Leandro Andrade
Software Developer

Os microsserviços não são o fim, são o meio. A decisão de usar microsserviço deve ser consciente, racional. A ideia deve ser ir para microsserviço somente se não puder evoluir ou encontrar limitação na arquitetura atual. Pense primeiro no simples: o que pode ser feito com o que temos atualmente antes de considerar microsserviço?

Migração gradual

A migração para microsserviço deve ser feita de forma gradual. Assim, uma abordagem big bang resultará em um big bang. Comece separando pequenas partes do monolítico, pois assim terá tempo de conhecer os microsserviços, o impacto será limitado caso ocorra algo errado e terá tempo para aprender com os erros.

Assim, inicie com algo pequeno e evolua gradualmente.

Decompor monolítico em microsserviço de modo prematuro pode ser muito custoso quando o domínio do negócio for novo para o time, pois a definição de fronteiras será um grande desafio. Entretanto, decompor um sistema existente em microsserviço torna-se mais fácil do que adotar microsserviço desde o início do projeto.

Agora, entendendo o contexto, um bom ponto de partida para separação de funcionalidades do monolítico para microsserviço seria identiticar as partes mais voláteis da base de código. Claro que pode acontecer de algumas funcionalidades estarem tão acopladas no monilítico que torna-se impossível realizar essa separação. Logo, a decisão sobre qual funcionalidade deve ser separada será um equilíbrio entre facilidade de extração versus vantagem de extrair o microsserviço.

Decomposição

Antes de sair migrando tudo, uma análise entre código e dados precisa ser realizada a fim de verificar a viabilidade da migração, pois caso seja possível migrar o código, mas ficar evidente que não é possível migrar os dados, poderíamos ter um problema.

Os padrões que podem ser utilizados para decomposição são:

  • estrangulamento (stranger fig): encapsula o sistema antigo e o sistema novo permmitindo que o sistema novo assuma cada vez mais o controle das funcionalidades do sistema antigo. Dependendo da funcionalidade solicitada, a chamada será interceptada e direcionada para o sistema antigo ou para o sistema novo.
  • execução paralela: executa tanto o monolítico, quanto o microsserviço, lado a lado, atendendo as mesmas requisições, comparando os resultados.
  • feature flag: permite ativar ou desativar uma funcionalidade on-demand.

Ao decompor o sistema monolítico, algums problemas tornar-se-ão evidentes:

  • desempenho: joins que antes eram feitos no banco de dados, agora serão feitos dentro dos microsserviços, o que gera aumento de latência. Assim, pode ser necessário adotar estratégias para otimimzar às consultas com uso de caching.
  • integridade dos dados: como agora os dados estão distribuídos em bancos de dados diferentes, não temos como garantir a integridade e relacionamento dos dados que antes eram garantidos pelo SGBD. Assim, estratégias de soft delete serão realidade.
  • transações: com os dados separados em diferentes bancos de dados, não temos ACID nas transações.

Ao iniciar à adoção da arquitetura de microsserviço, tenha claro o que se espera alcançar. Crie um ciclo de alteração, faça o rollout, avalie e repita.