¿Cómo hacemos Sportmaster?

Hola a todos! Estoy seguro de que muchos de ustedes alguna vez han comprado una camiseta, pelota, zapatillas de deporte, bueno, o algún otro equipo deportivo en nuestras tiendas, pero pocas personas saben qué es Sportmaster desde un punto de vista técnico.


Un poco de 2003 Sportmaster de web.archive.org

Mi nombre es Dmitry, soy desarrollador senior de Java en Sportmaster, y hoy me gustaría hablar sobre nuestra tienda en línea, sobre qué camino siguió para convertirse en la forma en que lo conoces ahora: cómo comenzamos, cómo nos desarrollamos qué sucedió y qué no, sobre los problemas de hoy y sobre los planes para el futuro. Interesante? ¡Bienvenido a cat!

La historia de la presencia de nuestra empresa en la web comenzó ya en 1999 con el primer sitio del Sportmaster, que era solo una tarjeta de presentación y un catálogo de productos para compradores mayoristas. En realidad, la tienda en línea de la compañía tiene su historia desde 2001. En aquellos días, la compañía no tenía su propio equipo para desarrollar proyectos en línea, y la tienda en línea logró cambiar varias plataformas de fabricación propia (ahora ni siquiera recordamos cuántas). La primera solución relativamente estable para nosotros fue creada por el próximo integrador en 2011 en PHP, basado en CMS 1C Bitrix. El sitio resultó ser simple, de hecho, se utilizó la funcionalidad en caja de Bitrix, con pequeñas personalizaciones para realizar un pedido. Para el hardware, la configuración inicial incluía 2 servidores de aplicaciones y un servidor de base de datos.

Mientras tanto, la compañía comenzó a desarrollar activamente sus propias competencias en el campo de las ventas en línea, principalmente del lado del negocio, que, debo decir, se desarrolló bastante rápido, y el equipo de desarrollo se vio obligado a crecer rápidamente en todos los sentidos para satisfacer sus necesidades. En menos de un año, tres equipos comenzaron a responder de inmediato por el desarrollo y el soporte del sitio: el integrador mismo, el equipo interno del Sportmaster, que en ese momento consistía en unas pocas personas y otro contratista, su apariencia, de hecho, se debió al hecho de que el integrador en ese momento no podía proporcionar las capacidades que necesitábamos para las personas.

¿Qué problemas tuvimos en ese momento? Hubo muchos problemas, pero el más importante es el funcionamiento inestable de nuestra tienda en línea.

Podríamos caer incluso por el hecho de que el negocio llevó a cabo algún tipo de boletín informativo, después del cual ~ 2000-2500 personas llegaron al sitio o, como recuerdo ahora, un banner publicitario en Yandex nos envió a una profunda caída. Por supuesto, tales cosas son inaceptables, porque esto no solo es la pérdida de ganancias, sino también la imagen de la empresa; en general, entendimos que algo necesitaba ser cambiado. En primer lugar, se dio cuenta de que las soluciones estándar con nuestras cargas de trabajo (en ese momento no muy grandes, pero aún así no pequeñas) no funcionarían. Luego tuvimos ~ 1000 visitantes en línea normalmente, ~ 2500 en el pico, más planes de desarrollo x2 anualmente.

Se intensificó de inmediato en términos de hardware: agregamos 2 servidores de aplicaciones más e hicimos un clúster de 2 servidores de bases de datos. Nuestra pila en ese momento era nginx, MySQL, PHP. Paralelamente, intentamos optimizar la solución actual: buscamos cuellos de botella, intentamos reescribir todo lo que era posible. Como nuestro cuello de botella era la base, siempre fue el primero en "morir", decidimos descargarlo al máximo. Se implementó la esfinge para la búsqueda de texto completo y la salida de mosaicos con facetas por los filtros seleccionados y las cachés conectadas. Y listo, esas cargas que resultaron ser fatales para nosotros ayer, comenzamos a aguantar con facilidad.

Junto con esto, se lanzó un piloto en paralelo, dentro del marco del cual querían llevar a cabo una actualización tecnológica del sitio: la transferencia a una plataforma fundamentalmente diferente. Había muchas ideas e ideas: en ese momento, la personalización de todo y de todo, las recomendaciones personales, los correos, los descuentos y otras cosas útiles estaban ganando popularidad, y, por supuesto, también queríamos usar todo esto. Analizamos lo que estaba disponible en el mercado a partir de esto, bueno, y compramos la plataforma más cara según el principio de "Una vez más caro, luego más fresco". La implementación se planeó con la ayuda de un integrador, y todavía contábamos con el apoyo y el desarrollo de la IM condicionalmente antigua hasta que la nueva se puso en funcionamiento en la nueva plataforma.

Pero dado que la velocidad del desarrollo funcional del sitio actual era muy alta, decidimos que comenzaríamos a implementar la nueva plataforma de comercio electrónico desde la tienda en línea más pequeña y sencilla de la cadena minorista de Austin, que también fue atendida por el equipo IT Sportmaster. En el proceso, nos dimos cuenta de que la cosa era fuerte y funcionalmente sofisticada, pero tecnológicamente obsoleta, y encontrar personas para implementarlo completamente resultó ser un gran problema. Además, el dimensionamiento realizado antes del inicio del proyecto redujo los requisitos de hardware y la cantidad de licencias, la vida resultó ser mucho más cruel. En general, entendimos una cosa: no haremos un Sportmaster al respecto. Y dado que el equipo para migrar a la plataforma ya estaba en proceso de reclutamiento, los muchachos decidieron comenzar a crear prototipos de su propia solución, en función de los requisitos establecidos por el negocio para la nueva plataforma.

La pila de tecnología se seleccionó de la siguiente manera: Java, Spring, Tomcat, ElasticSearch, Hazelcast.

Como resultado, a finales de 2014, teníamos una nueva versión de mensajería instantánea lista, completamente autoescrita, a la que nos cambiamos con éxito. Ella es la primera versión del sitio que ves hoy. Naturalmente, la versión actual es mucho más funcional y tecnológica, pero la plataforma básica es la misma.

Tareas principales

Por supuesto, cuando hablamos de una gran tienda en línea, estamos hablando de la voluntad de hacer frente no solo a las cargas diarias, sino también a las cargas máximas, para ser estables para las empresas y los usuarios finales.

Los principales enfoques aquí son la capacidad de escalar horizontalmente y la aplicación de enfoques de almacenamiento en caché de datos en diferentes niveles. Y ahora, como hace algún tiempo, decidimos optimizar el acceso a nuestros datos. Pero no podemos usar el almacenamiento en caché de página normal. En general Este es un requisito comercial, y el requisito es bastante razonable: si muestra un precio incorrecto o la disponibilidad incorrecta de los bienes en un momento determinado al usuario del sitio, lo más probable es que esto conduzca a un rechazo de la compra y una disminución de la lealtad del cliente.

Y está bien si el cliente ordenó 15 pares de calcetines por 299 rublos, y en la tienda descubrió que, de hecho, solo hay 14 pares y 300 rublos cada uno, de alguna manera puede vivir con ellos. Acepta, compra lo que es y vive con esta cicatriz en tu alma. Pero si las discrepancias en los números son graves, o si estaba buscando un tamaño específico, y se agotó mientras leía las reseñas de los felices propietarios de pantalones cortos a cuadros, aquí todo es más triste. Es decir, inmediatamente la pérdida de un cliente satisfecho (hasta este punto) y la pérdida de tiempo y dinero en el trabajo del centro de llamadas, donde este cliente llamará para averiguar qué sucedió y por qué.

Por lo tanto, el usuario siempre debe ver el último precio y los datos más actuales sobre saldos de productos básicos y, por lo tanto, nuestros cachés son inteligentes y saben cuándo cambian los datos en la base de datos. Para el almacenamiento en caché usamos Hazelcast.

Por cierto, sobre las sobras

Es importante señalar aquí que la profundidad de los residuos de productos básicos es muy pequeña. Y una gran cantidad de pedidos van a recoger (muy). Por lo tanto, el cliente normalmente debe reservar los productos en la tienda correcta y realizar un seguimiento de los saldos. En un momento, en Bitrix, el problema de los residuos fue abordado por el hecho de que simplemente consideraban que cualquier remanente de más de 10 unidades era infinito. Es decir, todo lo que es más de 10 siempre es igual a 10, pero los valores más bajos ya son interesantes para que los calculemos y los tomamos en cuenta, los subimos al sitio.

Ahora ya no es posible hacer esto, por lo que descargamos los restos de todas las tiendas cada 15 minutos. Y tenemos alrededor de 500 tiendas, además de varios almacenes regionales, además de varias cadenas minoristas. Y todo esto debe actualizarse con prontitud. La clave aquí es el hecho de que las condiciones de trabajo de las empresas de mensajería a menudo cambian en la escala de la Federación de Rusia, por lo tanto, los parámetros de entrega también deben cargarse. Además, se entrega un flujo continuo de bienes a los almacenes de la compañía, por lo que se espera que cambie la cantidad de bienes en los almacenes. Por lo tanto, también debe ser retirado nuevamente.

Y así es como se forman los identificadores de artículos de productos básicos (SKU). Tenemos alrededor de 40,000, los llamados modelos de productos en color. Si vamos más allá del tamaño de los productos, obtenemos aproximadamente 200,000 SKU. Y para todo esto, 200,000 necesitan ser actualizados en la escala de 500 tiendas.

También tenemos decenas de miles de ciudades y pueblos a los que entregamos productos desde tiendas o desde almacenes. Por lo tanto, resulta que la variabilidad de caché para solo una página de producto (ciudad * SKU) es una millonésima parte de un valor. Nuestro enfoque es el siguiente: el cálculo de la disponibilidad de una unidad de producto en particular se produce sobre la marcha cuando el usuario ingresa la tarjeta del producto. Observamos el trabajo de los correos en la región del usuario, observamos su horario de trabajo, calculamos la cadena de entrega y consideramos su duración. Junto con esto, los restos en las tiendas cercanas se analizan en paralelo, desde donde se puede organizar el transporte.

Para facilitar la gestión de todo esto, tenemos un cierto número de cachés muy rápidos en la aplicación, gracias a esto podemos obtener rápidamente todos los datos necesarios por ID y clasificarlos sobre la marcha. Lo mismo con los correos: los agrupamos en grupos y luego los grupos ya están guardados en la base de datos. Cada 15 minutos, todo esto se actualiza, para cada solicitud entrante calculamos un cierto grupo de correos con los parámetros necesarios, los agregamos y los entregamos rápidamente al comprador; todo está bien, definitivamente tenemos esos pantalones cortos verdes de tamaño 50, puede elija con bolígrafos en estas tres tiendas cercanas en este momento, o ordene en una tienda al otro lado de la carretera (o incluso en casa) durante 3 días, elija.

Para Moscú, esta situación puede parecer innecesaria, pero para las regiones este es un asunto completamente diferente, a menudo solicitan productos a algunas de las tiendas (que, tal vez, también es necesario acceder especialmente).

Figuras

Ahora el sitio recibe miles de solicitudes por segundo, teniendo en cuenta las estadísticas y 500-1000 solicitudes por segundo a los servidores de aplicaciones. El número de servidores de aplicaciones no ha cambiado, pero su configuración ha crecido significativamente. Se obtiene un promedio de aproximadamente 3,000,000 de visitas por día.

Los DDoS a veces se encuentran en el sitio. Al mismo tiempo, están tocando con botnets, además, nuestros familiares de la Federación Rusa. Hace mucho tiempo hubo casos de intentos de tocar redes de bots de México y Taiwán, pero ahora ya no es así.

Hay una serie de soluciones para la protección de la nube contra DDoS en el mercado, sí, y muy buenas. Pero para ciertas políticas de seguridad, no podemos usar este tipo de soluciones en la nube.

Que ahora

Comenzamos a hacer una solución de plataforma, separando los equipos no verticalmente (algunos de ellos vieron un sitio, y el segundo vio otro), sino horizontalmente, resaltando la capa de plataforma común, dividiéndola en partes, formando un equipo a su alrededor. Y en ellos ya estamos cerrando el sitio y no solo, incluidos los clientes de la empresa, tanto externos como internos. Por lo tanto, tenemos mucho trabajo complejo e interesante.

La pila en el frente, por razones obvias, realmente no ha cambiado durante este tiempo: Java, Spring, Tomcat, ElasticSearch, Hazelcast siguen siendo buenos para nuestras necesidades. Otra cosa es que ahora muchos sistemas de back-office en diversas tecnologías están ocultos detrás del sitio. Y, por supuesto, la reingeniería está en marcha (porque las solicitudes de sistemas internos y trabajar con ellos en su conjunto deben optimizarse, además no nos olvidamos de los requisitos comerciales y las nuevas funciones comerciales).

Y puede enviarme de forma segura (en comentarios) cualquier sugerencia sobre cómo mejorar el sitio, tanto en términos de nuevas características como del componente visual y la experiencia general del usuario. Intentaremos responder rápidamente y tener en cuenta todo. Y si quieres formar parte del equipo y lo viste todo desde adentro, bienvenido .