ARTIGO ORIGINAL
BORGES, Gustavo de Jesus [1], WATAYA, Roberto Sussumu [2]
BORGES, Gustavo de Jesus. WATAYA, Roberto Sussumu. Uma Proposta de Arquitetura de Microsserviços Aplicada em um Case de E-commerce. Revista Científica Multidisciplinar Núcleo do Conhecimento. Ano 05, Ed. 11, Vol. 19, pp. 05-24. Novembro de 2020. ISSN: 2448-0959, Link de acesso: https://www.nucleodoconhecimento.com.br/tecnologia/arquitetura-de-microsservicos
Este estudo, teve como objetivo fazer uma análise comparativa entre um processo de solução de uma ERP e também de uma aplicação idêntica utilizando uma arquitetura de microsserviços. Considerando o mesmo CASE e a singularidade das ferramentas e suas características para cada aplicação na solução dos problemas. Assim, ao fazer este estudo comparativo, entre as duas plataformas, esta pesquisa poderá ajudar em uma futura organização em seu processo de tomada de decisão, sobre que arquitetura usar em um projeto de desenvolvimento de software, visando uma melhoria no entendimento e na sua aplicabilidade. Como resultado, percebemos que a arquitetura de microsserviços teve melhor desempenho e performance na solução do problema apresentado no CASE em estudo.
Palavras-chave: ERP, lojas virtuais, monolíticos, microsserviços.
Plataformas que oferecem estruturas pré-prontas para empresas construírem seus sistemas e ou aplicações específicas para qualquer meio já é um conceito bem presente no mercado, empresas que constroem grandes arquiteturas e aplicações bastante poderosas e acabam vendendo esse tipo de tecnologia para outras empresas podemos ver o exemplo da Microsoft com Azure e a Amazon com o AWS. Com as plataformas de e-commerce não é diferente pois elas oferecem todo gerenciamento e visualização do seu negócio na internet, sellers, marketplace, um gerenciamento de catálogo dos produtos da loja, diversas bases de dados para futuras integrações entre outras coisas, e tudo isso já é bem presente no mercado então os lojistas têm essa grande variedade de plataformas. Por existirem diversos cenários e segmentos diferentes que as empresas que trabalham com loja virtual escolhem algumas plataformas por possuírem sistemas robustos monolíticos acabam as vezes limitando o negócio das lojas virtuais já que nem todas as lojas virtual tem o mesmo tipo de fluxo de compra e isso pode impedir de um determinado negócio seja realizado.
Neste contexto, o objetivo deste estudo é fazer uma análise comparativa entre um processo de solução de uma ERP e também uma aplicação idêntica utilizando uma arquitetura de microsserviços.
A solução proposta foi uma integração trabalhada no back-end da loja com a arquitetura de microsserviços, que foi elaborada a partir de um ponto específico no fluxo de compra para que os dados fossem levados de forma correta ao ERP das lojas.
Este estudo está estruturado em 5 etapas, iniciando com esta Introdução, em seguida a Fundamentação Teórica; na Etapa 3 apresentamos.
Os microsserviços é uma forma de desenvolver sistemas onde cada processo é autônomo o suficiente para executar suas funções de formas independentes e articulada entre os outros serviços em que cada um é independente e desacoplado e deve funcionar, eles usam mecanismo de comunicação que podem ser determinados em base de recursos de negócios, existem camadas que são o principal meio de comunicação dos componentes em si geralmente é uma service mash que são responsáveis que abstraem a rede do aplicativo, assim fornecendo uma visibilidade e confiabilidade nas informações oferecendo uma transparência entre os processos, por isso a troca de informações entre os processos definem a arquitetura do sistema.
De acordo com Fowler (2017), com a arquitetura de microsserviços, uma aplicação pode ser facilmente escalada tanto horizontalmente quanto verticalmente, a produtividade e a velocidade do desenvolvedor aumentam drasticamente e tecnologias antigas podem facilmente ser trocadas pelas mais recentes.
No meu entendimento essa arquitetura ela é uma abordagem porque a ideia é desenvolver uma única aplicação em que cada um roda seus próprios processos de formas simples e que tudo seja definido com cada um tenha suas responsabilidades naquela aplicação.
Essa abordagem não foi feita para todos os tipos de aplicações existem sim para todos os casos uma abordagem adaptada de alguma forma porém o foco dos microsserviços são em aplicações grandes e complexas, que deve ser altamente escaláveis no sentido de programação e de várias dimensões sempre focando a performance da aplicação e sabendo tratar os erros oferecendo ao usuário o mínimo de causalidade em erros, ou seja não comprometendo toda aplicação.
Existem algumas importâncias nos microsserviços que podem ser listadas e cada uma delas é o que vai ser levado em consideração se uma determinada empresa vai escolher essa arquitetura ou não.
Através dessa característica modular onde cada módulo atua com diferentes tipos de ferramentas e tecnologias uma empresa que escolhe como vai desenvolver seus sistemas e aplicativos consegue antes definir se aquele sistema funcionaria melhor de forma mais antiga com características monolíticas, mas com o avanço das aplicações e o aumento exponencial de integrações entre plataformas e tecnologias os microsserviços conseguem atender essas aplicações com que elas evoluam de forma eficiente ao decorrer do uso.
A figura abaixo mostra um exemplo de um determinado sistema que usa a arquitetura de microsserviços. Através da ilustração dessa arquitetura implementada no sistema eu consigo ver que dentro do bloco ‘Microservices’ eu tenho toda parte de serviços organizada em forma de processos paralelos e que cada serviço serve a API com diversos processos estruturais.
Figura 01: Arquitetura básica de um sistema que atua com microssiços
Com o avanço com os aplicativos de nuvem nos últimos anos houve um crescimento exponencial de diversas funcionalidades e as empresas crescem muito rápido e consequentemente as equipes de desenvolvimento crescem muito rápido e dependendo do grau da aplicação fica quase inviável uma equipe gigantesca de por exemplo mais de 100 pessoas trabalhando em um aplicação de arquitetura monolítica, então no processo de engenharia dessas aplicações adotar os microsserviços é o caminho para que a aplicação senha dividida em diversos módulos para que cada equipe consiga trabalhar com mais facilidade e fácil manutenção.
Empresas que trabalham desenvolvendo aplicações de nuvem e serviços de internet não querem sistemas robustos o suficiente que cada atualização ou teste levam horas para serem feitas por isso atualmente preferem destrinchar suas aplicações em pedaços porque você acaba trabalhando melhor suas equipes sem criar dores de desenvolvimento.
Seguindo esse raciocínio de deixar o desenvolvimento da aplicação mais flexível rápidas manutenções, um sistema robusto monolítico em que toda aplicação trabalhar num mesmo repositório faz com que toda aplicação tenha que ser pausada para que algum processo dentro desse sistema seja atualizado ou implementado e dependendo da implementação os outros processos devem ser refatorados, trabalhando com microsserviços o time de desenvolvimento consegue contornar esse problema.
De acordo com Fowler (2017), o objetivo da arquitetura de microsserviços é construir um conjunto de pequenas aplicações, cada uma responsável por executar uma função (ao contrário da forma tradicional de construir uma aplicação que faz tudo), e permitir que cada microsserviço seja autônomo, independente e autossuficiente.
Figura 02: Arquitetura de um sistema monolítico robusto e uma arquitetura de microsserviços demonstrando a facilidade de manutenção.
Na arquitetura de microsserviços é muito difícil que todos os microsserviços que sejam completamente isolados de outros microsserviços porém existem microsserviços que conseguem trabalhar com seus próprios componentes como por exemplo uma base de dados própria. Mas também existem microsserviços que se reúnem entre si e conseguem trocar informações completas ao usuário, e através de mensagens ele consegue trazer e criar informações para cada lado, sempre tendo em mente que cada microserviço se falhar os outros não serão afetados.
Existem circunstâncias que não podem ser levadas com microsserviços se não forem estruturadas de forma correta, por exemplo microsserviços que compartilham o mesmo banco de dados não são microsserviços porque se a base quebrar todos os processos são comprometidos, ainda é um grande problema em empresas que prosseguem com essa falha de estrutura para frente e ocasionando em manutenções mais complexas para as equipes e até mesmo frustrações para o usuário.
Um exemplo que pode ser visto como um microsserviços temos no caso o Gmail que de vez em quando a área de contatos do Gmail não está funcionando mais as outros serviços como ler e-mail, mandar e-mail, fazer rascunhos continua funcionando isso é um exemplo de um micro serviço autônomo que continua seu funcionamento de forma independente.
Abaixo uma figura ilustrativa de como é a diferença da arquitetura monolítica para uma arquitetura de microsserviços.
Figura 03: Ilustração das diferenças organizacionais de uma arquitetura monolítica e uma arquitetura baseada em microsserviços.
A loja virtual desenvolvida trabalha com delivery de alimentos, com foco o absoluto em mobile buscando atender em quase todos os estados do brasil. Trabalhando com geocalização e um ERP estruturado para centralizar todos os processos de logística, entrada e saída de dados.
O ramo da loja por é de alimenta com o foco em fast food, ou seja comida rápida ela se difere das lojas convencionais de e-commerce, a maioria delas trabalham com produtos que serão entregues em dias específicos e trabalha toda aquela parte de receber o pedido, gerenciar o pedido, aprovar pagamento e separação estoque e tudo isso em prazo de dias que envolve a entrega. No caso desse case a loja deveria trabalhar em cima de um ERP que integra lojas por todos os estados do brasil e também os pedidos feitos pelo usuário, assim que comprado o alimento o usuário vai retirá-lo em menos de 1 hora em alguma loja próxima a sua localização.
O fluxo de compra é bem simples de ser entendido é visualização do fluxo de compra do usuário no front-end da loja.
Figura 04: Fluxograma da compra efetuada pelo usuário
O ERP da loja do cliente por existir a muito tempo e por ser uma estrutura feita para todas as lojas presentes no Brasil e também em outros países tem a sua estrutura própria e bem delineada para as suas próprias integrações. O grande problema que impossibilitou as vendas é que quando o cliente realiza o pedido e os dados do pedido vão passar para a camada de pedidos e de segurança que é uma última camada antes de chegar no ERP esses dados (JSON) não chegam organizados e compatíveis com a estrutura dessa camada de integração e por isso os dados do pedido não conseguem prosseguir pro ERP das lojas.
Aqui temos uma representação simplificada de como estava estruturada a integração das compras da loja desde o front-end (loja virtual/plataforma) para a camada de pedidos e de segurança até chegar no ERP.
Figura 05: Fluxograma do problema do CASE com o problema.
Onde o sinal de erro está colocado é onde os dados (JSON) do pedido chegavam na estrutura da plataforma em um determinado formato e no caso eles deveriam chegar organizados e dentro da estrutura que a camada de pedidos e segurança fossem capaz de reconhecer esses dados e passar pro ERP. Isso impossibilitou gravemente a continuidade do projeto porque praticamente impedia a compra do usuário.
Com o cenário do problema entendido a empresa contratada estudou e levantou que deveríamos atuar com um middleware desenvolvido com conceito de microsserviços para receber os pedidos da loja e organizar esses dados e passados para próxima camada.
Aqui está a representação simplificada de como ficou a integração da loja como um todo com a solução do microsserviço, note que entre a loja e a camada de pedidos o middleware é responsável por organizar esses dados na estrutura correta e deixá-los prontos para passar para camada de segurança e seguir pro ERP.
Figura 06: Fluxograma do problema do CASE com a solução.
O middleware construído possui diversas ações e processos que trabalham por trás das integrações vindas da loja. Então aqui vamos entender a sua composição:
Ele possui funções que trabalham todos os tipos de pedido seja em pequena ou grande volumetria sem instabilidade de dados.
Trabalha com Webhooks para tratar os dados que recebe em tempo real assim que cada e qualquer pedido é realizado, a construção dessa lógica e esse tempo de recebimento e organização de dados foi fixada para 10 segundos.
Trabalha os status do pedido padrões em qualquer loja, pedido realizado, pedido cancelado, pagamento realizado, pagamento recusado, pedido em espera. Para todas esses status existe uma tratativa para proceder com essas ações.
Ao fazer uma análise comparativa em um CASE, entre a solução tradicional de uma ERP vs solução com uma arquitetura de microsserviços, podemos perceber que os resultados são nitidamente justificados por meio da observação de uma diferença de resposta favorável à arquitetura de microsserviços.
Sistemas que seguem uma arquitetura robusta hoje em dia no mercado tornam-se mais datados no sentido ser um sistema saudável e de uma manutenção rápida e eficiente sem precisar nesse processo efetuar o desligamento do sistema.
Especificamente para plataformas que trabalham com e-commerce a responsabilidade de ter um sistema a prova de falhas é muito maior porque lidam com entregas e saídas de pedido inteiro e quanto mais aplicações e processos que são acrescentados a eles com uma metodologia semelhante à incremento pode exponencialmente o sistema monolítico que com inúmeras travas de desenvolvimento.
Assim a proposta de uma arquitetura baseada em microsserviços para estes tipos de CASE, são mais eficientes e é justificável a sua complexidade de implementação no início já que são mais fáceis de trabalhar isoladamente e se manterem saudáveis depois de prontos suas ações e processos
Por tudo isso, os resultados apresentados através desta pesquisa, demonstrou como foi a jornada deste CASE em específico, e sua aplicação em uma arquitetura de microsserviços, sobrepondo uma arquitetura robusta que impossibilitou o prosseguimento desta loja. Assim, podemos afirmar que um microsserviço pode oferecer às empresas que oferecem plataformas de lojas virtuais conseguem adotar esse modelo de arquitetura mantendo seus serviços abertos, evolucionários e adaptáveis a qualquer segmento de vendas específico.
FOWLER, Susan J. Microsserviços prontos para produção: Construção de sistemas padronizados em uma organização de engenharia de software. São Paulo – SP. Novatec – LTDA, 2017.
FERNANDO, Boaglio. Spring Boot: Acelere o desenvolvimento de microsserviços. São Paulo – SP. Caelum, 2017.
MEDIUM, Disponível no site: https://medium.com/startlovingyourself/microservices-vs-monolithic-architecture-c8df91f16bb4 acesso em 12/set/2020.
RANCHER, Disponível no site: https://rancher.com/blog/2019/microservices-vs-monolithic-architectures acesso em 12/set/2020
SCOTT, James A. Microsservices and Containers: Mastering the Cloud, Data, and Digital Transformation. US – MARP, 2017.
[1] Bacharelado em ciência da computação.
[2] Orientador. Doutorado em Educação. Mestrado em Educação. Graduação em Matemática. Graduação em Sistemas para Internet. Graduação em Tecnologia em Redes de Computadores. Graduação em Bacharel Em Ciências Jurídicas.
Enviado: Novembro, 2020.
Aprovado: Novembro, 2020.
A violência doméstica contra a mulher constitui uma das mais persistentes violações de direitos humanos…
O comércio eletrônico impõe aos sistemas de venda on-line elevada taxa de mudança em regras…
O objetivo deste estudo é compreender os sentimentos das primíparas frente às dificuldades no processo…
A gestão administrativa eficiente constitui um dos principais pilares de sustentação do desempenho organizacional no…
O artigo examina criticamente o fundamento da periculosidade nas medidas de segurança do direito penal…
O presente estudo analisa os desafios arquitetônicos relacionados ao desenvolvimento de banheiros acessíveis para pessoas
