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
RESUMO
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.
1. INTRODUÇÃO
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.
2. FUNDAMENTAÇÃO TEÓRICA
2.1 MICROSSERVIÇOS
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.
2.2 QUANDO DEVE SER APLICADO?
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.
2.3 GANHOS
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.
- Múltiplos Componentes: Por que isso é bom? Tendo diversos blocos de componentes o sistema consegue ter uma certa independência de execução, como assim? consigo prever cenários no desenvolvimento dos componentes prevendo ações no futuro da aplicação dando a cada processo uma certa ação assim se algum deles não cumprir com a ação dentro da camada de service mash eu vou ter uma certa integridade do sistema porque isso não vai comprometer o sistema, a grande vantagem do microsserviços pode ser definida como essa e também por oferecer fácil manutenção da aplicação.
Construído para negócios: Ela é uma arquitetura bem distinta das demais, geralmente os sistemas construídos são monolíticos caracterizando um só componente principal em que todos dependem inteiramente um do outro o que é no caso é o mais usado do mercado, enquanto na arquitetura de microsserviços as equipes que desenvolvem cada parte da aplicação e são responsáveis por distintas tarefas como banco de dados, tester, camadas do software, rede, rotas das APIs. - Roteamento Simples: Os microsserviços trabalham de forma inteligente o roteamento de dados e informações com terminais inteligentes que trafegam informações específicas e geram uma resposta igualitária a partir de determinada informação, algo que sai um pouco das arquiteturas que empresas usam em seu dia a dia.
- Descentralizado: A arquitetura de microsserviços por usar diversos tipos de softwares e plataformas específicas elas não podem ser centralizadas em um único ponto é necessário haver um mínimo de flexibilidade na iterações dessas ferramentas, as empresas e desenvolvedores que escolhem trabalhar com microsserviços tem como vigência desenvolver e produzir ferramentas que podem ser usadas por qualquer pessoa daquele ambiente e resolver problemas, para ficar mais claro um sistema normal monolítico ele tem sua base de dados centralizada onde todos os processos são conversados por um único fluxo, enquanto os microsserviços para cada ação ou processo tem sua própria base de dados, dando a aplicação sua exclusividade em suas ações.
Resistente a falhas: por cada processo ser independente é muito fácil descobrir de onde surgem erros então existe uma certa eficiência na correção de erros e ajustes de processos inteligentes, já que comunicam entre si é possível prever esses determinados cenários sem comprometer o resto da aplicação então eu posso afirmar que é um sistema analógico que funciona em qualquer cenário mas é claro que esse desenvolvimento exige uma complexidade maior dos outros sistemas monolíticos.
Evolucionário: por ser analógico ele sempre tem a necessidade de evoluir o desenvolvimento de suas ações na maior parte delas são prever cenários de erros, dependendo do sistema por ele possuir uma arquitetura de microsserviços ele tem que conversar com outros sistemas por meio de APIs então é sempre necessário dar ao sistema um desenvolvimento evolucionário.
2.4 DORES NA ARQUITETURA
- Arquitetura complexa: No deadline do desenvolvimento da aplicação será necessário levantar requisitos de diversas ações do sistema em que cada uma delas seja trabalhada pelas equipes sem demandar muito tempo de desenvolvimento e que nos primeiros steps ou primeiras versões da aplicação cada microsserviços consiga conversar entre si sem falhas, o que gera um alto nível de complexidade das equipes para desenvolver.
- Alto custo: Para manter uma aplicação que trabalha com microsserviços vai muito além de complexidade de desenvolvimento mas também em manter diversas tecnologias, ferramentas e bases para o sistema funcionar como servidores, hospedagem, APIs pagas de integrações e outras coisas que são de alto custo para manter a aplicação rodando, por isso eles são bem mais frequentes em grandes sistemas corporacionais.
- Muitas equipes: Para cada microsserviço é necessária uma equipe para mantê-lo porque, na metodologia ágil que é emendada com essa estrutura cada equipe tem seu papel de trabalhar a manutenção e evolução daquele serviço por isso o número de equipes é grande dependendo da aplicaçã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.
2.5 FUNCIONAMENTO
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
2.6 NECESSIDADE DE MICROSSERVIÇ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.
2.7 NTERAÇÕES
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.
2.8 O QUE NÃO É MICROSSERVIÇO
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.
2.9 EXEMPLO DE FUNCIONAMENTO
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.
2.10 DIFERENÇA DAS ARQUITETURAS
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.
3. CASE
3.1 SOBRE A LOJA VIRTUAL DO CLIENTE
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.
3.1.1 OS DESAFIOS PARA CONSTRUÇÃO E ADAPTAÇÃO DA LOJA
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.
3.1.2 ENTENDENDO FLUXO DE COMPRA
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
3.2 O PROBLEMA DA INTEGRAÇÃO COM O ERP
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.
3.3 ENTENDENDO O CENÁRIO DO PROBLEMA POR PARTE DAS EMPRESAS
- A plataforma em que a loja foi desenvolvida por possuir uma arquitetura própria e monolítica, por parte da empresa da plataforma era inviável e fora do negócio fazer uma adaptação para esse cliente pois isso levaria um alto custo de desenvolvimento para adaptação da plataforma pra essa loja em específico.
- A empresa que responde pela camada de pedidos e de segurança também por parte deles nada poderia ser feito até porque a função deles é simplesmente receber os dados e passar isso para os ERP.
- A integração feita com a plataforma possui suas API’s funcionando somente dentro do seu domínio então isso não poderia ser trabalhado por fora da plataforma.
4. A SOLUÇÃO PROPOSTA PELA EMPRESA CONTRATADA
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.
4.1 ENTENDENDO A INTEGRAÇÃO COM O MIDDLEWARE
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.
4.2 COMPOSIÇÃO DO MIDDLEWARE
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.
5.CONSIDERAÇÕES FINAIS
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.
REFERÊNCIAS BIBLIOGRÁFICAS
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.
