Bienvenido a la tercera edición de nuestro Informe de progreso de desarrollo técnico, donde profundizaremos en la Ingeniería de rendimiento utilizada para impulsar el próximo Klever Exchange.
Otra semana súper ocupada, con tantos desafíos que superar y juntos, apoyándonos unos a otros, ¡lo logramos!
El equipo mantuvo nuestro enfoque, trabajo duro y pasión. ¡Es por eso que no puedo sentir nada más que emoción!
Ingeniería de desempeño
Esta semana hablemos de nuestra ingeniería de rendimiento utilizada por el equipo técnico de Klever.
Estos son los procesos detrás de escena que nos permiten construir Klever Exchange, un intercambio de alto rendimiento, con nuestro objetivo general de ser un intercambio más barato, lo que hace posible procesar una gran cantidad de operaciones con pequeñas cantidades y tarifas bajas.
Nuestro proceso de ingeniería de rendimiento es parte de nuestro equipo #devsecops con especialistas en el campo que se unieron al equipo #KleverEx para aplicar su experiencia.
Este proceso asegura un alto rendimiento y resiliencia en nuestros servicios, desde las fases de desarrollo hasta el entorno de producción. Es una operación cíclica, que se carga en cada nueva versión del producto #KleverEx.
El objetivo es encontrar y eliminar los posibles cuellos de botella que podrían limitar el rendimiento del intercambio y su servicio a nuestros usuarios.
Vemos cómo se comportará el servicio con una carga extrema y pesada, para luego analizar las mejoras arquitectónicas del software, buscando siempre una solución más escalable y de alto rendimiento con el menor costo posible.
Antes de pasar a los resultados, hablemos un poco sobre la arquitectura de software utilizada para impulsar #KleverEx. Se basa en la arquitectura de microservicio controlada por eventos construida sobre Kubernetes (K8s) y Golang.
Esta solución nos garantiza tener:
-
Estructura débilmente acoplada: creadores de eventos, como cuando crea un pedido o se completa su pedido, y consumidores de eventos, como la interfaz de usuario que le informa sobre el estado de sus pedidos, junto con la ayuda del autobús del evento, que los ayuda a la pareja y desacoplarse en diferentes plataformas (Android o IOS) en respuesta a varios eventos. También nos permite que diferentes desarrolladores desarrollen diferentes procesadores de eventos con mayor velocidad. Y use estos componentes y también reutilícelos en muchas plataformas diferentes.
-
Análisis en tiempo real: arquitectura optimizada basada en eventos para análisis en tiempo real. Tiene una capacidad mucho mayor para encontrar, analizar y luego responder a patrones en el tiempo antes de que ocurran eventos críticos, evitando así que ocurran en la producción. Uso de procesamiento de eventos complejo para lograr análisis en tiempo real.
-
Versatilidad: un sistema que sigue la arquitectura impulsada por eventos facilita una mayor capacidad de respuesta porque los sistemas controlados por eventos están, por diseño, normalizados a entornos impredecibles, no lineales y asíncronos. Estos sistemas son muy adaptables en diferentes circunstancias.
En palabras simples, esta arquitectura de software significa:
- Menos esfuerzo para construir #KleverEx para las 3 plataformas planeadas: Android, IOS y Web;
- Una interfaz de usuario en tiempo real, para las 3 plataformas planificadas;
- Y una solución más resistente.
Kubernetes, desarrollado originalmente por Google, nos permite crear y reconstruir entornos como queramos y tantos como necesitemos. Al usar la infraestructura como código, podemos escalar entornos y servicios para satisfacer nuestras necesidades, solo al límite de nuestro presupuesto con proveedores de nube.
Entonces, después de cualquier lanzamiento, ejecutamos la prueba de carga en el entorno de ensayo y validamos si el rendimiento es mejor que la última versión. Si es peor, simplemente bloqueamos la publicación de ese código y le pedimos al equipo que solucione los cuellos de botella que se encuentran en él.
Como ejemplo, en una de nuestras mediciones de los servicios, disparada sobre un código candidato de lanzamiento, simplemente alcanzamos el límite de rendimiento en 114 Usuarios virtuales (bots o robots que realizan solicitudes sin parar sin tiempo para pensar).
Por lo tanto, el equipo analiza los datos de rendimiento, identifica los cuellos de botella y las limitaciones de la arquitectura del software y los optimiza en función de esos resultados.
Entonces, al día siguiente, después de los cambios en el código, la mejora del uso de la caché en el nivel de servicio y muchas otras mejoras, repetimos la prueba en la versión fija y alcanzamos el primer nivel de rendimiento necesario, es decir, 250 usuarios virtuales (bots o robots que realizan solicitudes ininterrumpidas sin tiempo para pensar).
Ejecutamos la prueba hasta que llega a 550 usuarios virtuales y el servicio mantiene el buen rendimiento anterior, por lo que damos luz verde a esta versión.
Con estos métodos, seguimos mejorando nuestros servicios para brindar a nuestra comunidad una experiencia de Klever Exchange de alto rendimiento y escalabilidad resiliente.
Ahora, veamos el progreso general en otros escuadrones la semana pasada:
Klever Exchange
Klever Wallet
Klever Hard Wallet
Klever Workspace
Espero que haya disfrutado escuchando más sobre la Ingeniería de rendimiento de #KleverEx esta semana y el progreso técnico general realizado por nuestro equipo. ¡No puedo esperar a verte la semana que viene!
Atentamente,
Bruno Campos
CTO en Klever