MICROSERVICES: HANDLING HIGH DEMAND EVENTS
REGISTRO DOI: 10.5281/zenodo.10155841
Freitas, L.O
Santos, L.S
Pereira, F.R
Noriega, C.L
RESUMO
Este artigo tem como objetivo apresentar como os microsserviços podem solucionar o problema de desempenho e disponibilidade durante eventos de alta demanda em e-commerces. Especificamente durante o período da black friday, evento que ocorre sempre na última sexta-feira de novembro, e gera alto tráfego em e-commerces devido a descontos, promoções e ao expressivo investimento em marketing.
Palavras-chave: Microsserviços, Black Friday, escalabilidade, manutenibilidade, desempenho
ABSTRACT
This article aims to demonstrate how a microservice architecture can be a valuable choice to address performance and availability issues during high demand events in e-commerces mainly during black friday period which occurs in the last friday of november and generate a substantial traffic in e-commerce applications due special deals and significant marketing investment.
Keywords: Microsservices, scalability, manutenability, performance
1. INTRODUÇÃO
A Black Friday é o maior evento para o calendário varejista, e ocorre no dia seguinte ao feriado de Thanksgiving, do inglês ação de graças. O feriado de Thanksgivingé comemorado na quarta quinta-feira de novembro, e marca o período de vendas de fim de ano, terminando no Natal, em 24 de dezembro. O período de inverno nos Estados Unidos se inicia em dezembro, muito próximo a Black Friday, que ganhou relevância na mídia devido ao acúmulo de consumidores em frente às principais lojas e shopping centers, durante condições climáticas extremas como a neve. A ansiedade para adquirir novos produtos, combinado a ambientes superlotados, investimentos em propaganda e a limitação de produtos disponíveis, gera frustração e agressão entre os consumidores — Guerra, 2017. Resultando em alguns casos de morte, como no caso de um funcionário da Wal-Mart que foi pisoteado até a morte em 2008. Segundo Black Friday Death Count(contador de mortes da Black Friday) 17 pessoas morreram durante eventos da Black Friday e 125 se feriram até o ano de 2021.
Conforme os escritores Apfelbaum e Taylor-Blake, o termo Black Friday hoje é associado ao mercado varejista. Foi primeiramente utilizado pelos policiais da Filadélfia ao se referirem ao trânsito causado por famílias atraídas pelo Papai Noel na sexta-feira após o Thanksgiving. De acordo com Benjamin Zimmer, o termo era anteriormente utilizado para representar calamidades financeiras, como o Wall Street Crash (grande quebra da bolsa) em 1929. Em 1980 o termo começou a ser utilizado por contadores, ainda quando os registros de caixa eram registrados com tinta. Onde o vermelho representava perdas e o preto o lucro. A expressão (do inglês going black) que indica melhoria, saírem do vermelho, começou a ser utilizada pelo mercado do varejo, e em meados da década de 90 já era uma expressão popular.
O mercado brasileiro, assim como praticamente todo o mundo, também aderiu ao evento, de acordo com pesquisas da receita federal, o comércio eletrônico brasileiro deve crescer a uma taxa anual de 20% nos próximos anos, saltando de U$ 211 bilhões em 2022 para U$ 400 bilhões em 2026 — SEBRAE. As compras realizadas por meio de websites e aplicativos representam a maioria das vendas, em 2023, 61% dos brasileiros passaram a comprar mais pela internet do que em lojas físicas. Segundo o comparativo do consumo em lojas físicas e lojas virtuais realizado pela SPC Brasil, 45% dos consumidores virtuais já preferem comprar pela internet e 90% fazem pesquisa virtual, antes de comprar em loja física. De 2010 a 2020, a Black Friday tem apresentado crescimento acima de dois dígitos no comércio eletrônico Brasileiro (E-BIT, 2021). E ao somar as vendas da Black Friday, com a Cyber Monday (ação promocional online que ocorre na segunda-feira seguinte à BlackFriday) e do mês de Natal, em alguns segmentos as vendas representam cerca de 25% a 40% do volume anual de vendas — SWILLEY, GOLDSMITH, 2003; DISSE, 2023.
Toda volumetria de solicitações de compras e a exibição de produtos é mediada por programas de computadores. A Black Friday, assim como, venda de ingressos para eventos musicais ou esportivos, ou até mesmo em um dia de eleição, onde o país inteiro está acompanhando minuto a minuto os resultados das apurações. Causa um evento de pico de acessos em sistemas eletrônicos como websites e APIs que gerenciam o processamento de dados. Onde a demanda de uso de sistemas de informação cresce substancialmente em pouco tempo. Todos esses eventos apresentam um desafio substancial para sistemas de informação, que devem apresentar características de desempenho, resiliência e precisão para suportarem a alta demanda e ainda, sim, continuar a entregar uma experiência adequada em seu software.
Software é descrito como o elemento que faz mediação entre o ser humano e máquinas, refere-se a todos os programas que os fabricantes ou usuários podem instalar em um computador. O software pode ser usado pelo computador, pelo usuário ou por ambos para organizar e usar arquivos e outros dados para tarefas específicas, estão presentes explicitamente ou mesmo sem serem percebidos, a maioria dos produtos elétricos incluem uma máquina e um software de controle. Dado que, o software é intangível e abstrato, ou seja, não é limitado por materiais ou leis da física, não existem limitações materiais no potencial de software. Porém, a falta de restrições naturais implica que os programas de computadores tendem a se tornar complexos facilmente — MORAIS, Engenharia de Software, 2017; GALLOTTI, Arquitetura de software, 2016; DZIAK, M. Computer Software.
Linguagem de programação é o termo empregado, para o conjunto de símbolos, que descrevem os programas, interpretados por computadores. Java e JavaScript são dois exemplos de linguagens de programação. Aplicações projetadas para a interação com o usuário, são chamadas de frontend, como websites e aplicativos de smartphones, já os programas que realizam processamento de dados, como a aprovação de uma transferência bancária, são chamados de backend. Framework é o nome dado ao conjunto de práticas associadas à utilização de linguagens de programação, Spring Boote Express são frameworks feitos em Java e JavaScript respectivamente para criar entre outros, porém principalmente, aplicações web. Para que os dados trafegados nas aplicações sejam persistidos, os bancos de dados são utilizados, como o PostgreSQL. É comum haver integração direta entre diferentes aplicações, de tal forma que quando um sistema entra em estado indisponível, o outro para de operar parcial ou totalmente. Para remover este acoplamento direto, serviços de mensageirias são utilizados, como o
ActiveMQ, onde o sistema A se comunica com o ActiveMQ, mediante a mensagens, o sistema B consomê a mensagem e responde novamente para o ActiveMQ, onde finalmente o sistema A consome a resposta. Dessa forma, caso o sistema A ou B, caia (não esteja operante) as mensagens ficam enfileiradas no ActiveMQ sem que haja propagação de falha entre os sistemas. É comum que os programas possuam diversas versões correspondendo a atualizações e adição de novas funcionalidades. Pode ocorrer de que em uma versão, o banco de dados, framework, biblioteca interna, ou a versão da própria linguagem de programação, seja modificada. Causando certo atrito com usuários do sistema, que devem ajustar seus computadores para utilizá-lo. O Docker é um programa responsável pela conteinerização da aplicação, criando um ambiente específico, muito semelhante a máquinas virtuais, com todas as dependências necessárias para executar o projeto. Existem alguns métodos para teste de aplicações, como testes unitários, que isolam partes pequenas do sistema. Testes de integração, que testam a comunicação entre sistemas, testes end-to-end, de carga, entre outros. Para realizar testes de cargas, ferramentas como JMeter são utilizadas, considerando que é necessário simular vários dispositivos acessando o serviço simultaneamente, processo praticamente impossível de ser executado manualmente (SPRING; JAVA; Express; JavaScript; POSTGRESQL; DOCKER; ACTIVEMQ; JMETER).
As estratégias promocionais dos grandes varejistas convergiram para o desenvolvimento da engenharia de software, dado que, o software possibilita a compra do produto, sua divulgação, influência em vendas, e coleta de informações sobre os consumidores.
A engenharia de software é um ramo da engenharia cujo foco é o desenvolvimento em custos adequados de sistemas de software. Segundo o Sommerville — O mundo moderno não funciona sem software, sendo essencial para o funcionamento do governo, sociedade, empresas, instituições nacionais e internacionais. Tendo como principal impulsionador a competitividade gerada pela disputa de mercado, dado que, as empresas que conseguem gerar valor gastando menor recurso ou oferecer produtos de melhor qualidade o dominam. No cenário da indústria de software, a inovação tecnológica (o software), é o principal ativo, e a partir dele os indicadores de qualidade são criados. Está disputa de mercado gerou o que é conhecido hoje como Engenharia de Software, durante os anos 1970 e 1980, foram desenvolvidas séries de técnicas e paradigmas que compõem a base da engenharia de software atual. Ao decorrer deste processo houve algumas falhas como as “pens-based computers” lançadas pela Microsoft — Bloomberg (1991) e, em contrapartida, o sucesso dos smartphones logo após o lançamento do primeiro Iphone em 2007 — MEDIUM. O software está presente em praticamente todas as áreas, apresentando-se, quase que, como uma extensão humana. Quanto à arquitetura de software, é a maneira como os componentes que constitui o software são organizados, com finalidade de tornar a evolução, a adição de novas funções mais flexível, extensível, portátil e reutilizável. Entre os padrões arquitetônicos mais utilizados estão o modelo monolítico e o de microsserviços. De acordo com NEWMAN, 2020, o modelo monolítico é descrito quando todas as funcionalidades de um sistema tiverem que ser implantadas em conjunto, esse sistema é considerado monolítico. Em outras palavras, quando todo o sistema estiver contido em um único projeto ou quando um grupo de projetos tiverem que ser implantados em conjunto. Para este segundo exemplo existe um nome mais específico, monolítico distribuído. Já os microsserviços são definidos como sistemas que podem ser implantados de maneira independente, sendo modelados em torno de um domínio de negócio. Eles são sistemas enxutos e especializados que se comunicam entre si, utilizando rede de computadores, para o desempenho de tarefas mais complexas. A ideia é que através dessa abordagem seja possível endereçar os principais problemas de modo mais granular e especializado. A adoção dessa técnica, em conjunto com práticas como integração e implantação contínua, testes automatizados, monitoramento, pode ajudar com que as empresas entreguem soluções com uma melhor experiência aos seus usuários finais. Exemplificando, para o contexto de uma empresa de comércio eletrônico, poderia haver um micro serviço para cálculo de frete, outro para gerenciamento de produtos mais relevantes, e assim por diante, cada um com uma finalidade específica no domínio do negócio.
Uma pesquisa realizada pela O’REILLY em 2020, constatou que 46% das organizações estão migrando ao menos 25% de seus sistemas para a arquitetura de microsserviços, e 15% das organizações estão migrando de 75% a 100%. Escalabilidade é uma das principais razões pelas quais empresas como Netflix, Uber, Amazon e Airbnb adotaram arquitetura de microsserviços, a quantidade de usuários simultâneos em seus serviços é significativa. Dado que, há interesse em oferecer produtos e experiências digitais de qualidade, oferecer o serviço ao maior número possível de usuários, mantendo a experiência do usuário agradável, enquanto se gerencia uma infraestrutura complexa, estimulou a popularização dos microsserviços. Outro fator relevante é o desempenho percebido pelos usuários que impacta diretamente os resultados do negócio, de acordo com estudos de grandes empresas de tecnologia. A Amazon constatou que 0,1s de latência adicional resulta em um impacto de 1% de suas vendas, enquanto o Google descobriu que 0,5 segundos adicional na geração de resultados de busca pode reduzir seu tráfego na ordem de 20%.
Sabe-se que a Black Friday causa grande tráfego de consumidores em plataformas digitais, como já mencionado, em alguns segmentos as vendas durante esse período atingem 40% do volume anual. Diante desse contexto, cada compra é intermediada por serviços de terceiros como gateways de pagamento de bancos digitais e serviços de emissão de notas fiscais eletrônicas. As transações durante este período extrapolam os limites desses serviços, uma vez que, há concorrências nos serviços terceirizados.
É imprescindível que o sistema de venda, desde a UI (do inglês interface do usuário) presente no website ao serviço ou serviços backend, garantam apropriada UX(do inglês experiência do usuário) para os seus consumidores. De que forma um sistema backend pode operar com estabilidade e responder a todas as transações, durante um evento de alta demanda, como a Black Friday, quando parte de uma transação depende de um serviço terceirizado, onde não é possível controlar o seu comportamento. E ainda assim, garantir todas as vendas?
Entre as principais causas de travamentos e mau desempenho em sistemas backend está relacionado à escolha de arquitetura incorreta. Dado que, um aumento repentino no tráfego ou no número de requisições pode ocasionar deadlocks (problemas de concorrência), quando múltiplas partes do sistema competem por recursos, erros de sincronização podem ocorrer e sobrecarregar o sistema e levá-lo a travar. Isso pode ocorrer devido a eventos inesperados, como picos de popularidade. A dependência de terceiros como bibliotecas, serviços web ou APIs, com alto acoplamento, pode apresentar o mesmo problema, considerando que o processo trava até obter a resposta.
Para lidar com eventos de alta demanda é importante adotar a arquitetura de microsserviços, em razão da capacidade de lidar com falhas e escalonar recursos conforme necessário.
1.1. JUSTIFICATIVA
A importância desse trabalho reside na compreensão de como a arquitetura de microsserviços pode dispor de meios para lidar com alto volume de tráfego durante a Black Friday. Portanto, este trabalho envolve vários aspectos importantes para sociedade, como, demonstrar características deste padrão arquitetônico, à sua capacidade de dividir monólitos em componentes independentes, tornando o desenvolvimento e a manutenção de sistemas mais gerenciáveis. Explorar o porquê a adoção de microsserviços tem se tornado tendência na indústria de software. Além dos aspectos práticos, esse trabalho tem em vista contribuir para o conhecimento acadêmico, ao explorar a arquitetura, as boas práticas e os desafios em profundidade.
1.2. OBJETIVOS (GERAL E ESPECÍFICOS)
1.2.1. OBJETIVOS GERAIS
Compreender o conceito de microsserviços, suas características, princípios e benefícios. Fornecendo uma modelagem de um sistema backend utilizando o Framework Spring com a linguagem de programação Java, capaz de processar todas as solicitações compras que uma empresa com sede em São Paulo, que fabrica e vende roupas, recebeu durante a Black Friday do ano de 2022. Nos referimos a esta empresa, pelo nome de CStore, devido à pedido da mesma, motivada pela lei da LGPD. Alguns dados como nome dos produtos e CPF dos clientes foram anonimizados, e substituídos por números sequenciais únicos. Além disso, esse trabalho aborda temas como comunicação entre microsserviços, incluindo API (do inglês application programming interface), mensageria, demonstrar como os microsserviços podem ser escalados horizontalmente e como podem lidar com falhas de maneira resiliente. Apresentando mediante o estudo de caso da empresa CStore, que perdeu, segundo relatos da própria empresa, cerca de 42% de suas solicitações de compras devido ao sistema não ser escalonável.
2. OBJETIVOS ESPECÍFICOS
Explorar o padrão arquitetônico de microsserviços, através de uma revisão bibliográfica, buscando entender seus fundamentos, bem como apresentar suas vantagens e desvantagens de utilização.
Normalizar e explorar o conjunto de dados fornecido pela CStore, para exemplificar o pico de volume de transações recebidas durante a Black Friday.
Exemplificar os conceitos discutidos por meio de um caso prático de implementação de um sistema backend utilizando microsserviços. Construído com a linguagem de programação Java, banco de dados Postgre SQL, mensageira com ActiveMQ e Docker. Apresentando um sistema capaz de processar todas as solicitações de compra recebidas pela CStore na Black Friday de 2022 em um prazo de até vinte e quatro horas.
2. REVISÃO BIBLIOGRÁFICA
A arquitetura de microsserviços vem sendo cada vez mais adotada no desenvolvimento de software, fazendo com que sistemas grandes e complexos possam ser subdivididos em sistemas menores com responsabilidades mais direcionadas. Essa abordagem traz consigo uma série de conceitos e técnicas que precisam ser exploradas. Como, entender quais são os principais desafios técnicos na implementação desse tipo de arquitetura. No artigo “A Systematic Mapping Study in Microservice Architecture”, os autores exploram alguns desses conceitos e desafios por meio de uma análise que levanta quais os principais conceitos e desafios inerentes a esse estilo arquitetural e sua implementação, focando no levantamento de lacunas que possam ser preenchidas por estudos futuros. Alguns dos pontos em comum com esse trabalho são os seguintes temas: desempenho, disponibilidade e tolerância a falhas.
O Livro “Microservices Patterns”apresenta uma valiosa contribuição para o entendimento dos principais conceitos e desafios levantados no artigo citado anteriormente. O autor oferece uma visão ampla e pragmática sobre os principais conceitos e abordagens para solução dos desafios inerentes à adoção de microsserviços.
Um ponto de destaque no livro é a contínua comparação entre diferentes abordagens e soluções para o mesmo problema, explorando vantagens, desvantagens e complexidades de cada uma das soluções, servindo de uma fonte de conhecimento extremamente rica e guia para escolha das abordagens corretas na adoção da arquitetura de microsserviços.
3. MATERIAIS E MÉTODOS
Para este estudo foi utilizado Docker na versão 4.22.1 para criação de contêineres virtuais, Postgre SQL versão 16, PGAdmin na versão 4.7 e três microsserviços, um desenvolvido em Java versão 17 com framework Spring 3.1.3, e os outros dois com JavaScript com o framework Express. Onde, todos os programas (Java, JavaScript, PGAdmin e PostgreSQL) foram executados dentro de containers Docker, em um notebook Dell modelo Inspiron 3583, processador Core i7, 8 gigabytes de memória RAM, placa de vídeo Radeon 520 e sistema operacional Windows 10.
A pesquisa foi conduzida mediante a biblioteca virtual e a plataforma de pesquisa EBSCO disponibilizada pela Universidade São Judas. Alguns artigos científicos foram encontrados via sistema de busca do Google Scholar. Reportagens de revistas como The New York Times e Bloomberg foram encontradas via pesquisa no Google. Segue palavras-chave utilizadas na pesquisa, black friday, history of black friday, black friday origin, como a black friday chegou ao Brasil, influência da black friday nas vendas, benefícios da black friday no Brasil, relevance of microservices, microservices, software, microsserviços, escalabilidade de microsserviços, benchmark of microservices. A documentação oficial das tecnologias empregadas neste trabalho foram encontradas no website da própria fabricante. Além disso, livros físicos como (NEWMAN, 2020; SOMMERVILLE, 2018) também foram utilizados.
Os dados foram coletados por meio de contato telefônico com a CStore, empresa presente na cidade de São Paulo, que fabrica e vende roupas. As informações foram concedidas em formato CSV (valores separados por vírgula) por e-mail. As estrutura de dados segue o seguinte padrão, cpf, product_id, gender, age, occupation, city_category, stay_in_current_city_years, marital_status, product_category_1, product_category_2, product_category_3, purchase, a base de dados contém registro de todas as solicitações de compras recebidas pela CStore em seu sistema de vendas durante a Black Friday de 2022. Todas as informações biográficas dos clientes, com exceção do sexo, foram anonimizados conforme a lei da LGPD, o CPF dos clientes e nome dos produtos foram substituídos por valores sequenciais alfanuméricos, utilizando um algoritmo feito em Java para a conversão (Apêndice B). Os dados foram submetidos a análise quantitativa utilizando o banco de dados PostgreSQL. Foi realizado consultas para contabilizar o total de transações e comparado compras por gênero, idade e os produtos mais vendidos.
Com base na análise de dados, foi projetado um sistema backend construído em Java 17, com framework Spring, visando criar um sistema de microsserviços capaz de processar todas as transações recebidas pela CStore. Foram realizados testes de desempenho e capacidade da API, para garantir que o sistema poderá executar todas as transações, submetendo a aplicação a ferramenta de desempenho JMeter, software para testes de aplicações web.
4. RESULTADOS E DISCUSSÃO
A análise dos dados revelou que a CStore recebeu 550.068 mil transações na Black Friday de 2022.
Tabela 1 – Quantidade de solicitações de compras por gênero
Fonte: Criado pelo autor
Onde 45% dos pedidos de compras foram efetuados por clientes do sexo feminino e 75% do sexo masculino.
Figura 1 – Relação entre idade e solicitações de compra
Fonte: Criado pelo autor
A distribuição por idade demonstrou que os clientes entre 26 e 35 anos representam a maior faixa de compradores, com 39,91% dos pedidos.
Tabela 2 – Produtos mais vendidos
Fonte: Criado pelo autor
A análise dos produtos mostrou que o produto ‘P00265242’ foi o mais solicitado, recebendo 1.880 pedidos.
Com a volumetria de requisições de compras contabilizadas, foi construído um micro serviço em Javascript para simular o gateway de pagamento (gateway-api, será utilizado o nome do serviço) e outro micro serviço para simular o gerador de notas fiscais (fiscal-api), ambos utilizando o framework Express. Posteriormente, o micro serviço principal (store-api), responsável por receber as solicitações de compra via rede de computadores, e comunicar-se com os outros microsserviços utilitários, foi construído em Java com framework Spring (Apêndice A — contém link para o código-fonte dos serviços mencionados), conforme a figura 2.
Figura 2 – Arquitetura CStore
Fonte: Criado pelo autor
Todos os serviços foram executados em containers Docker, demonstrado na figura 3.
Figura 3 – Containers Docker
Fonte: Criado pelo autor
Para critérios de análise de desempenho, foi adicionado uma entidade (nome técnico para o conjunto de dados, popularmente conhecido como tabela, presente em banco de dados relacionais) com o nome de Log, para contabilizar o tempo de execução de cada transação, com a seguinte estrutura de dados:
Tabela 3 – Estrutura de dados da entidade Log
Fonte: Criado pelo autor
Todas as variáveis com sufixo time, estão em milissegundos, o purchase_id faz referência ao número identificador para uma solicitação de compra. Em conjunto com a ferramenta JMeter, os testes de carga foram realizados, inicialmente com 1 requisição por segundo, subindo para 10, 20, 50 e 90.
Tabela 4 – Percepção real de uso do sistema
Fonte: Criado pelo autor
Tabela 5 – Tempo de processamento interno store-api — 1 transação/segundo
Fonte: Criado pelo autor
Através da análise da tabela 4 e 5, foi possível perceber que o tempo de processamento interno difere do tempo de resposta real, percebido pelos usuários no momento de manipulação do sistema, onde o tempo de processamento interno levou 4,6 segundos, enquanto o tempo real levou 5,01 segundos . A tabela 4, demonstra o tempo de processamento completo entre a requisição de uma compra e o retorno do sistema. Enquanto a tabela 5, expõem o tempo de processamento interno, sem considerar o tempo em que a transação levou para sair do computador do usuário, sendo interpretado e convertido em um objeto, presente na classe responsável por receber transações HTTP do store-api. E o tempo para a resposta chegar ao sistema do usuário.
Figura 3 – Tempo de processamento interno store – api —10 transações/segundo
Fonte: Criado pelo autor
Tabela 6 – Percepção real de uso do sistema
Fonte: Criado pelo autor
Com taxa de 10 transações por segundo, o sistema manteve-se com tempo de resposta de aproximadamente 4 segundos. Em relação ao tempo real de percepção dos usuários, houve uma pequena taxa de variação, onde a requisição com menor tempo de resposta levou 4,2 segundos, e a com maior, 5 segundos. Foi aumentado o número de requisições para 50 por segundo.
Figura 4 – Tempo de processamento interno store-api 50 transações/segundo
Fonte: Criado pelo autor
Tabela 7 – Percepção real de uso do sistema
A partir da taxa de 50T/s, o sistema começou a apresentar grande discrepância entre os valores mínimo e máximo, apresentando tempo máximo de 20,5 segundos e uma média de 12,3 segundos de resposta. Resultados já considerados inaceitáveis, em contrapartida, o tempo de processamento interno manteve-se constante, demonstrando que os processos que envolvem a conversão e o enfileiramento de requisições foram os responsáveis pelo aumento do tempo de resposta. Conforme a infraestrutura do framework Spring.
Figura 5 – Hierarquia da infraestrutura Spring
Fonte: Spring
Todas as requisições HTTP, são gerenciadas pelo Servlet WebApplication, nome do processo responsável por transformar os dados enviados por redes de computadores em objetos Java, que por sua vez, é salvo na memória do computador hospedeiro. A memória disponível para processos de computadores é limitada pelo sistema operacional, e quando a quantidade de objetos se aproxima do limite, o sistema para de receber novas requisições, até que haja memória disponível, gerando travamentos e aumento no tempo de resposta. Com o propósito de encontrar o limite de ruptura do sistema, continuamos aumentando a carga.
Figura 6 – Tempo de processamento interno store -api 90 transações/segundo
Fonte: Criado pelo autor
Tabela 8 – Percepção real de uso do sistema
Fonte: Criado pelo autor
Com taxa de 90T/s, o tempo de processamento interno manteve-se constante como o esperado, no entanto, o sistema atingiu o ponto de ruptura, deixando de responder 11,1% das transações, apresentando um tempo de resposta máximo de 33,7 segundos, e tempo de resposta médio de 20,4 segundos.
Os testes demonstraram que a store-api, recebendo a taxa de 20T/s, consegue se manter com bom desempenho de maneira saudável, conforme a tabela 9.
Tabela 9 – Percepção real de uso do sistema
Fonte: Criado pelo autor
A média apresentou o tempo de 6,1 segundos e o desvio padrão de 1,86 segundos.
Fórmula do desvio padrão
onde “Xi” são os valores individuais,“x” a média e “n” o número total de elementos.
Considerando que um dia possui 24h, e convertendo essa unidade de tempo para segundos 24h × 60m × 60s, encontra-se o valor de 86.400 segundos. Multiplicando esse valor pela taxa segura de execução da store-api, encontra-se o valor de 86. 400 × 20 = 1. 728. 000 transações diárias. Podendo processar 3,14 vezes a quantidade de transações recebidas pela CStore em 2022. Caso haja um pico de transações que supere esse valor, é possível adicionar novas instâncias da store-api e aumentar a quantidade de transações segundo o necessário. Conforme a figura 5.
Figura 7 – Arquitetura CStore com paralelismo
Fonte: Criado pelo autor
Para esse modelo mais robusto, três novas peças foram adicionadas, o loadbalancer (do inglês balanceador de carga) responsável por orquestrar qual instância do store-api processará a solicitação de compra. Como o número de instâncias da store-api pode aumentar a um número “n”, onde “n” pode crescer ao infinito, o ActiveMQ foi adicionado, para desacoplar a integração direta com os serviços terceirizados, que não podem ser controlados. O ActiveMQ enfileira transações na forma de mensagem, e à medida que o gateway-api e o fiscal-api respondem à transação, a store-api recebe este retorno sem travar o processo, mantendo todas as solicitações de compra. Dessa forma é possível atender todos os pedidos mesmo que os serviços terceirizados fiquem fora do ar por um período. O integration-api foi adicionado somente para ler mensagens do ActiveMQ, criadas pelo store-api. Com a responsabilidade de enviar para o gateway-api e fiscal-api, através de redes de computadores, quando estes serviços respondem, o integration-api converte para uma mensagem, enviando para o ActiveMQ novamente, e finalmente o store-api conclui toda a transação. Vale ressaltar que neste modelo os processos são assíncronos, ou seja, não ocorrem travamentos de uma linha de processamento em função de uma resposta. O sistema conecta-se semelhantemente a gatilhos, quando um processo termina, é disparando um evento, dando início a outro, sem gerar travamentos de processamento.
5. CONSIDERAÇÕES FINAIS/CONCLUSÕES
A uma taxa de 20 transações por segundo, a arquitetura desenvolvida para o caso de uso da CStore (figura 2) demonstrou-se capaz de processar todas as transações recebidas durante a Black Friday de 2022, com segurança. Porém, com limite máximo de 20 transações por segundo, caso o sistema seja submetido a uma carga que supere este valor, a utilização com paralelismo (figura 7) deve ser utilizada. Com o ponto positivo de não haver limite ao número de instâncias da store-api. Com isso em mente, é possível monitorar o recebimento de transações e controlar a quantidade de instâncias conforme o uso. Para este caso de uso, consideramos adequado manter uma instância ao longo do ano e três durante a Black Friday.
Foi interessante observar que os indicadores internos da aplicação mantiveram-se constantes, inclusive com o sistema em estado de ruptura. Apresentando alta divergência entre o tempo de execução e o tempo de espera real. Demonstrando que apenas medir o tempo de execução interno, não revela o tempo de resposta real. Este trabalho investigou a arquitetura de microsserviços e sua aplicação em um sistema de software moderno. Ao longo da pesquisa, examinamos os benefícios, desafios e melhores práticas associados a essa abordagem arquitetônica. Os principais achados deste estudo incluem a escalabilidade e resiliência, dado que, essa arquitetura permite replicar instâncias do mesmo projeto, trabalhando em conjunto, permitindo que os componentes individuais sejam dimensionados independentemente. Isso melhora a resiliência e o desempenho do sistema. O desacoplamento e a manutenção, são outros dois pontos fortes desse modelo, uma vez que, a arquitetura de microsserviços promove o desacoplamento entre os serviços, simplificando a manutenção e facilitando as atualizações e correções de bugs.
Este estudo serve como um ponto de partida para uma compreensão mais profunda da arquitetura de microsserviços e suas implicações no desenvolvimento de sistemas de software modernos. À medida que essa abordagem continua a evoluir, é essencial que pesquisas adicionais e experiências práticas continuem a informar e melhorar as práticas de desenvolvimento de microsserviços.
6. REFERÊNCIAS BIBLIOGRÁFICAS
SOMMERVILLE, Ian. Engenharia de Software. 10. ed. São Paulo: Pearson, 2018.
DZIAK, M. Computer Software. Salem Press Encyclopedia of Science, [s. l.], 2023. Disponível em: <https://research.ebsco.com/linkprocessor/plink?id=08cb1fff-1e03-3d69-b256-05e15f9b25b5>. Acesso em: 16 out. 2023.
MORAIS, Izabelly Soares de (org.). Engenharia de software. 1. ed. São Paulo: Pearson, 2017.
GALLOTTI, Giocondo Marino Antonio (org.). Arquitetura de software. 1. ed. São Paulo: Pearson, 2016.
BLOOMBERG, Silicon Valley Braces For AWar Of The Pens.Disponível em: <Silicon Valley Braces For A War Of The Pens – Bloomberg> Acesso em: 10 out. 2023.
MEDIUM, When Did Smartphones Become Popular?.Disponível em: <When Did Smartphones Become Popular? | by Freedomguider | Medium> Acesso em: 10 out. 2023.
NEWMAN, S. Migrando sistemas monolíticos para micros serviços. [s.l.] Novatec Editora, 2020.
Sebrae, Veja a importância do e-commerce para acessar o mercado internacional. Disponível em: <Veja a importância do e-commerce para acessar o mercado internacional – Sebrae>. Acesso em: 26 out. 2023
EINAV, Y. Amazon found every 100m so flatency costthem1% insales. GigaSpaces, 20 jan. 2019. Disponível em: <https://www.gigaspaces.com/blog/amazon-found-every-100ms-of-latency-cost-them-1-in-sales/>. Acesso em: 25 out. 2023.
Black Friday Death Count. Disponível em: <https://blackfridaydeathcount.com/>. Acesso em: 26 out. 2023.
MCFADDEN, R. D.; MACROPOULOS, A. Wal-Mart Employee Trampled to Death(Published 2008). The New York Times, 28 nov. 2008.
APFELBAUN, M. L. Philadelphia’s Black Friday. American Philatelist, v. 69, n. 4, p. 239, 1966.
ARNOLD, M. J.; REYNOLD, K.E. Hedonic shopping motivations. Journal of Retailing 79, 77-95. 2003.
Thomas, Gordon, and Max Morgan-Witts. The Day the Bubble Burst: A Social History of the Wall Street Crash of 1929. Open Road Media, 2014.
GUERRA, A. A. C.; GHISI, M. A.; NIELSEN, F. A. G. Aspectos benéficos e detratores do BlackFriday no Brasil: um estudo sobre as práticas adotadas pelos varejistas para essa data promocional. In. Anais do X (CLAV):, São Paulo. X Congresso Latino-americano de Varejo (CLAV), 2017.
SWILLEY, E.; GOLDSMITH, R. Black Friday and Cyber Monday: Understanding consumer intentions on two major shopping days. Journal of Retailing and Consumer Services, v. 20, n. 1, p. 43-50, 2013.
DISSE, M. G. 61%dos brasileiros compram mais pela internet do que em lojas físicas, aponta pesquisa. Disponível em: <https://www.supervarejo.com.br/e-commerce/61-dos-brasileiros-compram-mais-pela-internet-do-q ue-em-lojas-fisicas-aponta-pesquisa/#:~:text=E%2Dcommerce->. Acesso em: 26 out. 2023.
SPC Brasil, . Influência da internet nas compras em lojas físicas. Disponível em:<spc_brasil_analise_compras_on_off_maio_20151.pdf (spcbrasil.org.br)>. Acesso em: 26 out. 2023.
SWOYER, M. L., Steve. Microservices Adoption in 2020. Disponível em: <https://www.oreilly.com/radar/microservices-adoption-in-2020/>. Acesso em: 27 out. 2023.
ALSHUQAYRAN, Nuha; ALI, Nour; EVANS, Roger. A systematic mapping study inmicro service architecture. In: 2016 IEEE 9th International Conference on Service-Oriented Computing and Applications (SOCA). IEEE, 2016. p. 44-51.
RICHARDSON, Chris. Microservices patterns: with examples in Java. Simon and Schuster, 2018.
SPRING. spring.io. Disponível em: <https://spring.io/>. Acesso em: 07 nov. 2023. JAVA. java. Disponível em: <https://www.java.com/pt-BR/>. Acesso em: 07 nov. 2023. Express. Express-frameworkdeaplicativodaweb. Disponível em:<https://expressjs.com/pt-br/>. Acesso em: 07 nov. 2023.
JavaScript. JavaScript Disponível em: <https://developer.mozilla.org/pt-BR/docs/Web/JavaScript>. Acesso em: 07 nov. 2023.
POSTGRESQL. PostgreSQL:Theworld’smostadvancedopensourcedatabase.Disponível em: <https://www.postgresql.org/>. Acesso em: 07 nov. 2023.
DOCKER. Dockeroverview. Disponível em: <https://docs.docker.com/get-started/overview/>. Acesso em: 07 nov. 2023.
ACTIVEMQ. ActiveMQ. Disponível em: <https://activemq.apache.org/>. Acesso em: 07 nov. 2023.
JMETER. ApacheJMeter—ApacheJMeterTM. Disponível em: <https://jmeter.apache.org/>. Acesso em: 07 nov. 2023.
7. Apêndice A
Link para o repositório com código-fonte do projeto: FREITAS, L.o. store-api. Disponível em: <https://github.com/Leo3965/store-api>.
8. Apêndice B
Gerador de identificador: Disponível em: <https://github.com/Leo3965/store-api/blob/main/Demo.java>.