Apresentando: Magento

Bruno Viana — Thu, 21 Jan 2010 17:11:27 +0000

Atualmente estamos vivendo no Brasil uma realidade que nos EUA já é fato: não basta mais somente ter sua marca na Internet. Você deve vender através dela.

Não é fácil manter uma loja online. Para isso é necessário se preocupar com várias coisas como a forma como serão realizados pagamentos, as formas como será enviado o produto, controle de fraude, e o mais importante: a plataforma que gerenciará a loja.

Antes comércio eletrônico era apenas coisa de gente grande e para manter uma plataforma era necessário uma mão de obra grande e cara. Hoje não temos mais tanto este problema com o surgimento de várias plataformas de e-commerce open source, onde a que entre elas mais se destaca é o Magento.

O Magento é uma ferramenta Open Source desenvolvida pela Varien, empresa que age desde 2001 no segmento de e-commerce. Ele é escrito em PHP utilizando o banco de dado MySQL o que traz muitas vantagens, pois PHP é a linguagem de programação mais utilizada na Web, possuindo uma comunidade forte e ativa.

O Magento possui duas versões: a Community e a Enterprise. A primeira é a versão gratuita, disponibilizada para a comunidade sob a licensa OSL 3.0 que em resumo diz que o software pode ser distribuído desde que se mantenha a referência de seus autores. Já a segunda versão é paga e conta com recursos avançados que a versão Community não tem. Ela é recomendada para quem necessita de um suporte rápido(dado pela própria Varien) e de recursos avançados que lojas grandes possuem. Veja um comparativo das duas versões.

Veja algumas funcionalidades que o Magento possui em sua versão Community:

Gerenciamento de Sites
– É possivel gerenciar vários sites e várias lojas com apenas um Magento instalado.
– Faça update da ferramente com apenas um clique.
Gerenciamento de Catálogo
– Importação e exportação de produtos do catálogo em lote
– Suporte a preços especiais. Por exemplo, grupo de usuário X terá 10% de desconto ou levando 5 peças cada produto fica por Y reais.
Navegação de produtos
– Produtos relacionados
– Venda cruzada
– Venda casada
– Tags
– Avaliação dos usuários
– Comparação de produtos
Outros
– Suporte à SEO
– Relatórios
– Criação de produtos baixaveis(downloadable products)
– Integrado com Google Analytics
– Relatório de vendas
– Veja mais

Compartilhe em outras redes:

Load Balance – “dividir pra conquistar”

Administrador — Tue, 08 Sep 2009 14:57:57 +0000

Nessa segunda-feira recebemos a notícia que o planalto está sendo lançado o blog do planalto:

O problema é que quem tentou acessar o blog hoje a tarde ficou no mínimo, decepcionado com a dificuldade encontrada. Ele passou a tarde toda, praticamente, inoperante. Era difícil ele “resolver” as requisições, e quando isso acontecia, o congestionamento do tráfego, devido a um gande número de acessos, fazia com que a página não renderizasse direito no meu browser. Já passei por problemas parecidos, quando mantinha um site de uma antiga empresa onde trabalhava, e sazonalmente disponibilizavamos um serviço para nossos clientes. Nesse período, nosso site era praticamente inavegável. Consegui resolver esse problema, mais ou menos assim:

Suponhamos que eu tenho um servidor web rodando em uma máquina relativamente boa, mas o número de requisições sobem exponencialmente após colocarmos um novo serviço, ou o blog do planalto, por exemplo.

Bem, primeiro vou explicar rapidamente o que seria uma “requisição”. Todas as vezes que você acessa um endereço, você está fazendo uma requisição em um servidor, que irá “montar” a página que você solicitou e lhe enviar uma resposta. Esse processo acontece todas as vezes que alguém acessa um endereço para o seu servidor.

Quando essas requisições aumentarem, vai chegar em um momento que o servidor não vai aguentar, ficará lento e não enviará respostas as requisições. Esse tipo de problema é bem mais comum do que você pensa. E ele pode ser facilmente resolvido com o uso de software livre – Bind e Apache. O grande segredo está na configuração do DNS(BIND). O DNS é o serviço que transforma a URL que você digita no browser em um número de identificação único, que sereia o endereço do servidor. Não irei explicar aqui como se instala e configura o BIND, para esses detalhes vocês podem acessar esse site, lá tem uma extensa documentação de como se implementa e configura o BIND.

Vamos apenas exemplificar como tudo isso funciona. Direi que o domínio da minha empresa é exemplo.com.br. O que muitos não sabem é que o BIND possui uma “feature” chamada round robin. O round robin funciona como uma fila. Por exemplo, suponhamos que existem 3 clientes acessando meus servidores web. O primeiro acessa e o DNS redireciona para o servidor1. O segundo cliente acessa e o servidor DNS redireciona para o servidor2 e o terceiro cliente acessa e o DNS redireciona ao servidor1 novamente… e assim por diante.

Com isso, não preciso comprar um servidor mais potente e consequentemente mais caro para aumentar a capacidade de acessos do meu site, basta eu comprar ou disponibilizar uma outra máquina, que configurada corretamente, irá receber parte das requisições, balanceando assim a carga recebida inicialmente por um único servidor.

Mas ainda temos um problema, e se um dos servidores “cair”? Isso, o nosso caro BIND cuida também, ele notará e passará as resoluções de nomes apenas para os servidores que estão em pleno funcionamento, não deixando assim o nosso serviço “fora” e permitindo assim tolerar falhas de hardware, software, ou então nos permitir fazer manutenções programadas. Ótimo não? Diria que é ótimo em relação ao trabalho que se tem para configurar essa replicação/balanceamento. Mas existem alguns problemas.

Primeiro teriamos um custo maior na atualização e manutenção nos sites e serviços que estão sob essa configuração. Uma sugestão é fazer um ponto de controle do código com SVN, fazendo um controle de exportação das atualizações de versão para todos os servidores.

Um outro problema é de cache de DNS. Porque os DNSs possuem uma cache para as últimas requisições realizadas para agilizar nesse processo de resolução. Isso pode ser um problema porque o balanceamento não seria feito de forma justa para todos os servidores www. Isso, eu não faço idéia de como se resolve.

Com esses passos você tem toda carga de requisições da aplicação balanceada, mas temos outro problema. A quantidade de requisições para a aplicação não diminuiu, ela apenas foi dividida em vários servidores, no entanto, a maioria das vezes que é requisitado algo para a aplicação, a mesma faz uma requisição ao banco de dados, e até agora, nesse processo, ele continua sendo um só, e agora tendo que responder a N aplicações que estão replicadas.

Nós podemos utilizar o mesmo princípio de balanceamento que usamos para nossa aplicação no banco de dados, para isso usaremos o MySQL proxy. Não irei explicar aqui como se instala e configura o MySQL proxy, para isso você pode acessar o site do programa e verificar a documentação.

O MySQL proxy é uma aplicação que você instala entre a sua aplicação e o MySQL. Ela permite monitorar, analizar e transformar as comunicações e com ela você pode, além de fazer o load balance, você pode ainda fazer, testes de falha, análise de querys, filtros e modificações de querys e muito mais.

Compartilhe em outras redes:

Bloix » Open Source

Apresentando: Magento

Load Balance – “dividir pra conquistar”