Radar de tecnologia: uma lista de idiomas, ferramentas e plataformas que passaram pelas mãos de Lamoda

Nos comentários de nosso último artigo , houve muitas perguntas sobre as tecnologias que usamos. Neste artigo, eu - Igor Mosyagin, desenvolvedor de P&D da Lamoda - vou falar sobre eles. Abaixo do corte, você encontrará uma lista exaustiva de idiomas, ferramentas, plataformas e tecnologias que passaram por nossas mãos. O frontend, backend, banco de dados, intermediários de mensagens, caches e monitoramento, desenvolvimento e balanceamento são uma história detalhada sobre o que usamos hoje e o que abandonamos.



Meus colegas e eu estamos prontos para discutir nos comentários ou no estande da empresa no HighLoad ++ 2018.

Veja o radar em grande e detalhado aqui.

Como já dissemos, um grande número de diferentes tecnologias e ferramentas está envolvido em Lamoda. E isso não é coincidência. Caso contrário, não podemos lidar com a carga! Temos um grande armazém automatizado. Nosso call center é atendido por 500 funcionários e os processos que construímos nos permitem ligar de volta ao cliente em até 5 minutos após a realização do pedido. Nosso serviço de entrega opera em intervalos de 15 minutos. Mas, além de nossos próprios sistemas, temos integração B2B com outras lojas online. Com uma variedade de tarefas e os requisitos de um negócio tão dinâmico como o comércio eletrônico, o crescimento da pilha técnica é inevitável, porque queremos resolver cada problema com as tecnologias mais adequadas. A diversidade é inevitável. Falaremos sobre os principais representantes da nossa pilha abaixo. Mas vamos começar com mecanismos que não nos percam nessa variedade.

Fundamentos da arquitetura

Estamos caminhando ativamente para a arquitetura de microsserviços. A maioria dos sistemas já foi construída de acordo com essa ideologia - há dois anos passamos por um estágio de transição com nossos problemas e suas soluções. Mas não vamos nos aprofundar nos detalhes desse processo - um relatório de Andrey Evsyukov " Recursos de microsserviços no exemplo de uma plataforma e-Com " dirá muito mais sobre isso.

Para não agravar a diversidade tecnológica, introduzimos a “ditadura de práticas comprovadas”, segundo a qual os criadores de novos chips são recomendados para usar as tecnologias e ferramentas que já são usadas em algum lugar da empresa. A maioria dos serviços se comunica entre si por meio da API (usamos nossa modificação da segunda versão do padrão JSONRPC), mas onde a lógica de negócios permite, também usamos o barramento de dados para interação.

O uso de outras tecnologias não é proibido. No entanto, qualquer nova idéia deve ser testada em um comitê de arquitetura criado especialmente, que inclui líderes das principais áreas.

Considerando a próxima proposta, o comitê dá luz verde ao experimento ou oferece algum tipo de substituição da pilha existente. A propósito, essa decisão depende em grande parte das circunstâncias atuais nos negócios. Por exemplo, se uma equipe chegar às vésperas da venda da Black Friday e anunciar que introduzirá tecnologia em produção que o comitê nunca tinha ouvido falar antes, provavelmente será recusada. Por outro lado, o mesmo experimento pode receber luz verde se uma nova tecnologia ou ferramenta for introduzida em circunstâncias comerciais menos críticas, e a implementação começará com testes fora da produção.

O Comitê de Arquitetura também é responsável por manter o radar da tecnologia, fazendo as alterações necessárias a cada 2-3 meses. Um dos objetivos deste recurso é dar às equipes uma idéia do tipo de experiência que a empresa já possui.

Mas vamos para o mais interessante - para a análise dos setores do nosso radar.

Vale ressaltar que usamos uma interpretação um pouco fora do padrão das categorias de adoção de tecnologia:

• ADOTAR - tecnologias e ferramentas implementadas e usadas ativamente;
  
• TESTE - tecnologias e ferramentas que já passaram na fase de testes e estão se preparando para trabalhar com a produção (ou mesmo que já trabalhem lá);
  
• AVALIAÇÃO - ferramentas de avaliação que estão sendo avaliadas no momento e ainda não afetam a produção. Com a participação deles, apenas projetos de teste são implementados;
  
• HOLD - nesta categoria, temos experiência, mas as ferramentas mencionadas são usadas apenas com o suporte dos sistemas existentes - novos projetos não são lançados neles.
  

Desenvolvimento

PHP - Python - Ir

A primeira linguagem que queremos abordar é o PHP. Hoje, ele resolve apenas uma parte das tarefas de back-end da loja e, inicialmente, todo o back-end trabalhava em PHP. À medida que os negócios se expandiam no front-end, a falta de velocidade e produtividade se tornava perceptível - naquela época, usamos o PHP 5, então o Python o substituiu (primeiro 2.xe depois 3.x). No entanto, o PHP permite que você escreva modelos de negócios ricos, de modo que essa linguagem permaneceu no back office para automatizar vários processos operacionais, em particular, integração com lojas online de terceiros ou serviços de entrega, bem como a automação de um estúdio de conteúdo que elabora cartões de produtos. Agora já estamos usando o PHP 7. No PHP, escrevemos muitas bibliotecas para uso interno: integração e wrappers em nossa infraestrutura, camada de integração entre serviços, vários auxiliares reutilizados. O primeiro lote de bibliotecas já foi levado para código aberto em nosso github.com , e o restante, o mais "amadurecido", chegará em breve. Uma das primeiras foi uma máquina de estado, que, presente em quase todas as aplicações, assegura isso com o pedido antes de enviar todas as ações necessárias.

Com o tempo, o Python também se tornou insuficiente para um back-end da loja. Agora, preferimos um Go mais produtivo e leve.

Talvez a transição para o Go tenha sido uma mudança importante, pois economizou muito hardware e recursos humanos - a eficiência aumentou significativamente. Os primeiros que fizeram os primeiros projetos no Go foram o RnD, eles não quiseram lidar com as limitações técnicas do Python. Na equipe de desenvolvimento móvel, havia pessoas que o conheciam e o promoveram para a produção. Desde o envio, realizamos testes e ficamos mais do que satisfeitos com o resultado. Em casos separados, depois que parte do projeto foi reescrita do Python para o Go, o carregamento dos nós do cluster caiu significativamente. Por exemplo, reescrever o mecanismo de cálculo de desconto da cesta do Python para Go nos permitiu processar 8 vezes mais solicitações nas mesmas capacidades de hardware, e o tempo médio de resposta da API foi reduzido em 25 vezes. I.e. O Go mostrou-se mais eficiente que o Python (se você o escrever corretamente), mesmo que não seja tão conveniente para o desenvolvedor.

Como o desenvolvimento móvel teve que interagir com dezenas de APIs internas, foi criado um gerador de código que, de acordo com a descrição do serviço de API (de acordo com a especificação Swagger), um cliente pode gerar no Go. O Go on começou gradualmente a corresponder aos serviços e ferramentas existentes, especialmente aqueles que criaram o "gargalo" da carga. Além de facilitar a vida do desenvolvedor de back-end para dispositivos móveis, simplificamos as convenções internas a seguir sobre como desenvolver APIs, como nomear métodos, como passar parâmetros e assim por diante. Essa padronização facilitou o desenvolvimento e a implementação de novos serviços para todas as equipes.

Hoje, o Go já é usado em quase todos os lugares - em todas as interações em tempo real com os usuários - no back-end do site e aplicativos móveis, bem como nos serviços aos quais eles estão associados. E onde não há necessidade de processamento e resposta rápidos, por exemplo, nas tarefas de interação com o data warehouse, o Python permanece, pois não é igual para as tarefas de processamento de dados (embora exista aqui a penetração).

Como você pode ver no radar, temos Java no ativo. É usado no Sistema de Gerenciamento de Armazém (WMS), ajudando a coletar pedidos rapidamente. Até agora, temos uma pilha bastante antiga e um modelo de arquitetura antigo - um monólito girando no Wildfly 10 e 8 Java Hotspot, e também há remoting e Rich client na Netbeans Application Platform (agora essa funcionalidade é transferida para a Web). Aqui, em nosso arsenal, temos armazenamentos padrão para a empresa e até nosso próprio monitoramento. Infelizmente, não encontramos uma ferramenta que possa visualizar bem a operação do armazém e processos importantes (quando uma seção está sobrecarregada, por exemplo), e nós mesmos fizemos essa ferramenta.

Usamos o Python como o principal idioma para aprendizado de máquina: criamos sistemas de recomendação e classificamos o catálogo, corrigimos erros de digitação nas consultas de pesquisa e também resolvemos outros problemas em conjunto com o Spark em um cluster Hadoop (PySpark). O Python nos ajuda a automatizar o cálculo de métricas internas e testes AB.

Desenvolvimento de front-end e mobile

O front-end da loja on-line para computadores, bem como sites para celular, está escrito em JavaScript. Agora, o front-end está gradualmente migrando para a especificação ES6, criando novos projetos de acordo com ela. Usamos o vue.js como a estrutura principal, mas abordaremos mais detalhadamente na seção de ferramentas.

O desenvolvimento de aplicativos para plataformas móveis é uma unidade separada na empresa, que inclui grupos de back-end, além de aplicativos Android e iOS com suas próprias pilhas e ferramentas de tecnologia, que, devido às diferenças de plataforma, nem sempre é possível unificar toda a unidade.

Há dois anos, todo o novo desenvolvimento do Android está em andamento no Kotlin, o que nos permite escrever um código mais conciso e compreensível. Entre os recursos mais usados, nossos desenvolvedores chamam: smartcast, classes seladas, funções de extensão, typesafe builders (DSL), funcionalidade stdlib.

O desenvolvimento do iOS está em andamento no Swift, que substituiu o Objective-C.

Línguas especiais

A variedade de tarefas do Lamoda não se limita ao desenvolvimento de uma "vitrine" para diferentes plataformas; portanto, temos um número de idiomas que são usados ​​apenas na estrutura de nossos sistemas, funcionam bem lá, mas não serão implementados em outras partes da infraestrutura:

• R - usado para scripts de processamento e relatório de dados dentro da estrutura de business intelligence (BI). Ele não está em produção e não é mais usado para novas tarefas, mas ainda temos vários desses scripts. Resolvendo problemas com o R, percebemos que esse idioma não é para aplicativos altamente carregados. Em novas tarefas, usamos Python e outras tecnologias que são incompatíveis com R.
  
• Scala - usado pelo escritório de desenvolvimento em Vilnius para desenvolver um sistema de automação de call center. Inicialmente, esse sistema foi escrito em PHP, mas durante a transição para uma arquitetura de microsserviço, vários componentes foram reescritos no Scala. Também nele, a equipe de Engenharia de Dados grava trabalhos do Spark.
  
• TypeScript que estamos vendo. A entrega já foi implementada com sua ajuda e, no futuro, usaremos o TypeScript + vue.js no frontend.
  
• Lua é usada para configurar o nginx (via API do nginx); em outros projetos, não é e nunca será.
  
• Somos uma empresa de moda e seguimos a moda para programação funcional. Por exemplo, um emulador de dispositivo de classificação em um de nossos armazéns está escrito em Haskell.
  

Gerenciamento de dados

DBMS, pesquisa e análise de dados

Como muitos, os bancos de dados mais diversos que implementamos no PostgreSQL - ele é usado sempre que bancos de dados relacionais são necessários, por exemplo, para armazenar um diretório. É muito fácil encontrar especialistas nessa tecnologia, além disso, muitos serviços diferentes estão disponíveis.

Obviamente, o PostgreSQL não é o único DBMS que pode ser encontrado em nossa infraestrutura de TI. Em alguns sistemas mais antigos, por exemplo, o MySQL é usado, enquanto o WMS possui um pouco do MongoDB. No entanto, para altas cargas e dimensionamento (levando em consideração o restante de nossa pilha de tecnologias), não os usamos para novos projetos. Em geral, o PostgreSQL é o nosso tudo.

O Aerospike também é visível no radar. Nós o usamos de maneira bastante ativa, mas o contrato de licença foi alterado para o produto, então a versão “our” acabou sendo um pouco cortada. No entanto, agora olhamos para ele novamente. Talvez reconsideremos nossa atitude em relação ao instrumento e a utilizemos de forma mais ativa. Agora, o Aerospike é usado no serviço de agregação de eventos de exibição de página e no trabalho do usuário com a cesta, bem como no serviço de prova social ("5 pessoas adicionaram este produto aos favoritos esta semana"). Agora estamos fazendo recomendações ainda mais íngremes.

O Apache Solr é usado para procurar dados de produção. Paralelamente, também usamos o ElasticSearch. Ambas as soluções são de código aberto, mas, se antes, quando estávamos implementando a pesquisa, o Apache Solr já tinha a terceira ou quarta versão e estava desenvolvendo ativamente, e o ElasticSearch nem sequer tinha o primeiro lançamento estável - era muito cedo para usá-lo na produção. Agora, os papéis mudaram - é muito mais fácil encontrar soluções para o ElasticSearch, e novas pessoas chegaram até nós que são boas em prepará-lo. No entanto, no prod temos o Solr, e não mudaremos para outra solução pelo menos até a Black Friday 2018.


Comparação da dinâmica das consultas de pesquisa Apache Solr (azul) e ElasticSearch (vermelho), de acordo com o Google Trends

A análise de dados ocorre em vários sistemas, em particular, usamos ativamente o Apache Hadoop. Ao mesmo tempo, a coluna Vertica DBMS é usada para armazenar data marts (com um volume total de cerca de 4 TB). Sobre essas vitrines, são elaborados relatórios financeiros, operacionais e comerciais. Para muitas de nossas tarefas ETL, usamos o Luigi anteriormente, mas agora estamos migrando para o Apache Airflow. Também usamos o Pentaho para armazenamento relacional, no qual existem cerca de mil tarefas regulares de ETL.

Parte da análise e preparação dos dados para outros sistemas é realizada no Spark. Em alguns lugares, isso não é apenas uma ferramenta de análise, mas também faz parte da nossa arquitetura lambda.

Um papel importante na infraestrutura de TI é desempenhado pelos sistemas ERP: Microsoft Dynamics AX e 1C. Como DBMS, o Microsoft SQL Server é usado. E para relatórios, seus componentes, como serviços de análise e serviços de relatório.

Armazenamento em cache

Para armazenar em cache, usamos Redis. Anteriormente, essa tarefa era executada pelo MemCached, não podia ser usada como armazenamento de valor-chave com um despejo periódico em disco, portanto a abandonamos.

Filas de mensagens

Como intermediário de eventos, usamos duas ferramentas ao mesmo tempo - Apache Kafka e RabbitMQ.
O Apache Kafka é uma ferramenta que nos permite processar dezenas de milhares de mensagens em vários sistemas em que as mensagens são necessárias. Clusters Kafka separados são implantados para algumas partes altamente carregadas do sistema - por exemplo, para eventos ou log do usuário (tivemos um bom relatório sobre log no Highload ++ 2017 ). Kafka permite que você lide com 6000 mil mensagens em massa por segundo com o uso mínimo de ferro.

Nos sistemas internos, usamos o RabbitMQ para ações adiadas.

Plataformas e Infraestrutura

Entrega contínua

Para a implantação, é usado o Kubernetes, que substituiu o pacote Nomad + Consul da Hashicorp. A pilha anterior funcionou muito mal com atualizações de hardware. Quando nossa equipe de operações mudou os servidores físicos nos quais os nós estavam girando e os contêineres foram armazenados, ele periodicamente se rompeu e travou, sem querer subir. Não havia versão estável naquele momento. Além disso, não usamos o mais recente naquele momento - 0.5.6, que ainda precisava ser atualizado. A atualização para a última versão beta exigiu algum trabalho. Portanto, decidiu-se abandoná-lo e mudar para os Kubernetes mais populares.

Agora Nomad e Cônsul ainda são usados ​​no controle de qualidade, mas no futuro ele também deve se mudar para Kubernetes.

Para implementar a entrega contínua, são usados ​​contêineres Docker, para os quais migramos há dois anos. Para nossos serviços altamente carregados (cesta, catálogo, site, sistema de gerenciamento de pedidos), é importante a capacidade de buscar rapidamente alguns contêineres adicionais de um serviço, por isso temos contêineres em todos os lugares. E o Docker é um dos métodos mais populares de conteinerização, portanto sua presença no radar é bastante lógica.

Como servidor de construção e integração contínua, o Bamboo é implementado, usado em conjunto com o Jira e o Bitbucket (pilha padrão).

Jenkins também é mencionado no radar. Experimentamos com ele, mas não o arrastamos para novos projetos. É uma ótima ferramenta, mas simplesmente não se encaixa na nossa pilha, porque já temos o Bamboo.

Coletados usando os estivadores Bamboo docker são armazenados no repositório sob o controle do Artifactory.

Gerenciamento de processos e balanceamento

Usamos o NGINX Plus, mas não em termos de balanceamento, porque suas métricas não são suficientes para nossas tarefas. Ele não pode dizer, por exemplo, qual solicitação é roteada ou congelada com mais freqüência. Portanto, o HAProxy é usado para equilibrar a carga. Ele pode trabalhar de forma rápida e eficiente em conjunto com o nginx, sem carregar o processador e a memória. Além disso, as métricas de que precisamos estão prontas para uso - o HAproxy pode mostrar estatísticas por nós, pelo número de conexões no momento, pela ocupação da largura de banda e muito mais.

UWSGI é usado para executar aplicativos Python síncronos. O php-fpm foi usado como gerenciador de processos em todos os serviços PHP.

Monitoramento

Usamos o Prometheus para coletar métricas de nossos aplicativos e máquinas host (máquinas virtuais), bem como o banco de dados de séries temporais do aplicativo . Coletamos logs, para isso usamos a pilha ELK, como sistema de alerta usamos o Icinga, configurado para ELK e Prometheus. Ela envia alertas para correio e SMS. O serviço de suporte 6911 recebe os mesmos alertas e decide atrair engenheiros de serviço.

O Prometheus está envolvido em quase todos os lugares e, para isso, temos bibliotecas para todos os idiomas, o que permite o uso de apenas algumas linhas de código para conectar suas métricas ao projeto. Por exemplo, uma biblioteca para PHP está disponível em código aberto ).

Para exibir visualmente os resultados do monitoramento na forma de belos painéis, o Grafana é usado. Basicamente, coletamos todos os painéis do Prometheus, embora algumas vezes outros sistemas também possam servir como fontes.

Para captura e agregação automática de erros, usamos o Sentry, que é integrado ao Jira e facilita o início de um rastreador de tarefas para cada um dos problemas de produção. Ele sabe como capturar o erro com algumas informações adicionais e retorno e, portanto, é conveniente estrear.

As estatísticas sobre o código das solicitações de recebimento criadas são coletadas usando o SonarQube.

Estruturas e ferramentas

Durante o desenvolvimento da infraestrutura de TI da Lamoda, experimentamos quase três dúzias de ferramentas diferentes; portanto, essa categoria é a mais "em larga escala" do nosso radar. Até o momento, são usados ​​ativamente:

• Symfony 3.xe mais recente - Symfony 4.x - para desenvolvimento em PHP;
  
• Django e o mecanismo de modelo Jinja para desenvolvimento em Python. A propósito, o Jinja é usado, inclusive, para configuração no Ansible;
  
• Flask - para serviços internos (junto com o Django), mas na produção não o arrastamos;
  
• Spring - em desenvolvimento Java;
  
• Bootstrap - para uma variedade de ferramentas internas no desenvolvimento da Web (painel de administração, painéis caseiros, etc.);
  
• jQuery - para desenvolvimento de js;
  
• OpenAPI (Swagger) - para documentação de todos os serviços de API, incluindo que são usados ​​para a geração de código acima no Go;
  
• Webpack - para empacotar JS e minimizar CSS;
  
• Selênio - para testar o frontend;
  
• WireMock, JMeter, Allure e outros também são usados ​​em testes;
  
• Ansible - para gerenciamento de configuração;
  
• Kibana - para visualizar os resultados da pesquisa no ElasticSearch.
  

Gostaria de falar sobre o desenvolvimento do JavaScript separadamente. Nós, como muitos, temos todo um campo de experimentos. JavaScript . — Angular, ReactJS, vue.js. « », , vue.js, , .

, GO, PHP, Java, JavaScript, PostgreSQL, Docker Kubernetes.

, . , , . -, . , , , .