Wir haben kürzlich über die Arbeitsweise von IT-Architekten geschrieben. Jetzt werden wir Ihnen die Details zu einem unserer Fälle erläutern und das Schema des Systems zeigen. In diesem Projekt haben wir geholfen, eine "Box" -Banking-Anwendung durch eine Microservice-RBS zu ersetzen und gleichzeitig eine schnelle Veröffentlichung von Releases zu etablieren - durchschnittlich einmal pro Woche.
: , , -. NDA – , , , -.
«»
Bei mittleren und kleinen Unternehmen sind vorgefertigte IT-Lösungen gefragt, die angepasst und mit einem eigenen Logo versehen werden können. Nachteile - Die Funktionen von Anwendungen "out of the box" sind begrenzt, und Aktualisierungen müssen häufig über einen langen Zeitraum und ausschließlich über den Anbieter durchgeführt werden.
Einer unserer Kunden nutzte ein solches "Box" -System für Remote Banking Services (RBS). Die Online-Bank war eine monolithische Anwendung mit relativ kleinen Funktionen.
Um den Wettbewerbern nicht unterlegen zu sein, musste die Bank ständig Verbesserungen und neue Funktionen einführen. Um die Schaltflächen in der Anwendung einfach zu verschieben, mussten Sie sich an den Anbieter wenden. Updates wurden durchschnittlich einmal im Quartal veröffentlicht.
Daher war es aufgrund einer Reihe von Einschränkungen schwierig, das Produkt zu entwickeln:
- , «» .
- - «» -.
- , .
- , . .
- , .
- - , , , .
Infolgedessen traf die Bank die Entscheidung, die "Box" schrittweise aufzugeben und ein eigenes Remote-Banking-System mit einer Microservice-Architektur zu entwickeln, um die Entwicklung von Funktionen zu beschleunigen und den Benutzern Komfort und Sicherheit zu bieten.
Wo haben wir angefangen?
Die Schaffung einer Online-Bank begann mit dem Entwurf einer Architektur auf hoher Ebene, der Einstellung von Entwicklern und der Verbindung unseres engagierten Teams. Gleichzeitig musste die Architektur mit einem Sicherheitsspielraum verlegt werden, der auf zukünftige Erweiterungen zählen sollte.
Zu Beginn befasste sich unser Backend-Entwicklungsteam mit der Implementierung bestimmter Grundfunktionen: zum Beispiel Geldtransfers. Wir hatten jedoch ziemlich viel Erfahrung in der Arbeit mit Online-Banken. Eines unserer Projekte wurde zu diesem Zeitpunkt in das Branchenrating von Markswebb aufgenommen. Daher boten wir der Bank Unterstützung bei der architektonischen Gestaltung an - und erhielten grünes Licht.
Die Architektur
Zusammen mit dem Product Owner haben wir uns für Spring Cloud entschieden, das alle erforderlichen Funktionen zur Implementierung einer Microservice-Architektur bietet: Dies ist Service Discovery - Eureka, Api Gateway - Zuul, Config Server und vieles mehr. OpenShift wurde als Containersystem für Docker-Images ausgewählt, da die Infrastruktur der Bank für dieses Tool geschärft wurde.
Wir haben auch analysiert, welche Funktionen der alten "Box" die Benutzererfahrung erschweren können. Einer der Hauptnachteile war, dass das System synchron über den Datenbus arbeitete und jede Benutzeraktion einen Zugriff auf den Bus verursachte. Aufgrund schwerer Lasten fiel der Bus häufig aus und die gesamte Anwendung funktionierte nicht mehr. Darüber hinaus hat sich, wie bei vielen alten Bankprodukten, Vermächtnis angesammelt - "Vermächtnis" in Form des alten und schweren CORE-ABS, dessen Umschreibung schwierig und teuer wäre.
Wir haben eine Reihe von Verbesserungen vorgeschlagen:
- Versionierung
Früher unterstützte die "Box" nur eine Version, aber in der neuen Online-Bank haben wir eine neue Architektur vorgeschlagen, mit der wir mehrere verschiedene Versionen gleichzeitig unterstützen und bei Bedarf ersetzen können.
Das Versionsschema lautet wie folgt: Wenn sich die Nebenversion des Dienstes geändert hat, wird der Dienst automatisch neu erstellt und bereitgestellt, wobei die veraltete Version ersetzt wird. Wenn wir die Hauptversion einfügen, wird eine neue Kopie des Dienstes mit der neuen Version bereitgestellt. Daher wirkt sich die Entwicklung neuer Funktionen mit einer Änderung der Service-API nicht auf die mobile Anwendung aus, während die Testzeit verkürzt wird. Ein solches System ermöglichte es, auch veraltete Versionen der mobilen Anwendung zu unterstützen, wenn der Benutzer keine Möglichkeit zur Aktualisierung hat.
- Asynchronität
Wir haben eine Bibliothek implementiert, die in Diensten verwendet werden kann, die asynchrone Arbeit erfordern. Die Bibliothek implementiert die Ausführung von asynchronen Aufgaben, ist für die Verwendung auf einer beliebigen Anzahl von Kopien von Diensten geeignet und sie stören sich nicht gegenseitig. Die Synchronisierung zwischen verschiedenen Kopien erfolgt über die Kafka-Nachrichtenwarteschlange.
Diese Lösung trug zur Verbesserung der Stabilität der Anwendung bei. Die mobile Anwendung ist jetzt unabhängig vom Bus. Wir duplizieren die vom Benutzer in unseren Diensten benötigten Daten und aktualisieren sie im Hintergrund, wenn Zugriff auf den Bankbus besteht. Alle Benutzeraktionen werden zur Ausführung in die Warteschlange gestellt. Sobald sie bereit sind, werden PUSH-Benachrichtigungen über die Ergebnisse empfangen.
- Caching
Um die Anwendung zu beschleunigen und die Belastung der internen Bankressourcen zu verringern, wird das Daten-Caching mit Redis organisiert. KeyDB dient als Cache, der gute Ergebnisse zeigt und mit vielen Systemen kompatibel ist, die Redis verwenden. Daten werden nicht nach einer Benutzeranforderung zwischengespeichert, sondern wenn sich Benutzerdaten ändern, wodurch der Zugriff auf sie unabhängig von den internen Bankensystemen ermöglicht wird.
Was hat sich im System geändert?
Wie oben erwähnt, wurde in der alten Online-Bank das Backend in einer monolithischen Architektur implementiert, die Anwendung wurde auf einem separaten Computer bereitgestellt. Mit zunehmender Auslastung mussten neue Server bereitgestellt werden. Als der Server abstürzte, funktionierte die mobile Anwendung für einige Benutzer nicht.
Die neue Lösung verwendet eine Microservice-Architektur, mit der Sie so viele Kopien von Diensten bereitstellen können, wie für eine bestimmte Funktionalität erforderlich sind. Wir haben KeyDB-basiertes Daten-Caching hinzugefügt, um nicht nur das Abrufen von Informationen zu beschleunigen, sondern auch die Datenbank zu entlasten.
Schauen wir uns ein Beispiel für das Abrufen von Daten zu Benutzerkonten in der neuen Architektur an. Die Anforderung des Benutzers von der mobilen Anwendung geht über den Balancer an das Gateway, das versteht, an welchen der Dienste die Anforderung gesendet werden soll. Als nächstes gelangen wir zur Account Service API. Der Dienst prüft zunächst, ob sich tatsächlich Benutzerdaten im Cache befinden. Bei Erfolg werden die Daten zurückgegeben, andernfalls wird eine Anforderung an den Middle Account Service gesendet.
Das Aktualisieren von Daten im Dienst kann in verschiedenen Fällen erfolgen. Beispielsweise erstellt der Dienst auf direkte Anfrage des Benutzers eine Datenaktualisierungsaufgabe, die asynchron ausgeführt wird, und die vom ESB empfangenen Daten werden aktualisiert. Der Dienst empfängt auch Nachrichten aus der Nachrichtenwarteschlange und antwortet darauf. Beispielsweise empfängt ein Dienst eine Nachricht über einen Benutzer, der sich bei einer Anwendung anmeldet, und aktualisiert sofort Kontodaten, empfängt Daten zu Kontotransaktionen von anderen Diensten und aktualisiert seine Daten. Somit sieht der Benutzer immer aktuelle Daten auf seinen Konten.
Zu den wichtigsten Änderungen gehören:
- Flexibilität bei der Skalierung
Um die Fehlertoleranz des Systems zu erhöhen, werden Dienste auf verschiedene Server verteilt. Auf diese Weise können Sie das System im Falle eines Sturzes eines Systems funktionsfähig halten. Um rechtzeitig auf nicht standardisierte Situationen reagieren zu können, haben wir ein Überwachungssystem eingeführt, mit dessen Hilfe die Dienste bei Bedarf rechtzeitig skaliert werden können. Wir haben DevOps verbunden, um CI / CD auf Client-Servern von Grund auf neu zu konfigurieren, Bereitstellungs- und Supportprozesse für die zukünftige Anwendung auf mehreren Servern erstellt.
- Beschleunigung von Releases aufgrund von Versionierung
Zuvor haben einige Benutzer beim Aktualisieren der mobilen Version die neue Version bereits angewendet, andere nicht, aber die Anzahl der letzteren war minimal. Bei der Entwicklung eines neuen RBS haben wir die Versionierung und die Möglichkeit implementiert, Releases zu veröffentlichen, ohne das Risiko einzugehen, dass die Anwendung für einen großen Teil der Kunden nicht mehr funktioniert. Wenn Sie nun einzelne Funktionen in neuen Versionen implementieren, werden alte Versionen nicht beschädigt, sodass keine Regression erforderlich ist. Dies hat dazu beigetragen, die Veröffentlichungshäufigkeit um mindestens das 15-fache zu beschleunigen - jetzt werden Veröffentlichungen durchschnittlich einmal pro Woche veröffentlicht. Backend- und Mobile-Teams können gleichzeitig und unabhängig an neuen Funktionen arbeiten.
Zusammenfassen
In diesem Beispiel haben wir über das Entwerfen einer Microservice-Architektur für eine Bank gesprochen, die die monolithische "Boxed" -Lösung ersetzt. Ein verteiltes Team arbeitete an diesem Projekt, an dem sowohl interne Entwickler als auch Outsourcer teilnahmen.
Bei der Entwicklung der Online-Bank haben wir versucht, in der neuen Anwendung den gleichen Funktionsumfang wie in der Box-Anwendung zu implementieren und schrittweise weiterzuentwickeln.
Um Kundenabwanderung zu vermeiden, musste ein störungsfreier Betrieb der Anwendung ohne Ausfälle und Ausfallzeiten sowie eine regelmäßige Veröffentlichung von Releases und Updates eingerichtet werden. Dies wurde dank Verbesserungen in der Architektur erreicht. Insbesondere nachdem wir die Belastung der Datenbank reduziert hatten, erreichten wir eine konstante Verfügbarkeit der Anwendung. Aufgrund der Versionierung reduzierten wir die Testzeit und stellten die Möglichkeit einer unabhängigen Arbeit an der Funktionalität und der Veröffentlichung von Releases einmal pro Woche sicher.
Die Architektur der Anwendung basiert auf dem weiteren Wachstum der Produkt- und Entwicklungstools, die vom internen Bankenteam verwendet werden, sodass der Product Owner unabhängig Verbesserungen an der RBS vornehmen kann. Die Bedingungen für die aktive Entwicklung der Alpha-Version waren ungefähr ein Jahr, nach weiteren 3 Monaten wurde die Beta-Version für alle Benutzer veröffentlicht.
Wir hoffen, dass das beschriebene Arbeitsschema bei der Erstellung anderer Fintech-Produkte hilfreich sein kann.
Vielen Dank für Ihre Aufmerksamkeit!