Bienvenue dans la troisième édition de notre rapport d'avancement du développement technique, où nous approfondirons l'ingénierie des performances utilisée pour alimenter le prochain Klever Exchange.
Encore une semaine super chargée, avec tant de challenges à surmonter et ensemble, en nous soutenant les uns les autres, nous l'avons fait !
L'équipe a gardé sa concentration, son travail acharné et sa passion. C'est pourquoi je ne ressens que de l'excitation !
Ingénierie des performances
Cette semaine, parlons de notre ingénierie de performance utilisée par l'équipe technique de Klever.
Ce sont les processus en coulisse qui nous permettent de créer le Klever Exchange, un échange à haute performance, avec notre objectif primordial d'être un échange moins cher, permettant de traiter une énorme quantité de transactions avec de petits montants et des frais peu élevés.
Notre processus d'ingénierie de la performance fait partie de notre équipe #devsecops avec des spécialistes interdisciplinaires qui ont rejoint l'équipe #KleverEx pour appliquer leur expertise.
Ce processus garantit des performances et une résilience élevées dans nos services, des phases de développement à l'environnement de production. C'est une opération cyclique, qui est chargée dans chaque nouvelle version du produit #KleverEx.
L'objectif est de trouver et de supprimer les éventuels goulots d'étranglement qui pourraient limiter le débit de l'échange et son service à nos utilisateurs.
Nous voyons comment le service se comportera avec une charge extrême et lourde, puis analysons les améliorations architecturales logicielles, en recherchant toujours une solution plus évolutive et plus performante avec le coût le plus bas possible.
Avant de passer aux résultats, parlons un peu de l'architecture logicielle utilisée pour alimenter le #KleverEx. Il est basé sur l'architecture Event Driven Microservice basée sur Kubernetes (K8s) et Golang.
Cette solution nous garantit d'avoir :
-
Structure à couplage lâche – Les créateurs d'événements, comme lorsque vous créez une commande ou que votre commande est exécutée, et les consommateurs d'événements, comme l'interface utilisateur vous informant de l'état de vos commandes, vaguement couplée à l'aide du bus d'événements, qui les aide au couple et se découpler en différentes plateformes (Android ou IOS) en réponse à divers événements. Cela nous permet également de faire en sorte que différents développeurs développent différents processeurs d'événements avec une plus grande vitesse. Et utilisez ces composants et réutilisez-les également par de nombreuses plates-formes différentes.
-
Analyse en temps réel – Architecture optimisée axée sur les événements pour l'analyse en temps réel. Il a une capacité beaucoup plus élevée de trouver, d'analyser, puis de répondre aux modèles à temps avant que les événements critiques ne se produisent, évitant ainsi leur occurrence dans la production. Utilisation du traitement d'événements complexes pour réaliser des analyses en temps réel.
-
Polyvalence – Un système qui suit une architecture événementielle facilite une plus grande réactivité, car les systèmes événementiels sont, par conception, normalisés pour des environnements imprévisibles, non linéaires et asynchrones. Ces systèmes sont hautement adaptables dans différentes circonstances.
En termes simples, cette architecture logicielle signifie :
-
Moins d'efforts pour construire le #KleverEx pour les 3 plateformes prévues : Android, IOS et Web ;
-
Une UI temps réel, pour les 3 plateformes prévues ;
-
Et une solution plus résiliente.
Kubernetes, développé à l'origine par Google, nous permet de créer et de reconstruire des environnements comme nous le souhaitons, et autant dont nous avons besoin. En utilisant Infrastructure as code, nous pouvons adapter les environnements et les services à nos besoins, uniquement dans la limite de notre budget avec les fournisseurs de cloud.
Ainsi, après chaque version, nous exécutons le test de charge dans l'environnement de transfert et validons si les performances sont meilleures que la dernière version. Si c'est pire, nous bloquons simplement cette version de code et demandons à l'équipe de corriger les goulots d'étranglement trouvés dessus.
À titre d'exemple, dans l'une de nos mesures des services, déclenchée par un code de version candidate, nous venons d'atteindre la limite de performance à 114 utilisateurs virtuels (bots ou robots qui effectuent des demandes non-stop sans temps de réflexion).
Ainsi, l'équipe analyse les données de performance, identifie les goulots d'étranglement et les limites de l'architecture logicielle, et optimise en fonction de ces résultats.
Ainsi, le lendemain, après des changements de code, l'amélioration de l'utilisation du cache dans le niveau de service et bien d'autres améliorations, nous avons répété le test sur la version fixe et atteint le premier niveau de performance nécessaire, c'est-à-dire 250 utilisateurs virtuels (bots ou des robots qui font des requêtes non-stop sans temps de réflexion).
Nous avons exécuté le test jusqu'à ce qu'il atteigne 550 utilisateurs virtuels et que le service conserve les bonnes performances ci-dessus, nous avons donc donné le feu vert à cette version.
En utilisant ces méthodes, nous continuons à améliorer nos services pour apporter à notre communauté une expérience Klever Exchange haute performance et évolutive.
Voyons maintenant les progrès globaux des autres équipes la semaine dernière :
Échange Klever
Klever Wallet
Klever Hard Wallet
Klever Workspace
J'espère que vous avez aimé en savoir plus sur l'ingénierie de performance de #KleverEx cette semaine et les progrès techniques généraux réalisés par notre équipe. J'ai hâte de vous voir la semaine prochaine !
Sincèrement,
Bruno Campos
CTO chez Klever