Historique du développement de l'architecture financière de l'Internet de zéro à des dizaines de milliards

Rappelant que cela fait presque trois ans depuis la création de la première ligne de code depuis la création de l'entreprise, l'architecture technique et le système technique de la plateforme ont également subi quatre mises à niveau et transformations majeures (le système d'architecture de quatrième génération est actuellement en cours), comme À l'approche de la fin de l'année, je souhaite également prendre le temps de passer en revue les changements technologiques derrière une petite entreprise, depuis zéro transaction au début jusqu'à un volume de transactions de plus de 10 milliards.

Introduction générale

Dans le secteur financier sur Internet, qui compte plus de 10 milliards de yuans, il ne s'agit pas en réalité d'une grande plate-forme, c'est-à-dire d'un camp de second rang. En fait, chaque mise à niveau de l'architecture s'accompagne d'avancées commerciales majeures. l'architecture système de la génération précédente. Certains excellents cas de développement ont été accumulés au cours du processus de développement commercial, et les mises à niveau de l'architecture seront vigoureusement encouragées dans le développement des systèmes de nouvelle génération. D'une part, cela peut faciliter la transition, d'autre part, les ressources de l'entreprise peuvent fournir un soutien solide, et en même temps, les partenaires techniques peuvent utiliser une technologie de pointe et avoir un plus grand sentiment d'accomplissement dans le développement. de cette façon, nous pouvons mettre à niveau l’architecture du système une fois tous les 9 mois environ vers notre structure actuelle.

De nombreux internautes demandent souvent quel est le TPS de votre plateforme, quelle est la simultanéité maximale et quelles sont les performances. Pour être honnête, nous sommes une petite entreprise, et le plus exagéré est que des dizaines de milliers de personnes se disputent des offres ? en même temps, mais en tant qu'Internet de taille moyenne, la plateforme financière a vraiment beaucoup de choses à faire, et bien plus que ces paramètres qui peuvent être clairement énoncés, nous ne sommes pas une plateforme haut de gamme ; , et la technologie que nous utilisons est également un produit open source relativement courant à l'heure actuelle, mais dans le processus de développement continu de l'entreprise, j'ai également rencontré de nombreux problèmes et j'ai fait de mon mieux pour utiliser des solutions open source plus courantes qui nous permettent de construire l'ensemble du système. J'aimerais partager les changements dans les mises à niveau technologiques derrière le développement de la plate-forme. J'espère également avoir plus d'échanges avec vous. Faites quelques suggestions.

Nous avons apporté quatre changements architecturaux majeurs, et chaque génération d'architecture est résumée en une phrase :

• Caractéristiques de l'architecture de première génération : l'activité est relativement concentrée, les fonctions répondent aux besoins d'investissement et de gestion financière et peuvent être lancées rapidement

• Caractéristiques de l'architecture de deuxième génération : transformation des systèmes distribués, plate-forme commençant à prendre forme, divers systèmes commerciaux verticaux étant construits et lancés, côté produit enrichissant considérablement l'investissement des utilisateurs, et recherche et utilisation de plates-formes Big Data.

• Caractéristiques de l'architecture SOA de troisième génération, utilisant zookeeper comme centre d'enregistrement, dubbo comme centre de surveillance et de répartition, pour réaliser une authentification unique, utilisant shiro pour le contrôle des autorisations ;

• Caractéristiques de l'architecture de quatrième génération : activer pleinement le modèle de développement de microservices, avec la technologie springboot et springcloud comme support technique pour l'architecture de quatrième génération

Présentation détaillée ci-dessous

Architecture système de première génération

2014 doit être considérée comme la première année de la finance Internet. En fait, de nombreuses sociétés Internet utilisaient différents modèles pour survivre, mais elles ont été timides en 2014. La première était Pingdaizhijia et Pingdao Tianyan. . Ce type de trafic sur les sites Web tiers a soudainement augmenté, puis les médias ont continué à suivre. Plus tard, il y a eu de plus en plus de rapports sur diverses sociétés financières sur Internet recevant XXX dollars américains d'investissement, et les politiques sont progressivement devenues claires, de sorte que de nombreuses sociétés financières sur Internet ont reçu des investissements de XXX dollars américains. de grandes entreprises (groupes) ont également profité de cet engouement pour donner suite, dont nous.

L'objectif principal du système de première génération était de gagner du temps. L'entreprise espérait que le système soit en ligne dans les plus brefs délais. À ce moment-là, la vague mobile avait déjà commencé, il a donc été décidé de donner la priorité au lancement de. la version mobile et le site internet ne peuvent être envisagés pour le moment. À cette époque, l'entreprise disposait de réserves techniques dans deux langages de développement, PHP et Java. Parce que PHP présentait de grands avantages en matière de développement rapide, elle a décidé d'adopter le modèle PHP front-end et Java back-end. Le système est divisé en trois couches : Couche utilisateur : terminaux mobiles Android et IOS ; Couche interface : PHP fournit des interfaces utilisateur et de transaction ; Backend : Le backend comporte deux parties, l'arrière-plan et le système de synchronisation. Le backend utilise le développement PHP et la couche d'interface pour partager un système, et l'autre est un système de chronométrage, responsable des tâches de chronométrage telles que le calcul des intérêts, la distribution des dividendes, l'expiration, etc., et est développé en Java.

Pour les services de base et le middleware, MySQL fournit la prise en charge maître-esclave la plus élémentaire. Le système de première génération utilise uniquement la base de données principale de MySQL, et la base de données esclave n'est utilisée que pour la sauvegarde synchrone et est utilisée pour gérer le problème de concurrence de l'utilisateur. enchères, et seule cette partie est utilisée ;ActiveMQ est utilisé pour utiliser la correspondance de transfert sur le marché secondaire et d'autres notifications de messages asynchrones. Déploiement du projet : PHP est déployé à l'aide d'Apache, le service de synchronisation utilise Tomcat6 comme serveur d'applications et lvs est utilisé comme charge Apache frontale. Fondamentalement, ces technologies sont la première génération. Voici le schéma d'architecture de la première génération. système.

Après le lancement du système de première génération, la construction de sites Web et de systèmes H5 (navigateur mobile ou WeChat) est devenue particulièrement importante. En tant que société financière sur Internet, elle ne pouvait supporter de ne pas avoir de site Web officiel, elle a donc commencé à développer des sites Web et H5. systèmes non-stop. Au cours de cette période, le backend que PHP avait précédemment réalisé a été supprimé et replanifié en utilisant Java. Jusqu'à présent, PHP est responsable des trois systèmes de site Web, d'interface APP et d'une transaction de base partagée. par les trois systèmes, Java est responsable du backend Pour les services de gestion et de synchronisation, nous appelons généralement cette architecture l'architecture de génération 1.1.

Schéma d'architecture du système génération 1.1, la partie verte est la partie modifiée

Les inconvénients du système de première génération sont que l'activité est trop concentrée, qu'elle est lancée à la hâte et qu'il y a de nombreux problèmes dans la période ultérieure.

Architecture système de deuxième génération

Le contexte du système de deuxième génération est qu'avec le développement rapide du volume d'affaires de l'entreprise, de nombreuses dettes techniques dues au début ont explosé et de nombreux problèmes sont apparus en ligne, le plus grave étant le paiement répété de dividendes aux particuliers. utilisateurs, et ils ont été réprimandés de diverses manières, le souvenir est encore frais maintenant. D'un autre côté, les différents départements commerciaux ont des demandes constantes et les produits de l'entreprise sont en demande constante, donc à ce stade, ils sont occupés à résoudre divers problèmes de production, tout en développant également des systèmes commerciaux verticaux. J'étais presque devenu fou pendant cette période. Le système de première génération a été développé de manière fermée. Je ne me suis toujours pas remis de mon stress lorsque je suis revenu pour le remettre sur le marché. heureux.

Le premier sous-système vertical mis en ligne était le système de contrat. À cette époque, il n'y avait pas de contrat après que les utilisateurs aient soumis des offres. De nombreux utilisateurs étaient très inquiets et accordaient la priorité. Plus tard, le système de contrat à lui seul a été modifié en trois versions. La première version générait uniquement des PDF, la deuxième phase a lancé des signatures électroniques et la troisième phase a ajouté des filigranes pour personnaliser et générer dynamiquement des PDF, puis a développé un système de points : invitation de l'utilisateur, investissement et ; d'autres points de production peuvent être utilisés pour échanger des bons d'achat, etc. ; extraire le système de messagerie : messages du site, messages texte, e-mails, etc. ; lancer le système de surveillance en ligne, la surveillance des activités et la surveillance des services, ainsi que l'alerte précoce en cas de défaillance commerciale ; le département commercial continuera d'augmenter les demandes et de se mettre en ligne. Système financier : le personnel financier calcule les montants ; système de contrôle des risques : surveille les utilisateurs anormaux et les transactions anormales et développe un système d'accès externe car il s'interface avec de nombreux tiers ; systèmes.

Le système de première génération a été construit à la hâte et l'interface du produit était épouvantable. Ensuite, nous avons commencé à planifier le site Web 2.0, APP2.0 et H52.0. En réponse aux besoins du système frontal, nous avons développé un CMS. système sur le back-end pour publier les annonces de projets et d'entreprises, les actualités, etc. ; Le côté produit de deuxième génération prévoit généralement de nombreux besoins d'analyse de données volumineuses. Il affichera sur le site officiel où les préférences d'investissement et les montants d'investissement seront complets. analyse des données. Le front-end utilise une carte pour l'afficher, et il y aura également des remboursements pour les particuliers, une analyse des données collectées, etc., car ils ont besoin d'exécuter la totalité des données, elles sont conçues pour être traitées hors ligne. pendant la planification. Les données sont synchronisées de la bibliothèque esclave mysql vers le cluster mongodb, et la technologie mapreduce de mongdo est utilisée pour traiter de grandes quantités de données. Notre couche de base de données devient l'architecture suivante.

Mysql est synchronisé avec mongodb en temps réel. Nous utilisons l'outil tungsten-relicator, qui démarrera un agent de surveillance côté serveur mysql pour surveiller le journal binlog de mysql en temps réel, un service est également démarré côté serveur mongodb. Du côté client, l'agent surveille les modifications de données et les envoie au serveur. Le serveur les analyse et les insère dans le cluster mongodb pour obtenir une synchronisation en temps réel, comme indiqué dans le fichier. photo ci-dessus. J'ai initialement écrit un article pour le présenter : Article sur la synchronisation des données sur les pratiques du Big Data tungsten-relicator (mysql->mongo) , en fait, cet outil n'est pas particulièrement stable à l'usage, mais là Il n'y avait pas beaucoup d'options au début. Heureusement, il est devenu stable après que je m'y sois progressivement familiarisé.

Nous avons utilisé avec audace Golang pour développer le système de nettoyage des données. La version de Golang que nous utilisions à l'époque était la 1.3, mais maintenant elle est la 1.8. Je n'y avais jamais été exposé auparavant et cela a également formé l'équipe. est très simple et efficace, même si j'ai marché sur le N. Il y avait beaucoup d'embûches, mais à la fin nous l'avons mis en production à temps ; plus tard, nous avons utilisé Golang pour développer un backend, basé sur le framework beego ; Le système d'analyse des mégadonnées a ensuite été mis à niveau vers une autre génération.Dans chaque système d'entreprise frontal, la couche utilisateur de l'interface utilisateur a déployé de nombreux efforts pour collecter les données des utilisateurs. Elle les a reçues via la transmission activeMQ et les a finalement stockées dans mongodb. données, les résultats nettoyés ont été stockés dans la base de données de résultats pour être utilisés par le système commercial frontal ; plus tard, une nouvelle version du système d'analyse des données a été construite à l'aide de beego echart.

Schéma d'architecture du système Big Data

Parce que la pression sur la base de données back-end continue d'augmenter, le système de gestion back-end et le système d'entreprise ont été séparés du maître et de l'esclave ; le système de gestion back-end a ajouté du cache et démarré Redis pour la mise en cache d'un serveur d'images indépendant ; a été construit à l'aide de nginx ; développement de systèmes de deuxième génération. Au cours du processus, il s'agissait également de l'étape de croissance la plus rapide de l'entreprise, avec de nombreuses activités lancées en ligne.

Schéma d'architecture système de deuxième génération :

Résumons dans un instant :
L'architecture de deuxième génération a lancé divers systèmes commerciaux, séparé le maître et l'esclave, et construit une plate-forme Big Data pour fournir une base technique pour davantage de traitement de données à l'avenir
Inconvénients : une fois chaque système d'entreprise divisé, les appels entre chaque projet sont compliqués ; il existe de nombreux systèmes back-end et il existe des systèmes de comptes distincts entre chaque système. Les opérations doivent basculer d'un côté à l'autre pour compléter la surveillance des opérations de la plate-forme.

architecture système de troisième génération

Une fois le développement du système de deuxième génération terminé, nous nous sommes retrouvés avec trois problèmes douloureux. Le premier était qu'à mesure que les systèmes d'entreprise continuaient à se développer, les relations d'appel entre les systèmes augmentaient de façon exponentielle. Nous avons développé De nombreux composants de base ont été ajoutés, aggravant ce problème ; le deuxième problème est complémentaire au premier problème, et il y a trop de relations d'appel entre les systèmes. Si vous déplacez l'un des sous-systèmes, vous devrez peut-être modifier le fichier de configuration de. le système associé et redémarrer le service. , souvent en raison de la mise à jour d'un système, d'autres systèmes doivent également être mis à jour passivement, ce qui complique la mise en production et le changement lorsque des problèmes surviennent ; systèmes finaux, mais les comptes ne sont pas unifiés. Chaque sous-système a son propre centre de comptes et le personnel opérationnel doit se connecter d'avant en arrière pour effectuer son travail quotidien. À mesure que le volume d'affaires augmente, ce problème devient de plus en plus important.

Nous avons donc commencé la recherche et la sélection de systèmes, etc. Le premier problème à résoudre était d'introduire la gouvernance des services SOA et de résoudre le découplage entre les systèmes via l'enregistrement et la découverte des services. Nous avons beaucoup étudié à cette époque et avons finalement sélectionné Dubbo pour aucune autre raison que A. un grand nombre de personnes marchaient sur l’eau en utilisant l’eau de base. Pour résoudre le deuxième problème, nous avons introduit le centre de configuration. À cette époque, nous avons étudié Qihoo360/QConf de Spring, Spring-cloud-config, Taobao Diamond et Baidu Disconf. Enfin, après avoir longtemps lutté, nous avons choisi Disconf. ce qui était parfait pour Spring Cloud, nous l'avons ignoré, mais c'est à partir de là que nous avons remarqué que spring-cloud et Spring-boot ont jeté les bases de la sélection d'architecture de quatrième génération. En fait, en fin de compte, disconf n'a été utilisé que dans. un petit nombre de projets et n'a pas été entièrement promu ; le troisième problème est résolu par le centre de compte, qui utilise cas pour implémenter l'authentification unique, shiro pour le contrôle des autorisations et dubbo pour fournir des interfaces serveur telles que la liste des autorisations après la connexion.

Schéma d'architecture après transformation

Sur cette base, nous avons extrait de nombreux composants de base. Le composant coomn gère les classes de base communes, notamment les classes de caractères, les classes de date, les classes de chiffrement..., nous avons construit un cluster fastDFS pour traiter le système de fichiers et construit un cluster redis Testing ; a développé indépendamment un système de planification planifiée, intégrant toutes les tâches planifiées dans le système de planification. Quel que soit le système nécessitant des tâches planifiées, il peut automatiquement ajouter des stratégies de planification à la page ; le PHP frontal a effectué des transformations du système, une séparation maître-esclave, une optimisation statique, etc.

Plus tard, l'entreprise a commencé la construction d'une plate-forme de financement participatif. Cette fois, le système a été entièrement développé en langage Java et le côté application a adopté un modèle de développement hybride. Toutes les pages de premier niveau de l'APP ont été développées de manière native et toutes les pages de deuxième niveau. les pages ont été développées en utilisant H5 vue. Dans ce modèle, tous les backends utilisent dubbo pour le service. L'architecture finale est la suivante :

Dans la figure, seule une partie du système est répertoriée et d'autres services sont utilisés à la place.

Le système de troisième génération a lancé la gouvernance des services SOA et introduit un centre de comptes unifié et des composants de base ; l'inconvénient est que l'environnement de développement est plus complexe ;

Architecture système de quatrième génération

Les gens sont toujours insatisfaits et la technologie espère toujours utiliser la meilleure architecture système.Au cours du développement de l'architecture système de troisième génération, j'ai découvert Spring Cloud et Spring Boot.Après un apprentissage continu, j'ai pris de plus en plus conscience de la commodité de. spring boot.J'aime beaucoup les avantages du développement rapide.Le système Spring Cloud répond également pleinement à tous les aspects qui doivent être pris en compte dans un grand système.Le concept de microservices est constamment proposé. D'autre part, le pays a commencé à exiger strictement que les entreprises P2P aient des dépôts auprès des banques. Après avoir analysé les interfaces bancaires pertinentes, nous avons constaté que si nous suivons strictement les règles, notre système nécessite en même temps une transformation majeure. Pour répondre aux exigences réglementaires, la société a également développé des produits liés à Baitiao, qui constituent également un grand projet. Tirant parti des deux contextes ci-dessus, nous avons décidé d'adopter pleinement les microservices tout en travaillant sur les projets de dépôt bancaire et de Baitiao.

Quant à la raison pour laquelle nous abandonnons Dubbo et adoptons pleinement Spring Cloud, il y a trois raisons : 1. Dubbo n'a pas été mis à jour depuis de nombreuses années et Spring Cloud est constamment mis à jour et mis à niveau. 2. Dubbo s'occupe principalement de la gestion et de la surveillance des services, et Spring. Le cloud prend presque en compte tous les microservices. Il nécessite tous les aspects, tels qu'un centre de configuration unifié et un centre de routage ; 3. Spring Cloud est non intrusif et parfaitement intégré aux autres projets Spring, ce qui rend le développement plus efficace.

Maintenant que nous avons choisi d'utiliser Spring Boot Spring Cloud pour la transformation, le choix de la technologie des microservices a été décidé. Alors, comment démarrer la transformation? Après tout, l'activité d'origine ne peut pas être affectée lors de la transformation du système de nouvelle génération. Le problème est que même si les systèmes initiaux ont été développés selon le modèle de développement distribué, certains systèmes partagent toujours une base de données en raison de l'ancien système. Les microservices nécessitent que chaque sous-système indépendant ait son propre fonctionnement de bibliothèque indépendant. Autres systèmes Si vous devez modifier. ou interroger les données du sous-système, vous devez les obtenir en appelant l'interface interservices. Par conséquent, nous prévoyons de démarrer le projet springcloud à partir de projets nouvellement développés et de projets qui doivent être transformés. D'autres systèmes communiqueront temporairement via le mode routeur. Le schéma final de l'architecture du système est le suivant :

Il n'y a pas de fin sur le chemin de l'architecture. Le changement est éternel. La mise à niveau de l'architecture consiste à mieux soutenir l'entreprise.