Artículo sobre nuestros desarrollos backend
Conoce al equipo: backend al cuidado de la estabilidad del sistema
Esta es la historia de cómo el equipo backend de Onde ha logrado mejorar la estabilidad del sistema buscando soluciones únicas, porque no existen soluciones enlatadas para una plataforma como la nuestra. Conoce a Igor Zubchenok, el CTO de Onde y Artem Shaban, nuestro desarrollador backend.
Igor: Dejé de fumar. Hace dos años prometí dejarlo en el momento exacto en que nuestro servidor estuviera completamente estable. Pensé que sucedería en septiembre de 2017. Bueno, está sucediendo ahora. Los principales servicios que se ejecutan "bajo el capó" de la plataforma Onde son Apache Cassandra, Pulsar, ZooKeeper y nuestra propia Plataforma de Pagos. Nuestro servidor se comunica con todos ellos. La escalabilidad de la solución Onde, y, en consecuencia, la posibilidad de que nuestros clientes hagan crecer sus negocios depende de nuestra capacidad para correr muchos servidores al mismo tiempo.
Esto crea desafíos: sincronización, garantía de la integridad de los datos e intercambio de datos entre instancias. Cada instancia de servidor se comunica con APIs externas (autocompletado de Google, geocodificación, OAuth, ReCaptcha y muchos más). La arquitectura de la plataforma Onde es compleja: hay soluciones matemáticas y algorítmicas geniales, mucha integración con servicios externos e internos, toneladas de lógica empresarial, y capacidad para procesar miles de escenarios.
En los últimos 1,5 años, la carga máxima en nuestro servidor se ha incrementado en alrededor de 40-50 veces, de ≈5000 por día a ≈250000 órdenes por día. Tal crecimiento no pudo más que afectar nuestra plataforma. Necesitábamos resolver muchos problemas a un ritmo acelerado.
Sin dolor no hay ganancia: introduciendo RxJava 2
Artem: Nuestra prioridad era permitir que cada instancia de servidor manejara muchas más operaciones de clientes que antes. Para hacer esto, básicamente reescribimos el servidor usando la programación Reactiva, uno de los conceptos más avanzados que existen ahora, RxJava 2. En pocas palabras, nos acostamos tarde, nos levantamos temprano, trabajamos los fines de semana y los días festivos, aprendimos, experimentamos, intercambiamos ideas, levantamos nuestros servidores y los volvimos a bajar - ¡y los levantamos de nuevo!
Igor: Explicado en términos humanos, es muy parecido a tener cien hijos. Tienes que salir a pasear con ellos y vestirlos. Puedes vestirlos uno por uno: calcetines, pantalones, etc. Cada uno de ellos también debe orinar, por lo que debes llevarlos al baño, uno a la vez. Esto lleva mucho tiempo. Así es como nuestro servidor manejaba las operaciones de los clientes antes. Con RxJava 2 tenemos la posibilidad de vestir a todos los niños simultáneamente, es más rápido y más eficiente, ningún niño (u orden) tiene que esperar. Los niños también pueden orinar al mismo tiempo ahora.
De hecho, utilizamos una tecnología similar, incluso cuando RxJava 2 aún no existía. Resulta que casi creamos RxJava 2 desde cero, pero afortunadamente, alguien más lo hizo por nosotros. 😂 Esta herramienta nos dio incluso más de lo que podríamos esperar. Así que ahora mismo estamos en la vanguardia de la tecnología.
Sin embargo, la programación reactiva con RxJava 2 requiere mucho aprendizaje: lleva seis meses, al menos, aprender sus secretos. Todavía estamos migrando nuestro servidor hacia eso. Ya ahora vemos que nuestro servidor puede vestir a los niños de manera más rápida y eficiente.
Cada operación visualizada: el contexto realmente importa
Artem: hemos creado un sistema para monitorear el estado de la aplicación y visualizar el estado del sistema usando Grafana. Carga de trabajo, dinámicas, cambios resultantes de la introducción de nuevos indicadores: todas estas estadísticas de la vida útil de nuestro servidor se recopilaban previamente en forma de números. Dado que veíamos los números y no los gráficos, era difícil ver los cambios y las tendencias. Hemos creado instrumentos en el servidor para recopilar todas las métricas necesarias y ahora podemos visualizar cualquier indicador.
Igor: cuando alguien crea una orden, alrededor de 40 operaciones pasan por el servidor: se deben cumplir muchas condiciones, por ejemplo, que el mismo comando no pase dos veces, verificar cuánto dinero hay en la cuenta del conductor , comprobar los derechos de acceso del creador del pedido, enviar una solicitud de geocodificación a Google y esperar a que Google orine y te envíe una respuesta.
Así que queremos saber cómo funciona cada operación. Ahora podemos seguir cada proceso y ver dónde baja la velocidad. Por ejemplo, el tiempo que tarda Google en hacer pipí o la rapidez con la que se bloquean los conductores para una operación. En algunos casos, el bloqueo puede ser lento, pero es inaceptable durante la creación de la orden. Hasta que no vimos todos los procesos por separado, no pudimos entender dónde ocurrían los problemas. Ahora estamos rastreando cada indicador en particular y podemos mejorar el rendimiento del sistema de ellos. El servidor realmente vive de nuestros esfuerzos.
Artem: El contexto de las operaciones importa mucho, y ahora lo sabemos. Hay al menos cien gráficos diferentes en Grafana que nos muestran el contexto.
Continuará...
