Nous avons récemment écrit sur le fonctionnement des architectes informatiques , et maintenant nous allons vous donner les détails de l'un de nos cas et montrer le schéma du système. Dans ce projet, nous avons aidé à remplacer une application bancaire «box» par un microservice RBS, tout en établissant une version rapide des versions - en moyenne, une fois par semaine.
: , , -. NDA – , , , -.
«»
Parmi les moyennes et petites entreprises, des solutions informatiques prêtes à l'emploi sont demandées, qui peuvent être personnalisées et publiées avec leur propre logo. Inconvénients - les fonctions des applications «prêtes à l'emploi» sont limitées et les mises à jour doivent souvent être effectuées pendant longtemps et exclusivement par le biais du vendeur.
Un de nos clients a utilisé un tel système de «boîte» de services bancaires à distance (RBS). La banque en ligne était une application monolithique avec un ensemble de fonctions assez restreint.
Afin de ne pas être inférieure à ses concurrents, la banque devait constamment introduire des améliorations et de nouvelles fonctionnalités. Cependant, même pour déplacer simplement les boutons dans l'application, vous deviez contacter le fournisseur. Des mises à jour ont été publiées en moyenne une fois par trimestre.
Ainsi, il a été difficile de développer le produit en raison d'un certain nombre de restrictions:
- , «» .
- - «» -.
- , .
- , . .
- , .
- - , , , .
En conséquence, la banque a pris la décision d'abandonner progressivement la «box» et de développer son propre système de banque à distance, avec une architecture de microservices, afin d'accélérer le développement des fonctions et d'apporter confort et sécurité aux utilisateurs.
Où avons-nous commencé
La création d'une banque en ligne a commencé avec la conception de l'architecture de haut niveau, l'embauche de développeurs et la connexion de notre équipe dédiée. Dans le même temps, l'architecture devait être posée avec une marge de sécurité, en comptant sur une expansion future.
Au départ, notre équipe de développement Backend était engagée dans la mise en œuvre de certaines fonctions de base: par exemple, les transferts d'argent. Cependant, nous avions une grande expérience de travail avec les banques en ligne, l'un de nos projets étant à ce moment-là entré dans la notation de l'industrie de Markswebb, nous avons donc offert l'assistance de la banque dans la conception architecturale - et avons reçu le feu vert.
Architecture
En collaboration avec le propriétaire du produit, nous avons décidé d'utiliser Spring Cloud, qui fournit toutes les fonctions nécessaires pour implémenter une architecture de microservices: il s'agit de Service Discovery - Eureka, Api Gateway - Zuul, Config server et bien plus encore. OpenShift a été choisi comme système de conteneur pour les images Docker, car l'infrastructure de la banque a été affinée pour cet outil.
Nous avons également analysé quelles fonctionnalités de l'ancienne «boîte» peuvent compliquer l'expérience utilisateur. L'un des principaux inconvénients était que le système fonctionnait de manière synchrone via le bus de données, et chaque action de l'utilisateur provoquait un accès au bus. En raison de charges lourdes, le bus tombait souvent en panne et toute l'application cessait de fonctionner. En outre, comme dans de nombreux produits bancaires anciens, l'héritage s'est accumulé - un «héritage» sous la forme de l'ancien et lourd CORE ABS, qui serait difficile et coûteux à réécrire.
Nous avons proposé un certain nombre d'améliorations:
- Gestion des versions
Auparavant, la "box" ne supportait qu'une seule version, mais dans la nouvelle banque en ligne nous avons proposé une nouvelle architecture qui nous permettra de supporter plusieurs versions différentes en même temps et de les remplacer si nécessaire.
Le schéma de gestion des versions est le suivant: si la version mineure du service a changé, le service est automatiquement reconstruit et déployé, remplaçant la version obsolète. Si nous mettons la version majeure, une nouvelle copie du service avec la nouvelle version est déployée. Ainsi, le développement de nouvelles fonctions avec une modification de l'API de service n'affecte pas l'application mobile, tandis que le temps de test est réduit. Un tel système a permis de prendre en charge des versions même obsolètes de l'application mobile si l'utilisateur n'a pas la possibilité de se mettre à jour.
- Asynchronie
Nous avons implémenté une bibliothèque qui peut être utilisée dans les services qui nécessitent un travail asynchrone. La bibliothèque implémente l'exécution de tâches asynchrones, peut être utilisée sur un nombre illimité de copies de services et elles n'interfèrent pas les unes avec les autres. La synchronisation entre différentes copies se fait à l'aide de la file d'attente de messages Kafka.
Cette solution a permis d'améliorer la stabilité de l'application. L'application mobile est désormais indépendante du bus, nous dupliquons les données nécessaires à l'utilisateur dans nos services et les mettons à jour en arrière-plan lorsqu'il y a accès au bus bancaire. Toutes les actions de l'utilisateur sont mises en file d'attente pour exécution, dès qu'elles sont prêtes, des notifications PUSH sur les résultats sont reçues.
- Mise en cache
Pour accélérer l'application et réduire la charge sur les ressources bancaires internes, la mise en cache des données à l'aide de Redis est organisée. KeyDB sert de cache, ce qui donne de bons résultats et est compatible avec de nombreux systèmes utilisant Redis. Les données sont mises en cache non après une demande de l'utilisateur, mais lorsque les données de l'utilisateur changent, ce qui permet d'y accéder indépendamment des systèmes bancaires internes.
Ce qui a changé dans le système
Comme indiqué ci-dessus, dans l'ancienne banque en ligne, le backend était implémenté dans une architecture monolithique, l'application était déployée sur une machine distincte. À mesure que la charge augmentait, de nouveaux serveurs ont dû être déployés. Lorsque le serveur s'est écrasé, l'application mobile ne fonctionnait pas pour certains utilisateurs.
La nouvelle solution utilise une architecture de microservices, qui vous permet de déployer autant de copies de services que nécessaire pour une fonctionnalité particulière. Nous avons ajouté la mise en cache des données basée sur KeyDB pour non seulement augmenter la vitesse de récupération des informations, mais également réduire la charge sur la base de données.
Examinons un exemple d'obtention de données sur les comptes d'utilisateurs dans la nouvelle architecture. La demande de l'utilisateur à partir de l'application mobile passe par l'équilibreur vers la passerelle, qui comprend à quel service envoyer la demande. Ensuite, nous arrivons à l'API du service de compte. Le service vérifie d'abord s'il existe des données utilisateur réelles dans le cache. En cas de succès, il renvoie les données, sinon il envoie une demande au service de compte intermédiaire.
La mise à jour des données dans le service peut se produire dans divers cas. Par exemple, à la demande directe de l'utilisateur, le service crée une tâche de mise à jour des données qui s'exécute de manière asynchrone et les données reçues de l'ESB sont mises à jour. Le service reçoit également des messages de la file d'attente de messages et y répond. Par exemple, un service reçoit un message concernant un utilisateur se connectant à une application et met immédiatement à jour les données de compte, reçoit des données sur les transactions de compte d'autres services et met à jour ses données. Ainsi, l'utilisateur voit toujours des données à jour sur ses comptes.
Les changements les plus importants sont les suivants:
- Flexibilité évolutive
Pour augmenter la tolérance aux pannes du système, les services sont répartis sur différents serveurs. Cela vous permet de maintenir le système en état de fonctionnement en cas de chute de l'un d'entre eux. Pour une réponse rapide aux situations atypiques, nous avons mis en place un système de suivi, qui a aidé à étendre les services si nécessaire. Nous avons connecté DevOps pour configurer CI / CD à partir de zéro sur des serveurs clients, construit des processus de déploiement et de support pour la future application sur plusieurs serveurs.
- Accélération des versions grâce au versionnage
Auparavant, lors de la mise à jour de la version mobile, certains utilisateurs appliquaient déjà la nouvelle version, d'autres non, mais le nombre de cette dernière était minime. Lors du développement d'un nouveau RBS, nous avons implémenté le contrôle de version et la possibilité de publier des versions sans risque que l'application cesse de fonctionner pour une grande partie des clients. Désormais, lors de l'implémentation de fonctionnalités individuelles dans les nouvelles versions, nous ne cassons pas les anciennes versions, ce qui signifie qu'il n'est pas nécessaire de régresser. Cela a contribué à accélérer la fréquence des versions d'au moins 15 fois - maintenant, les versions sont publiées en moyenne une fois par semaine. Les équipes Backend et Mobile peuvent travailler simultanément et indépendamment sur de nouvelles fonctionnalités.
Résumer
Dans cet exemple, nous avons parlé de la conception d'une architecture de microservices pour une banque, qui a remplacé la solution monolithique «en boîte». Une équipe distribuée a travaillé sur ce projet, qui comprenait à la fois des développeurs internes et des sous-traitants.
Lors du développement d'une banque en ligne, nous avons essayé d'implémenter le même périmètre de fonctions dans la nouvelle application que dans une application en boîte, et de la développer progressivement.
Afin d'éviter le churn des clients, il était nécessaire d'établir un fonctionnement sans problème de l'application, sans pannes et sans temps d'arrêt, et la publication régulière des versions et des mises à jour. Cela a été fait grâce aux améliorations de l'architecture. En particulier, après avoir réduit la charge sur la base de données, nous avons atteint une disponibilité constante de l'application et, grâce au versionnage, nous avons réduit le temps de test, assuré la possibilité d'un travail indépendant sur les fonctionnalités et la publication des versions une fois par semaine.
L'architecture de l'application est basée sur la poursuite de la croissance du produit et des outils de développement utilisés par l'équipe interne de la banque afin que le propriétaire du produit puisse indépendamment apporter des améliorations au RBS. Les conditions de développement actif de la version alpha étaient d'environ un an, après 3 mois supplémentaires, la version bêta a été publiée pour tous les utilisateurs.
Nous espérons que le schéma de travail décrit pourra être utile lors de la création d'autres produits fintech.
Merci de votre attention!