{"id":12668,"date":"2018-02-16T09:00:09","date_gmt":"2018-02-16T11:00:09","guid":{"rendered":"https:\/\/king.host\/blog\/?p=12668"},"modified":"2025-09-26T14:34:42","modified_gmt":"2025-09-26T17:34:42","slug":"novo-shopping-cart-kinghost","status":"publish","type":"post","link":"https:\/\/king.host\/blog\/a-kinghost\/novo-shopping-cart-kinghost\/","title":{"rendered":"O Novo Shopping Cart da KingHost &#8211; Case de Desenvolvimento"},"content":{"rendered":"<p>Hoje vou comentar sobre o processo de desenvolvimento do novo shopping cart, o carrinho de compras, da <a href=\"https:\/\/www.kinghost.com.br\/?utm_source=lab&amp;utm_medium=post&amp;utm_term=&amp;utm_content=shopping-cart&amp;utm_campaign=content-marketing\" target=\"_blank\" rel=\"noopener\">KingHost<\/a>. O sistema foi desenvolvido internamente e cuida basicamente de todas as vendas de produtos realizadas na empresa.<\/p>\n<p>Anteriormente \u00e0 mudan\u00e7a, o antigo formato era totalmente acoplado ao site, independente de onde era ofertado o produto. O cliente era encaminhado para o carrinho no site para concluir a compra &#8211; exceto em algumas situa\u00e7\u00f5es, como em compras p\u00f3s-pagas dentro do painel de controle. Ou seja, nosso shopping cart era bastante centralizado, um dos pontos que precisava ser corrigido.<\/p>\n<p>Al\u00e9m de vender produto, o carrinho tamb\u00e9m o configurava.<br \/>\nComo assim o configurava? Sim! Era preciso informar v\u00e1rios dados que seriam necess\u00e1rios para a ativa\u00e7\u00e3o do servi\u00e7o\/produto contratado. Diagnosticamos ent\u00e3o que todo esse processo para o cliente acabava tendo como consequ\u00eancia um alto \u00edndice de abandono de compra.<\/p>\n<p>Como podemos ver nessa imagem, al\u00e9m de alguns desafios de neg\u00f3cios, n\u00f3s t\u00ednhamos v\u00e1rias dificuldades t\u00e9cnicas, como escalabilidade, resili\u00eancia, sistema totalmente monol\u00edtico. Tudo isso causava impacto na hora de dar manuten\u00e7\u00e3o e de criar novas funcionalidades no sistema.<\/p>\n<p>Inicialmente come\u00e7amos a fazer uma an\u00e1lise, buscando entender nossa real necessidade, cases de solu\u00e7\u00f5es e de poss\u00edveis arquiteturas.<br \/>\nUma arquitetura de software que tem ganhado muita aten\u00e7\u00e3o nos \u00faltimos anos \u00e9 a de microsservi\u00e7os. Ela \u00e9 uma alternativa \u00e0 de aplica\u00e7\u00e3o monol\u00edtica e, basicamente, consiste em dividir uma aplica\u00e7\u00e3o grande em v\u00e1rias menores, com prop\u00f3sitos espec\u00edficos.<\/p>\n<p>Se voc\u00ea quer ler mais sobre o assunto, indico este artigo falando sobre quando utilizar <a href=\"https:\/\/king.host\/blog\/2017\/05\/microsservicos-quando-utilizar-este-metodo\/?utm_source=lab&amp;utm_medium=post&amp;utm_term=&amp;utm_content=shopping-cart&amp;utm_campaign=content-marketing\">microsservi\u00e7os<\/a>.<\/p>\n<p>Ap\u00f3s avaliarmos a situa\u00e7\u00e3o, optamos por tentar migrar nosso sistema de vendas para a arquitetura de microsservi\u00e7os. Falo em \u201ctentar\u201d porque quem trabalha ou j\u00e1 trabalhou com sistemas legados sabe que n\u00e3o \u00e9 t\u00e3o f\u00e1cil e simples sair criando algo novo.<\/p>\n<h2>Arquitetura do Novo Shopping Cart<\/h2>\n<p>Com o desenvolvimento da nova arquitetura, separamos as responsabilidades, deixando no shopping cart somente o necess\u00e1rio para o cliente conseguir adquirir os servi\u00e7os. Assim, ficou para outra etapa a configura\u00e7\u00e3o do produto, com isso j\u00e1 diminu\u00edmos duas etapas do processo de compras antigo.<\/p>\n<p>Distribuindo as responsabilidades, n\u00f3s temos hoje a seguinte arquitetura, com aplica\u00e7\u00f5es isoladas em containers Docker: uma API recebe os dados do pedido e envia para uma fila, essa fila envia para uma outra aplica\u00e7\u00e3o, que ent\u00e3o processa o pedido.<\/p>\n<p>Cart-Admin: sistema interno para gest\u00e3o de produtos, combos e pedidos;<br \/>\nSite e Cart-Client: Interface do carrinho de compras;<br \/>\nCart-Painel: Interface do shopping cart dentro do painel de controle;<br \/>\nAPI Oauth: API de autentica\u00e7\u00e3o de aplica\u00e7\u00f5es clients e usu\u00e1rios internos;<br \/>\nDB Master: Banco de dados legado, onde pedidos s\u00e3o inseridos;<br \/>\nDB Slave: R\u00e9plica do DB Master, para consultas necess\u00e1rias na API do Cart, assim a API Cart n\u00e3o tem depend\u00eancia do banco de dados legados;<br \/>\nCart-Server: API, fila e o consumer<\/p>\n<p>Abaixo temos uma vis\u00e3o mais detalhada sobre as aplica\u00e7\u00f5es que recebem, enviam para a fila e processam o pedido.<\/p>\n<p>Optamos por ter uma fila utilizando o RabbitMQ para termos total controle e independ\u00eancia dos sistemas legado. Se, por algum motivo, o consumer n\u00e3o conseguir inserir o pedido, a fila consegue gerenciar isso, fazendo novas tentativas ou at\u00e9 armazenando em uma fila de erros.<br \/>\nCom esta arquitetura, temos a possibilidade de escalar facilmente cada aplica\u00e7\u00e3o ou banco de dados, conforme a necessidade. Tamb\u00e9m podemos adicionar o carrinho onde for necess\u00e1rio, fazendo somente a integra\u00e7\u00e3o com a API.<\/p>\n<h2>Monitoramento \/ Logs<\/h2>\n<p>Uma arquitetura de microsservi\u00e7os distribu\u00eddo \u00e9 muito mais dif\u00edcil de monitorar, mas \u00e9 imprescind\u00edvel, para isso n\u00e3o poupamos na monitoria e logs.<\/p>\n<p>Para monitorar as aplica\u00e7\u00f5es e a comunica\u00e7\u00e3o entre elas, utilizamos a stack open source da Elastic.<\/p>\n<p>Com os Bets conseguimos capturar as informa\u00e7\u00f5es que necessitamos como, por exemplo, arquivos de logs e requisi\u00e7\u00f5es HTTP. Atrav\u00e9s do Logstash enviamos para armazenar no Elasticsearch somente os dados que achamos cruciais para identificar poss\u00edveis problemas e, no Kibana, criamos nossos dashboard para visualizar esses dados.<\/p>\n<p>Como nosso desenvolvimento hoje dentro da KingHost \u00e9 basicamente utilizando a linguagem PHP, n\u00f3s tamb\u00e9m utilizamos o Monolog para armazenar os logs e nos notificar se acontecer qualquer problema.<\/p>\n<p>Com o Monolog, n\u00f3s categorizamos e identificamos a gravidade de uma exce\u00e7\u00e3o, por exemplo, e notificamos a equipe por e-mail ou chat, dependendo da gravidade.<\/p>\n<p>Outras stacks que utilizamos para nos auxiliar no monitoramento foi o Prometheus, Grafana, AlertManager, NodeExporter e cAdvisor.<\/p>\n<p>Com esta stack n\u00f3s conseguimos monitorar o servidor e os containers Docker, capturar estas m\u00e9tricas, enviar alertas e criar dashboards no grafana.<br \/>\nPara quem quiser saber mais sobre essa stack e como utiliz\u00e1-la, pode ler o <a href=\"https:\/\/king.host\/blog\/2017\/01\/monitorando-aplicacoes-php-com-prometheus%E2%80%8A-%E2%80%8Aparte-2\/?utm_source=lab&amp;utm_medium=post&amp;utm_term=&amp;utm_content=shopping-cart&amp;utm_campaign=content-marketing\">artigo monitorando aplica\u00e7\u00f5es PHP com Prometheus<\/a>.<\/p>\n<h2>Principais Tecnologias Utilizadas<\/h2>\n<p>Como comentei anteriormente, a principal linguagem utilizada no desenvolvimento de aplica\u00e7\u00f5es na KingHost \u00e9 o PHP. Neste projeto n\u00f3s utilizamos alguns frameworks, como Lumen que \u00e9 um micro-framework do Laravel al\u00e9m do micro-framework Slim.<\/p>\n<p>Al\u00e9m do pr\u00f3prio PHP, utilizamos tamb\u00e9m seus frameworks e as stacks para logs, ferramentas como RabbitMQ para gerenciamento da fila de pedidos, GitLab como reposit\u00f3rio de c\u00f3digo fonte, Jenkins para build e deploy, e Portainer para gerenciar de forma gr\u00e1fica os containers Docker.<\/p>\n<h2>Melhorias e Considera\u00e7\u00f5es Finais<\/h2>\n<p>Como comentei no in\u00edcio do artigo, este projeto foi um dos nossos primeiros utilizando este tipo de arquitetura dentro da KingHost, ent\u00e3o temos muito a melhorar e refinar.<\/p>\n<p>Falando um pouco de resultados e benef\u00edcios, j\u00e1 estamos vendo v\u00e1rios impactos desde a implementa\u00e7\u00e3o do projeto que come\u00e7ou em fevereiro deste ano. Tanto voltado para quest\u00f5es do neg\u00f3cio como para quest\u00f5es t\u00e9cnicas, \u00e9 poss\u00edvel relatar alguns resultados.<\/p>\n<p>Por exemplo, diminu\u00edmos o tempo para o cliente completar a compra, baixamos o \u00edndice de abandono e vendas perdidas, aumentamos a taxa de convers\u00e3o, como consequ\u00eancia aumentando a porcentagem de compras conclu\u00eddas em at\u00e9 60%. E como resultados t\u00e9cnicos, fomos beneficiados com algumas facilidades, como deploys separados, melhor manuten\u00e7\u00e3o, ganho de escalabilidade e flexibilidade.<\/p>\n<p>Essa arquitetura, com a qual temos um grande sistema quebrado em servi\u00e7os menores e mais leves, por crit\u00e9rio de funcionalidades de neg\u00f3cio e integrados via HTTP (ou alguma arquitetura de mensageira), \u00e9 o que forma a famosa arquitetura de microsservi\u00e7os. Evidentemente, existem outros casos que podem usar diferentes tecnologias, bancos de dados compartilhados entre servi\u00e7os, servi\u00e7os que se comunicam com outros servi\u00e7os e assim por diante.<\/p>\n<p>Faz parte do papel do arquiteto de software tomar decis\u00f5es baseadas em trade-offs. Nunca teremos uma solu\u00e7\u00e3o perfeita. Sempre precisamos escolher entre vantagens e desvantagens, como foi o nosso caso com a utiliza\u00e7\u00e3o de microsservi\u00e7os. O importante \u00e9 analisar calmamente qual \u00e9 a melhor abordagem para cada situa\u00e7\u00e3o.<\/p>\n","protected":false},"excerpt":{"rendered":"<p>Hoje vou comentar sobre o processo de desenvolvimento do novo shopping cart, o carrinho de compras, da KingHost. O sistema foi desenvolvido internamente e cuida basicamente de todas as vendas de produtos realizadas na empresa. Anteriormente \u00e0 mudan\u00e7a, o antigo formato era totalmente acoplado ao site, independente de onde era ofertado o produto. O cliente [&hellip;]<\/p>\n","protected":false},"author":285,"featured_media":12685,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[1316],"tags":[1363],"class_list":["post-12668","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-a-kinghost","tag-tecnologia"],"_links":{"self":[{"href":"https:\/\/king.host\/blog\/wp-json\/wp\/v2\/posts\/12668","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/king.host\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/king.host\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/king.host\/blog\/wp-json\/wp\/v2\/users\/285"}],"replies":[{"embeddable":true,"href":"https:\/\/king.host\/blog\/wp-json\/wp\/v2\/comments?post=12668"}],"version-history":[{"count":12,"href":"https:\/\/king.host\/blog\/wp-json\/wp\/v2\/posts\/12668\/revisions"}],"predecessor-version":[{"id":42392,"href":"https:\/\/king.host\/blog\/wp-json\/wp\/v2\/posts\/12668\/revisions\/42392"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/king.host\/blog\/wp-json\/wp\/v2\/media\/12685"}],"wp:attachment":[{"href":"https:\/\/king.host\/blog\/wp-json\/wp\/v2\/media?parent=12668"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/king.host\/blog\/wp-json\/wp\/v2\/categories?post=12668"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/king.host\/blog\/wp-json\/wp\/v2\/tags?post=12668"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}