Como fazemos Sportmaster

Olá pessoal! Tenho certeza de que muitos de vocês já compraram uma camiseta, bola, tênis, poço ou algum outro equipamento esportivo em nossas lojas, mas poucas pessoas sabem o que é o Sportmaster do ponto de vista técnico.


Um pouco do Sportmaster de 2003 em web.archive.org

Meu nome é Dmitry, sou desenvolvedor java sênior da Sportmaster e hoje gostaria de falar sobre nossa loja on-line, sobre o caminho que ele se tornou do jeito que você o conhece agora: como começamos, como desenvolvemos o que aconteceu e o que não, sobre os problemas atuais e sobre os planos para o futuro. Interessante? Bem-vindo ao gato!

A história da presença de nossa empresa na web começou já em 1999, com o primeiro site do Sportmaster, que era apenas um cartão de visita e um catálogo de mercadorias para compradores no atacado. Na verdade, a loja online da empresa tem sua história desde 2001. Naquela época, a empresa não possuía equipe própria para o desenvolvimento de projetos on-line, e a loja on-line conseguiu alterar várias plataformas criadas por você (agora nem nos lembramos quantas). A primeira solução relativamente estável para nós foi criada pelo próximo integrador em 2011 em PHP, com base no CMS 1C Bitrix. O site acabou sendo simples; de fato, a funcionalidade de caixa do Bitrix foi usada, com pequenas personalizações para fazer um pedido. Para hardware, a configuração inicial incluiu 2 servidores de aplicativos e um servidor de banco de dados.

Enquanto isso, a empresa começou a desenvolver ativamente suas próprias competências no campo das vendas on-line, principalmente do lado dos negócios, que, devo dizer, se deram muito rapidamente, e a equipe de desenvolvimento foi forçada a crescer rapidamente em todos os sentidos, a fim de atender às suas necessidades. Em menos de um ano, três equipes começaram imediatamente a responder pelo desenvolvimento e suporte do site - o próprio integrador, a equipe interna do Sportmaster, que na época consistia em apenas algumas pessoas e outro contratado - sua aparência, de fato, devido ao fato de o integrador naquele momento, eu não poderia fornecer as capacidades que precisávamos para as pessoas.

Que problemas tivemos naquela época? Havia muitos problemas, mas o mais importante é a operação instável da nossa loja online.

Poderíamos cair até do fato de a empresa ter realizado algum tipo de boletim informativo, após o qual ~ 2000-2500 pessoas chegaram ao site, ou, como me lembro agora, de um banner de publicidade no Yandex que nos levou a um colapso profundo. Naturalmente, essas coisas são inaceitáveis, porque isso não é apenas lucros cessantes, mas também a imagem da empresa - em geral, entendemos que algo precisava ser mudado. Antes de tudo, percebemos que as soluções padrão com nossas cargas de trabalho (na época não eram grandes demais, mas ainda não pequenas) não funcionariam. Tínhamos ~ 1000 visitantes online normalmente, ~ 2500 no pico, além de planos de desenvolvimento x2 anualmente.

Intensificado imediatamente em termos de hardware: adicionamos mais 2 servidores de aplicativos e criamos um cluster de 2 servidores de banco de dados. Nossa pilha naquela época era nginx, MySQL, PHP. Paralelamente, tentamos otimizar a solução atual - buscamos gargalos, tentamos reescrever tudo o que era possível. Como nosso gargalo era a base, sempre foi o primeiro a “morrer”, decidimos descarregá-lo ao máximo. Esfinge implementada para pesquisa de texto completo e saída de blocos de mercadorias com facetas pelos filtros selecionados e caches conectados. E voila - aquelas cargas que acabaram sendo fatais para nós ontem, começamos a aguentar com facilidade.

Junto com isso, um piloto foi lançado em paralelo, no âmbito do qual eles desejavam realizar uma atualização tecnológica do site - uma transferência para uma plataforma fundamentalmente diferente. Havia muitas idéias e idéias - naquele tempo, a personalização de tudo e de tudo, recomendações pessoais, correspondências, descontos e outras coisas úteis estavam ganhando popularidade, e é claro que também queríamos usar tudo isso. Analisamos o que estava disponível no mercado a partir disso e compramos a plataforma mais cara com o princípio de "Mais uma vez caro, depois mais frio". A implementação foi planejada com a ajuda de um integrador, e ainda tínhamos suporte e desenvolvimento adicional do IM condicionalmente antigo até que o novo fosse colocado em operação na nova plataforma.

Mas como a velocidade do desenvolvimento funcional do site atual era muito alta, decidimos iniciar a implementação da nova plataforma de comércio eletrônico a partir da loja online menor e mais simples da rede de varejo de Austin da época, também atendida pela equipe de TI Sportmaster. No processo, percebemos que a coisa era pesada e funcionalmente sofisticada, mas tecnologicamente obsoleta, e encontrar pessoas para implementá-la completamente acabou sendo um grande problema. Além disso, o dimensionamento feito antes do início do projeto forneceu requisitos muito reduzidos para hardware e o número de licenças - a vida acabou sendo muito mais cruel. Em geral, entendemos uma coisa: não faremos um Sportmaster nele. E como a equipe de migração para a plataforma já estava em processo de recrutamento, os caras decidiram começar a criar uma protótipo de sua própria solução, com base nos requisitos estabelecidos pelos negócios para a nova plataforma.

A pilha de tecnologia foi selecionada da seguinte forma: Java, Spring, Tomcat, ElasticSearch, Hazelcast.

Como resultado, no final de 2014, tínhamos uma nova versão do IM pronta, totalmente auto-escrita, para a qual trocamos com êxito. Ela é a primeira versão do site que você vê hoje. Naturalmente, a versão atual é muito mais funcional e tecnológica, mas a plataforma básica é a mesma.

Principais tarefas

Obviamente, quando falamos de uma grande loja on-line, estamos falando da vontade de lidar não apenas com as cargas diárias, mas também com as cargas de pico - para ser estável para os negócios e usuários finais.

As principais abordagens aqui são a capacidade de escalar horizontalmente e a aplicação de abordagens de cache de dados em diferentes níveis. E agora, há algum tempo, decidimos otimizar o acesso aos nossos dados. Mas não podemos usar o cache regular da página. Geralmente. Esse é um requisito comercial e é bastante razoável - se você mostrar o preço errado ou a disponibilidade incorreta de mercadorias em um determinado momento no tempo para o usuário do site, isso provavelmente levará a uma rejeição da compra e a uma diminuição da lealdade do cliente.

E tudo bem se o cliente encomendou 15 pares de meias por 299 rublos, e na loja ele descobriu que, na verdade, existem apenas 14 pares e 300 rublos cada - você pode, de alguma forma, viver com isso. Aceite, compre o que é e viva com essa cicatriz em sua alma. Mas se as discrepâncias nos números são sérias, ou você estava procurando por um tamanho específico - e ele foi comprado enquanto você lia as críticas dos felizes proprietários de shorts xadrez, aqui tudo já está mais triste. Ou seja, imediatamente a perda de um cliente satisfeito (até este ponto) e a perda de tempo e dinheiro no trabalho do call center, onde esse cliente ligará para descobrir o que aconteceu e por quê.

Portanto, o usuário sempre deve ver o preço mais recente e os dados mais atuais sobre os saldos de commodities e, portanto, nossos caches são inteligentes e sabem quando os dados no banco de dados são alterados. Para armazenar em cache, usamos Hazelcast.

By the way, sobre as sobras

É importante notar aqui que a profundidade dos resíduos de mercadorias é muito pequena. E um número muito grande de pedidos vai para a coleta (muito). Portanto, o cliente normalmente deve reservar as mercadorias na loja certa e acompanhar os saldos. Ao mesmo tempo, no Bitrix, o problema dos resíduos foi resolvido pelo fato de eles simplesmente considerarem qualquer resíduo de mais de 10 unidades como infinito. Ou seja, tudo o que é maior que 10 é sempre igual a 10, mas os valores mais baixos já são interessantes para calcularmos e os levamos em consideração, carregamos no site.

Agora não é mais possível fazer isso, então fazemos o download das sobras de todas as lojas a cada 15 minutos. E temos cerca de 500 lojas, além de vários armazéns regionais, além de várias redes de varejo. E tudo isso deve ser atualizado rapidamente. A cereja do bolo aqui é o fato de que as condições de trabalho das empresas de courier muitas vezes mudam na escala da Federação Russa; portanto, os parâmetros de entrega também devem ser carregados. Além disso, um fluxo contínuo de mercadorias é entregue aos armazéns da empresa, razão pela qual se espera que a quantidade de mercadorias nos armazéns mude. Portanto, ele também precisa ser puxado novamente.

E aqui está como os identificadores de item de mercadoria (SKUs) são formados. Temos cerca de 40.000, os chamados modelos coloridos de mercadorias. Se formos mais além do tamanho das mercadorias, obteremos cerca de 200.000 SKU. E por tudo isso, 200.000 precisam ser atualizados na escala de 500 lojas.

Também temos dezenas de milhares de cidades e vilas para as quais entregamos mercadorias em lojas ou em armazéns. Portanto, a variabilidade do cache para apenas uma página de produto (cidade * SKU) é milionésimos de valor. Nossa abordagem é a seguinte: o cálculo da disponibilidade de uma determinada unidade de commodity ocorre em tempo real quando o usuário entra no cartão do produto. Examinamos o trabalho dos correios na região do usuário, o cronograma de trabalho, calculamos a cadeia de entrega e consideramos sua duração. Junto com isso, os restos nas lojas próximas são analisados ​​em paralelo, a partir dos quais o transporte pode ser organizado.

Para facilitar o gerenciamento de tudo isso, temos um certo número de caches muito rápidos no aplicativo - graças a isso, podemos obter rapidamente todos os dados necessários por ID e resolvê-los rapidamente. O mesmo ocorre com os correios - nós os agrupamos em clusters e, em seguida, os clusters já são salvos no banco de dados. A cada 15 minutos, tudo isso é atualizado. Para cada solicitação recebida, calculamos um determinado grupo de correios com os parâmetros necessários, os agregamos e os entregamos rapidamente ao comprador - tudo está bem, temos definitivamente shorts verdes de tamanho 50, você pode compre com canetas nessas três lojas próximas agora ou faça o pedido em uma loja do outro lado da estrada (ou até em casa) por 3 dias, escolha.

Para Moscou, essa situação pode parecer desnecessária, mas para as regiões esse é um assunto completamente diferente, eles costumam pedir mercadorias para algumas das lojas (às quais talvez você também precise ir).

Figuras

Agora, o site recebe milhares de solicitações por segundo, levando em consideração as estatísticas e 500-1000 solicitações por segundo para servidores de aplicativos. O número de servidores de aplicativos não mudou, mas sua configuração aumentou significativamente. É obtida uma média de cerca de 3.000.000 visualizações por dia.

Às vezes, os DDoS s são encontrados no site. Ao mesmo tempo, eles estão batendo nas redes de bots, além disso, nossos parentes da Federação Russa. Há muito tempo, houve casos de tentativas de derrubar botnets do México e Taiwan, mas agora isso não é mais o caso.

Existem várias soluções para proteção de nuvem contra DDoS no mercado, sim, e muito boas. Mas para certas políticas de segurança, não podemos usar esse tipo de soluções em nuvem.

O que agora

Começamos a criar uma solução de plataforma, separando as equipes não verticalmente (algumas viram um site e a segunda, outro), mas horizontalmente, destacando a camada comum da plataforma, dividindo-a em partes, formando uma equipe em torno dela. E neles já estamos fechando o site e não apenas, incluindo quaisquer clientes da empresa, externos e internos. Portanto, temos muito trabalho complexo e interessante.

A pilha na frente, por razões óbvias, realmente não mudou durante esse período - Java, Spring, Tomcat, ElasticSearch, Hazelcast ainda são bons para nossas necessidades. Outra coisa é que agora muitos sistemas de back-office em várias tecnologias estão ocultos atrás do site. E, é claro, a reengenharia está em andamento (porque as solicitações de sistemas internos e o trabalho com eles como um todo precisam ser otimizadas, além disso, não esquecemos os requisitos de negócios e as novas funções de negócios).

E você pode me enviar com segurança (ou em comentários) pessoais algumas sugestões sobre como melhorar o site - tanto em termos de novos recursos, quanto no componente visual e na experiência geral do usuário. Vamos tentar responder rapidamente e levar em conta tudo. E se você quiser se tornar parte da equipe e ver tudo de dentro - seja bem - vindo .