Arquitetura de microsserviço - Introdução
Microservice é uma metodologia de desenvolvimento de aplicativos baseada em serviço. Nessa metodologia, os grandes aplicativos serão divididos nas menores unidades de serviço independentes. Microsserviço é o processo de implementação da Arquitetura Orientada a Serviços (SOA) dividindo todo o aplicativo como uma coleção de serviços interconectados, onde cada serviço atenderá apenas a uma necessidade de negócios.
O conceito de Micro
Em uma arquitetura orientada a serviços, pacotes de software inteiros serão subdivididos em pequenas unidades de negócios interconectadas. Cada uma dessas pequenas unidades de negócios se comunicará entre si usando protocolos diferentes para entregar negócios de sucesso ao cliente. Agora, a questão é: como a Microservice Architecture (MSA) difere da SOA? Em uma palavra, SOA é um padrão de design e Microservice é uma metodologia de implementação para implementar SOA ou podemos dizer que Microservice é um tipo de SOA.
A seguir estão algumas regras que precisamos ter em mente ao desenvolver um aplicativo orientado a microsserviço.
Independent - Cada microsserviço deve ser implantado de forma independente.
Coupling - Todos os microsserviços devem ser fracamente acoplados uns aos outros, de forma que as alterações em um não afetem o outro.
Business Goal - Cada unidade de serviço de todo o aplicativo deve ser a menor e capaz de atender a uma meta de negócios específica.
Vamos considerar um exemplo de portal de compras online para entender o microsserviço em profundidade. Agora, vamos dividir todo este portal de comércio eletrônico em pequenas unidades de negócios, como gerenciamento de usuários, gerenciamento de pedidos, check-in, gerenciamento de pagamentos, gerenciamento de entrega, etc. Um pedido bem-sucedido precisa passar por todos esses módulos em um tempo específico quadro, Armação. A seguir, a imagem consolidada de diferentes unidades de negócios associadas a um único sistema de comércio eletrônico.
Cada um desses módulos de negócios deve ter sua própria lógica de negócios e partes interessadas. Eles se comunicam com softwares de outros fornecedores para algumas necessidades específicas e também entre si. Por exemplo, o gerenciamento de pedidos pode se comunicar com o gerenciamento de usuários para obter informações do usuário.
Agora, considerando que você está executando um portal de compras online com todas essas unidades de negócios mencionadas anteriormente, você precisa de algum aplicativo de nível corporativo consistindo em diferentes camadas, como front-end, back-end, banco de dados, etc. Se seu aplicativo não for dimensionado e completamente desenvolvido em um único arquivo de guerra, então será chamado de um aplicativo monolítico típico. De acordo com a IBM, um aplicativo monolítico típico deve possuir a seguinte estrutura de módulo internamente, onde apenas um terminal ou aplicativo será responsável por lidar com todas as solicitações do usuário.
Na imagem acima, você pode ver diferentes módulos, como Banco de dados, para armazenar diferentes usuários e dados de negócios. No front-end, temos um dispositivo diferente onde normalmente processamos os dados do usuário ou da empresa para uso. No meio, temos um pacote que pode ser um arquivo EAR ou WAR implementável que aceita a solicitação do final do usuário, processa-a com a ajuda dos recursos e a renderiza de volta para os usuários. Tudo ficará bem até que as empresas desejem quaisquer mudanças no exemplo acima.
Considere os seguintes cenários em que você precisa alterar seu aplicativo de acordo com as necessidades do negócio.
A unidade de negócios precisa de algumas mudanças no módulo “Pesquisar”. Em seguida, você precisa alterar todo o processo de pesquisa e reimplantar seu aplicativo. Nesse caso, você está reimplantando suas outras unidades sem qualquer alteração.
Agora, novamente, sua unidade de negócios precisa de algumas alterações no módulo “Check-out” para incluir a opção “carteira”. Agora você tem que mudar o seu módulo “Check out” e reimplantar o mesmo no servidor. Observe que você está reimplantando os diferentes módulos de seus pacotes de software, embora não tenhamos feito nenhuma alteração neles. Aí vem o conceito de arquitetura orientada a serviços mais específico para a arquitetura de microsserviços. Podemos desenvolver nossa aplicação monolítica de tal maneira que cada módulo do software se comporte como uma unidade independente, capaz de lidar com uma única tarefa de negócios de forma independente.
Considere o seguinte exemplo.
Na arquitetura acima, não estamos criando nenhum arquivo ear com serviço ponta-a-ponta compacto. Em vez disso, estamos dividindo diferentes partes do software, expondo-as como um serviço. Qualquer parte do software pode se comunicar facilmente através do consumo dos respectivos serviços. É assim que o microsserviço desempenha um grande papel no aplicativo da web moderno.
Vamos comparar nosso exemplo de carrinho de compras na linha de microsserviço. Podemos dividir nosso carrinho de compras em diferentes módulos, como “Pesquisa”, ”Filtro”, “Check-out”, “Carrinho”, “Recomendação”, etc. Se quisermos construir um portal de carrinho de compras, então temos que construir o módulos mencionados acima, de forma que eles possam se conectar uns aos outros para lhe proporcionar uma boa experiência de compra 24 horas por dia, 7 dias por semana.
Vantagens desvantagens
A seguir estão alguns pontos sobre as vantagens de usar microsserviços em vez de usar um aplicativo monolítico.
Vantagens
Small in size- Microsserviços é uma implementação do padrão de design SOA. É recomendável manter seu serviço o máximo que puder. Basicamente, um serviço não deve executar mais de uma tarefa de negócios, portanto, será obviamente pequeno em tamanho e fácil de manter do que qualquer outro aplicativo monolítico.
Focused- Conforme mencionado anteriormente, cada microsserviço é projetado para entregar apenas uma tarefa de negócios. Ao projetar um microsserviço, o arquiteto deve se preocupar com o ponto focal do serviço, que é sua entrega. Por definição, um microsserviço deve ser de natureza completa e deve estar comprometido em fornecer apenas uma propriedade de negócios.
Autonomous- Cada microsserviço deve ser uma unidade de negócios autônoma de todo o aplicativo. Com isso, o aplicativo fica mais fracamente acoplado, o que ajuda a reduzir o custo de manutenção.
Technology heterogeneity- O Microservice oferece suporte a diferentes tecnologias para se comunicarem entre si em uma unidade de negócios, o que ajuda os desenvolvedores a usar a tecnologia correta no local correto. Ao implementar um sistema heterogêneo, pode-se obter o máximo de segurança, velocidade e um sistema escalonável.
Resilience- Resiliência é uma propriedade de isolar uma unidade de software. A Microservice segue alto nível de resiliência na metodologia de construção, portanto, sempre que uma unidade falha, não impacta todo o negócio. A resiliência é outra propriedade que implementa um sistema altamente escalável e menos acoplado.
Ease of deployment- Como todo o aplicativo é subdividido em pequenos pedaços de unidades, cada componente deve ser uma pilha completa por natureza. Todos eles podem ser implantados em qualquer ambiente muito facilmente com menos complexidade de tempo, ao contrário de outros aplicativos monolíticos do mesmo tipo.
A seguir estão alguns pontos sobre as desvantagens da arquitetura de microsserviço.
Desvantagens
Distributed system- Devido à heterogeneidade técnica, diferentes tecnologias serão usadas para desenvolver diferentes partes de um microsserviço. Um grande conjunto de profissionais qualificados é necessário para dar suporte a esse grande software distribuído heterogêneo. Portanto, a distribuição e a heterogeneidade representam a desvantagem número um do uso de microsserviços.
Cost - O microsserviço é caro, pois você precisa manter um espaço de servidor diferente para diferentes tarefas de negócios.
Enterprise readiness- A arquitetura de microsserviços pode ser considerada como um conglomerado de diferentes tecnologias, à medida que a tecnologia evolui dia a dia. Portanto, é muito difícil tornar uma empresa de aplicativo de microsserviço pronta para ser comparada ao modelo de desenvolvimento de software convencional.
Microsserviço sobre SOA
A tabela a seguir lista determinados recursos de SOA e microsserviço, destacando a importância do uso de microsserviços em vez de SOA.
| Componente | SOA | Microsserviço |
|---|---|---|
| Padrão de design | SOA é um paradigma de design para software de computador, em que os componentes de software são expostos ao mundo exterior para uso na forma de serviços. | Micro Service é parte do SOA. É uma implementação especializada de SOA. |
| Dependência | As unidades de negócios dependem umas das outras. | Todas as unidades de negócios são independentes umas das outras. |
| Tamanho | O tamanho do software é maior do que o software convencional. | O tamanho do software é pequeno. |
| Tecnologia | A pilha de tecnologia é menor que o microsserviço. | O microsserviço é de natureza heterogênea, pois tecnologias exatas são usadas para realizar uma tarefa específica. Os microsserviços podem ser considerados um conglomerado de muitas tecnologias. |
| Autônomo e Foco | Os aplicativos SOA são desenvolvidos para executar várias tarefas de negócios. | Os aplicativos de microsserviço são desenvolvidos para executar uma única tarefa de negócios. |
| Natureza | Monolítico por natureza. | Pilha completa na natureza. |
| Desdobramento, desenvolvimento | A implantação é demorada. | A implantação é muito fácil. Conseqüentemente, será menos demorado. |
| Custo-efetividade | Mais econômico. | Menos custo-benefício. |
| Escalabilidade | Menos em comparação com microsserviços. | Totalmente dimensionado. |
| Exemplo | Vamos considerar um aplicativo de reserva CAB online. Se quisermos construir esse aplicativo usando SOA, então suas unidades de software serão -
|
Se o mesmo aplicativo for construído usando arquitetura de microsserviço, então suas APIs serão -
|