Willkommen zur dritten Ausgabe unseres Fortschrittsberichts zur technischen Entwicklung, in der wir tiefer in das Performance-Engineering eintauchen, das für die bevorstehende Klever-Börse verwendet wird.
Eine weitere super anstrengende Woche, mit vielen Herausforderungen, die es zu überwinden galt, die wir aber durch gegenseitige Unterstützung erfolgreich absolviert haben!
Das Team behielt unseren Fokus, unsere harte Arbeit und unsere Leidenschaft bei. Deshalb spüre ich nichts als Aufregung!
Performance Engineering
Lassen Sie uns diese Woche über unser Performance-Engineering sprechen, das vom Klever-Tech-Team verwendet wird.
Dies sind die Prozesse hinter den Kulissen, die es uns ermöglichen, die Klever Exchange, eine High Performance Exchange, mit unserem übergeordneten Ziel aufzubauen, eine billigere Börse zu sein, die es ermöglicht, große Mengen an Trades mit kleinen Beträgen und geringen Gebühren abzuwickeln.
Unser Performance Engineering Process ist Teil unseres #devsecops-Teams mit Cross-Field-Spezialisten, die sich dem #KleverEx-Team angeschlossen haben, um ihr Know-how einzubringen.
Dieser Prozess gewährleistet eine hohe Leistungsfähigkeit und Belastbarkeit unserer Dienstleistungen, von der Entwicklungsphase bis zur Produktionsumgebung. Es handelt sich um einen zyklischen Vorgang, der in jeder neuen Version des #KleverEx-Produkts geladen wird.
Ziel ist es, mögliche Engpässe zu finden und zu beseitigen, die den Durchsatz der Börse und deren Service für unsere Benutzer einschränken könnten.
Wir sehen, wie sich der Dienst bei extremer und hoher Last verhält, und analysieren dann Verbesserungen der Softwarearchitektur, wobei wir immer nach einer skalierbareren und leistungsfähigeren Lösung mit den geringstmöglichen Kosten suchen.
Bevor wir zu den Ergebnissen gehen, lassen Sie uns ein wenig über die Softwarearchitektur sprechen, die zum Antrieb der #KleverEx verwendet wird. Er basiert auf der Event Driven Microservice Architecture, die auf Kubernetes (K8s) und Golang basiert.
Diese Lösung garantiert uns:
-
Loosely Coupled Structure – Event-Ersteller, z. B. wenn Sie eine Bestellung erstellen oder Ihre Bestellung ausgeführt wird und Event-Konsumenten, wie die Benutzeroberfläche, die Sie über den Status Ihrer Bestellungen informiert - lose gekoppelt mit der Event-Bus-Hilfe, die sie beim Paaren und Entkoppeln in verschiedene Plattformen unterstützt (Android oder iOS) als Reaktion auf verschiedene Ereignisse. Es ermöglicht uns auch, dass verschiedene Entwickler verschiedene Ereignisprozessoren schneller entwickeln. Und diese Komponenten nutzen und auch von vielen verschiedenen Plattformen wiederverwenden.
-
Real-time Analytics – Optimierte ereignisgesteuerte Architektur für Echtzeitanalysen. Es hat eine viel höhere Fähigkeit, Muster rechtzeitig zu finden, zu analysieren und darauf zu reagieren, bevor kritische Ereignisse eintreten, wodurch ihr Auftreten in der Produktion vermieden wird. Verwendung komplexer Ereignisverarbeitung zur Erzielung von Echtzeitanalysen.
-
Versatility – Ein System, das einer ereignisgesteuerten Architektur folgt, ermöglicht eine größere Reaktionsfähigkeit, da ereignisgesteuerte Systeme von Grund auf auf unvorhersehbare, nichtlineare und asynchrone Umgebungen normalisiert sind. Diese Systeme sind unter verschiedenen Umständen sehr anpassungsfähig.
In einfachen Worten bedeutet diese Softwarearchitektur:
-
Weniger Aufwand, um #KleverEx für die 3 geplanten Plattformen zu bauen: Android, iOS und Web
-
Eine Echtzeit-Benutzeroberfläche für die 3 geplanten Plattformen
-
Und eine überaus widerstandsfähigere Lösung
Kubernetes, ursprünglich von Google entwickelt, ermöglicht es uns, Umgebungen nach Belieben und in beliebiger Anzahl zu erstellen und neu zu erstellen. Mit Infrastruktur als Code können wir Umgebungen und Dienste skalieren, um unsere Anforderungen zu erfüllen, nur an der Grenze unseres Budgets mit Cloud-Anbietern.
Daher führen wir nach jedem Release den Lasttest in der Staging-Umgebung aus und überprüfen, ob die Leistung besser ist als die der letzten Version. Wenn es schlimmer ist, blockieren wir einfach diese Code-Veröffentlichung und bitten das Team, die darin gefundenen Engpässe zu beheben.
Als Beispiel haben wir in einer unserer Messungen der Dienste, die über einen Release Candidate-Code ausgelöst wurden, bei 114 virtuellen Benutzern (Bots oder Robotern, die ununterbrochen Anfragen ohne Bedenkzeit ausführen) gerade die Leistungsgrenze erreicht.
Daher analysiert das Team die Leistungsdaten, identifiziert Engpässe und Einschränkungen der Softwarearchitektur und optimiert basierend auf diesen Ergebnissen.
Also haben wir am nächsten Tag nach Änderungen im Code, der Verbesserung der Cache-Nutzung im Service-Level und vielen anderen Verbesserungen den Test mit der nächsten Version wiederholt und das erste Level der benötigten Leistung erreicht, das sind 250 virtuelle Benutzer (Bots oder Roboter, die ununterbrochen Anfragen ohne Bedenkzeit ausführen).
Wir haben den Test durchgeführt, bis er 550 virtuelle Benutzer erreicht hat und der Dienst die oben genannte gute Leistung erreicht. Anschließend haben wir diese Version freigegeben.
Mit diesen Methoden verbessern wir unsere Dienstleistungen ständig, um unserer Community ein leistungsstarkes und belastbar skalierbares Klever Exchange-Erlebnis zu bieten.
Sehen wir uns nun den Gesamtfortschritt in den anderen Teams der vergangenen Woche an:
Klever Exchange
Klever Wallet
Klever Hard Wallet
Klever Workspace
Ich hoffe, es hat Ihnen Spaß gemacht, diese Woche mehr über #devsecops und den allgemeinen technischen Fortschritt unseres Teams zu erfahren. Ich kann es kaum erwarten, Sie nächste Woche zu sehen!
Mit freundlichen Grüßen,
Bruno Campos
CTO at Klever