Microsserviços são uma forma de dividir um aplicativo grande em módulos fracamente acoplados que se comunicam entre si por meio de uma API simples.
Ultimamente, só pessoas burras não falam sobre microsserviços. Isso está se tornando cada vez mais popular. O estilo arquitetônico modular parece particularmente adequado para ambientes baseados em nuvem e está crescendo em popularidade. Antes de entrarmos em detalhes, vamos dar uma visão geral de tudo . Portanto: Microsserviços são uma forma de dividir um grande projeto em módulos pequenos, independentes e pouco acoplados. Módulos independentes são responsáveis por tarefas claramente definidas e discretas e comunicam-se entre si através de uma API simples e acessível. Em outras palavras, os microsserviços são simplesmente um estilo de arquitetura diferente para projetar aplicações complexas, principalmente da Web. Mas o que há de tão ruim nas soluções arquitetônicas existentes, como SOA (arquitetura orientada a serviços)? A maioria das soluções empresariais modernas escritas em SOA parecem funcionar muito bem. Este pode ser um ótimo momento para falar sobre alguns dos desafios que a indústria enfrenta atualmente... Vamos começar com um exemplo simples. Digamos que eu precise executar um aplicativo clássico escrito em Java. Primeiro desenvolverei a Interface do Usuário, depois a camada de lógica de negócio, com diversos componentes que irão interagir com a UI, e por fim a camada de banco de dados, que será acessível ao banco de dados persistente. Agora conforme desejo rodar a aplicação, irei criar um WAR/EAR/JAR e montá-lo em um servidor (como JBoss, Tomcat ou WebLogic). Como tudo isso é feito em um só lugar, obtenho um aplicativo monolítico, o que significa que todos os componentes estão em um só lugar... Exemplo na imagem:
Muito provavelmente, você já está familiarizado com esta abordagem e já a utilizou, mas a ideia é usar este exemplo para mostrar quais desafios os desenvolvedores terão que enfrentar ao usar esta solução arquitetônica. Aplicação monolítica: desafios desafios
À medida que o aplicativo cresce, aumenta também a quantidade de código escrito, o que pode sobrecarregar o ambiente de desenvolvimento toda vez que você precisar abri-lo. Isto definitivamente reduz a eficiência do desenvolvedor.
Como tudo tem que ser montado em um só lugar, isso faz com que mudar para outra linguagem de programação ou mudar para outras tecnologias seja um grande problema. Por exemplo, você escreveu um aplicativo em Java e, depois de um tempo, Kotlin foi lançado e você estava ansioso para reescrevê-lo, porque foi promovido como mais legal, melhor e mais rápido. Com um aplicativo monolítico, até mesmo pensar em refatorar causará muita dor, sem mencionar o processo em si. Atualmente existem muitas aplicações feitas desta forma e a quantidade de linhas de código é simplesmente incrível.
Se algum dos componentes parar de funcionar por qualquer motivo , todo o aplicativo também travará. Imagine que existe uma aplicação web que possui módulos como autorização, pagamento, histórico, etc. E por algum motivo um deles quebra. Isto é simplesmente um choque para os negócios e, consequentemente, para os desenvolvedores.
O dimensionamento de um aplicativo monolítico só pode ser alcançado criando outro aplicativo do mesmo tipo. Mas e se você precisar dimensionar apenas um componente e não o aplicativo inteiro? Quantos recursos serão desperdiçados?...
Isso pode ter um grande impacto no processo de desenvolvimento e instalação do aplicativo. Quanto maior o aplicativo, mais importante é que os desenvolvedores possam dividir o aplicativo em partes funcionais menores. Como todos os módulos em um aplicativo monolítico estão conectados entre si, os desenvolvedores não podem trabalhar/montar esses módulos independentemente uns dos outros. Como os desenvolvedores dependem uns dos outros, o tempo de desenvolvimento aumenta.
Ao mesmo tempo, estamos prontos para considerar e compreender o significado dos microsserviços, nomeadamente como podem ser utilizados para restaurar a flexibilidade que foi perdida com o estilo SOA. Deus Microsserviços ao resgate Uma das características mais importantes em qualquer solução arquitetônica é a escalabilidade. Enquanto eu estava aprendendo microsserviços pela primeira vez, vi que tudo era muito parecido com citações do livro “A Arte da Escalabilidade”. Este é um ótimo começo e lugar para discussão. Este livro define o chamado modelo "Cubo de Escalabilidade", que descreve um sistema de escalabilidade tridimensional:
Como você pode ver, o eixo X descreve o "escalamento horizontal" (que vimos também está disponível para arquiteturas monolíticas), o eixo Y representa o escalonamento no sentido de separar diferentes componentes de serviço . A ideia do eixo Z é entendida quando os dados são divididos e a aplicação envia solicitações exatamente para onde os dados estão localizados. Ou seja, eles não estão todos no mesmo lugar. A ideia do eixo Y é aquela que focaremos com mais detalhes. Este eixo representa uma decomposição funcional . Nesta estratégia, diferentes funções podem ser consideradas serviços independentes. Portanto, ao montar o aplicativo inteiro somente quando tudo estiver pronto, os desenvolvedores podem montar serviços individuais independentemente uns dos outros e não esperar que outros terminem de trabalhar em seus módulos. Isso não apenas melhorará o tempo de desenvolvimento, mas também oferecerá flexibilidade para alterar e religar sem ter que se preocupar com o restante dos componentes do aplicativo. Vamos comparar este diagrama com o monolítico anterior:
Microsserviços: benefícios Os benefícios dos microsserviços parecem ser suficientes para convencer desenvolvedores empresariais como Amazon, Netflix e Ebay a começarem a usar essa abordagem. Ao contrário dos aplicativos arquitetônicos monolíticos, os microsserviços:
Melhora o isolamento de falhas de componentes: Aplicativos grandes podem continuar a funcionar com eficiência mesmo se um único módulo falhar.
Elimina o compromisso do aplicativo com uma pilha de tecnologia: se você quiser experimentar uma nova pilha de tecnologia em algum serviço, vá em frente. As dependências serão muito mais leves do que as monolíticas e também será muito mais fácil reverter tudo. Quanto menos código em um aplicativo, mais fácil será trabalhar.
Torna muito mais fácil para os novos funcionários entenderem a funcionalidade do serviço.
Microsserviços: recursos de montagem e virtualização Agora entendemos o que são microsserviços. E a maior vantagem é que ele é montado por mais de um arquivo WAR/EAR/JAR. Mas como ele é instalado? A melhor maneira de montar microsserviços dentro de contêineres. Um contêiner é um sistema operacional virtual totalmente configurado com o ambiente necessário configurado, o que ajuda a isolar o acesso aos recursos do sistema de hardware no qual o contêiner está instalado. A solução mais famosa do mercado é, obviamente, o Docker . Máquinas virtuais de IaaS (infraestrutura como serviço), como AWS, também podem funcionar bem para montar microsserviços, mas microsserviços relativamente leves podem não utilizar todos os recursos que estão na máquina virtual, o que pode reduzir a lucratividade de uso. Você também pode montar seus microsserviços usando o pacote OSGI (Open Service Gateway Initiative). Neste caso, todos os microsserviços serão executados em uma única JVM, mas isso envolve questões de compensação entre controle e isolamento. Microsserviços: Desvantagens Só porque “tudo isso é legal” e “não vimos isso antes” não significa que não haja desvantagens. Abaixo está uma lista de possíveis áreas problemáticas que a arquitetura de microsserviços traz consigo:
O desenvolvimento de sistemas distribuídos pode ser difícil. Com isso quero dizer que todos os componentes agora são serviços independentes - você precisa lidar com muito cuidado com as solicitações que passam entre os módulos. Pode haver um cenário em que um módulo não esteja respondendo, forçando você a escrever código adicional para evitar travar o sistema. Isto pode ser mais difícil se as chamadas remotas forem sensíveis à latência .
Vários bancos de dados e gerenciamento de transações podem ser uma verdadeira dor de cabeça.
testar aplicativos de microsserviços pode ser complicado. Usando um aplicativo monolítico, precisamos apenas executar o arquivo WAR/EAR/JAR no servidor e garantir que ele esteja conectado ao banco de dados. E em microsserviços, cada serviço individual deve ser iniciado antes do início dos testes.
A montagem de aplicativos pode ser complicada. Eles podem exigir coordenação em torno de vários serviços que podem não ser tão fáceis de montar quanto um contêiner WAR.
.... É claro que, com as ferramentas e abordagens certas, essas desvantagens podem ser evitadas. Mas eles próprios necessitam de apoio e não resolvem completamente todos os problemas. O artigo foi traduzido do site CloudAcademy . Tradução gratuita. Todos são livres para expressar todos os seus pensamentos nos comentários. Eles definitivamente serão lidos. Artigo original Minha conta no Github
GO TO FULL VERSION