Entwicklungsgeschichte der Internet-Finanzarchitektur von null bis zu mehreren zehn Milliarden

Unter Berücksichtigung der Tatsache, dass seit der Gründung des Unternehmens fast drei Jahre vergangen sind, wurden die technische Architektur und das technische System der Plattform auch vier großen Upgrades und Transformationen unterzogen (das Architektursystem der vierten Generation befindet sich derzeit in der Entwicklung), as Da sich das Jahresende nähert, möchte ich mir auch die Zeit nehmen, die technologischen Veränderungen hinter einem kleinen Unternehmen zu betrachten, von null Transaktionen am Anfang bis zu einem Transaktionsvolumen von über 10 Milliarden.

Allgemeine Einführung

In der Internet-Finanzbranche, die mehr als 10 Milliarden Yuan hat, handelt es sich eigentlich nicht um eine große Plattform, das heißt, es handelt sich um ein Lager der zweiten Stufe. Tatsächlich geht jedes Architektur-Upgrade mit großen geschäftlichen Fortschritten einher Während des Geschäftsentwicklungsprozesses wurden einige hervorragende Entwicklungsfälle gesammelt, und Architektur-Upgrades werden bei der Entwicklung von Systemen der nächsten Generation energisch vorangetrieben. Einerseits kann es den Übergang erleichtern, andererseits können die Unternehmensressourcen eine starke Unterstützung bieten und gleichzeitig können technische Partner modernste Technologie nutzen und ein größeres Erfolgserlebnis bei der Entwicklung haben Auf diese Weise können wir die Systemarchitektur alle etwa 9 Monate auf unsere aktuelle Struktur aktualisieren.

Viele Internetnutzer fragen oft: Wie hoch ist die TPS Ihrer Plattform, wie hoch ist die maximale Parallelität und wie ist die Leistung? Um ehrlich zu sein, sind wir ein kleines Unternehmen, und das Übertriebenste ist, dass Zehntausende von Menschen um Gebote konkurrieren Gleichzeitig, aber als mittelständische Internetplattform gibt es wirklich viele Dinge, die die Finanzplattform tun muss, und es sind weit mehr als nur diese Parameter, die klar angegeben werden können. Wir sind keine High-End-Plattform , und die Technologie, die wir verwenden, ist derzeit auch ein relativ gängiges Open-Source-Produkt, aber im Prozess der kontinuierlichen Weiterentwicklung des Unternehmens bin ich auch auf viele Probleme gestoßen und habe mein Bestes gegeben, um gängigere Open-Source-Lösungen zu verwenden sind für uns geeignet, das gesamte System aufzubauen. Ich möchte hier auch die Änderungen bei den Technologie-Upgrades teilen, die sich hinter der Entwicklung der Plattform verbergen.

Wir haben vier große architektonische Veränderungen durchgeführt und jede Architekturgeneration wird in einem Satz zusammengefasst:

• Merkmale der Architektur der ersten Generation: Das Geschäft ist relativ konzentriert, die Funktionen erfüllen die Investitions- und Finanzmanagementanforderungen und können schnell eingeführt werden

• Merkmale der Architektur der zweiten Generation: Transformation verteilter Systeme, beginnende Plattformisierung, Aufbau und Einführung verschiedener vertikaler Geschäftssysteme, erhebliche Bereicherung der Benutzerinvestitionen auf der Produktseite sowie Forschung und Nutzung von Big-Data-Plattformen

• Merkmale der Architektur der dritten Generation; SOA-Governance, Verwendung von zookeeper als Registrierungszentrum, Dubbo als Überwachungs- und Dispatching-Zentrum, Verwendung von Shiro zur Berechtigungskontrolle;

• Merkmale der Architektur der vierten Generation: Vollständige Aktivierung des Microservice-Entwicklungsmodells mit Springboot + Springcloud-Technologie als technische Unterstützung für die Architektur der vierten Generation

Detaillierte Einführung unten

Systemarchitektur der ersten Generation

2014 sollte als das erste Jahr der Internetfinanzierung angesehen werden. Tatsächlich nutzten viele Internetunternehmen verschiedene Modelle, um zu überleben. Im Jahr 2014 wurden sie jedoch plötzlich populär . Diese Art von Website-Verkehr von Drittanbietern nahm plötzlich zu, und dann gab es immer mehr Berichte über verschiedene Internet-Finanzunternehmen, die Investitionen in Höhe von XXX US-Dollar erhielten, und die Richtlinien wurden nach und nach klar Auch große Unternehmen (Konzerne) nutzten diesen Trend, um nachzuhaken, darunter auch wir.

Der Hauptzweck des Systems der ersten Generation bestand darin, Zeit zu gewinnen, um sicherzustellen, dass das System in kürzester Zeit online ist. Zu diesem Zeitpunkt hatte die mobile Welle bereits begonnen, und beschloss daher, der Einführung des Systems Priorität einzuräumen mobile Version verfügbar und die Website konnte vorerst nicht berücksichtigt werden. Zu diesem Zeitpunkt verfügte das Unternehmen über technische Reserven an zwei Entwicklungssprachen, PHP und Java, da PHP große Vorteile bei der schnellen Entwicklung hatte, und entschied sich für die Übernahme des Front-End-PHP + Back-End-Java-Modells. Das System ist in drei Schichten unterteilt: Benutzerschicht: Android- und IOS-Mobilterminals; Schnittstellenschicht: PHP stellt Benutzer- und Transaktionsschnittstellen bereit: Das Backend besteht aus zwei Teilen, dem Hintergrund und dem Zeitsystem. Das Backend verwendet PHP-Entwicklung und die Schnittstellenschicht, um ein System gemeinsam zu nutzen, und das andere ist ein Zeitsystem, das für die Zinsberechnung, Dividendenverteilung, Ablauf und andere geplante Aufgaben verantwortlich ist und mit Java entwickelt wird.

Für grundlegende Dienste und Middleware bietet MySQL die grundlegendste Master-Slave-Unterstützung. Das System der ersten Generation verwendet nur die Hauptdatenbank von MySQL, und die Slave-Datenbank wird nur für die synchrone Sicherung verwendet Bieten, und nur dieser Teil wird verwendet, um Sekundärmarkt-Transferabgleich und andere asynchrone Nachrichtenbenachrichtigungen zu verwenden. Projektbereitstellung: PHP wird mit Apache bereitgestellt, der Timing-Dienst verwendet Tomcat6 als Anwendungsserver und lvs wird als Front-End-Apache-Last verwendet. Im Folgenden ist das Architekturdiagramm der ersten Generation aufgeführt System.

Nach der Einführung des Systems der ersten Generation erlangte die Erstellung von Websites und H5-Systemen (mobiler Browser oder WeChat) eine besondere Bedeutung. Da es sich als Internet-Finanzunternehmen nicht ertragen konnte, keine offizielle Website zu haben, begann es mit der Entwicklung von Websites und In diesem Zeitraum habe ich das zuvor von PHP erstellte Backend herausgenommen und es mithilfe von Java neu geplant. Bisher ist PHP für die drei Systeme Website, APP-Schnittstelle und H5 A-Kern verantwortlich Die von den drei Systemen gemeinsam genutzte Transaktion ist für das Backend verantwortlich. Für Verwaltungs- und Timing-Dienste bezeichnen wir diese Architektur im Allgemeinen als Architektur der 1.1-Generation.

Systemarchitekturdiagramm der Generation 1.1, der grüne Teil ist der geänderte Teil

Die Mängel des Systems der ersten Generation bestehen darin, dass das Geschäft zu konzentriert ist, es in Eile gestartet wird und es in der späteren Zeit viele Probleme gibt.

Systemarchitektur der zweiten Generation

Der Hintergrund des Systems der zweiten Generation ist, dass mit der rasanten Entwicklung des Geschäftsvolumens des Unternehmens viele in der Anfangsphase geschuldete technische Schulden explodierten und viele Probleme online auftauchten. Das gravierendste war die wiederholte Zahlung von Dividenden an Einzelpersonen Benutzer, und sie wurden auf verschiedene Weise beschimpft. Die Erinnerung ist jetzt noch frisch. Andererseits haben verschiedene Geschäftsabteilungen ständige Anforderungen und die Produkte des Unternehmens sind ständig gefragt. Daher sind sie in dieser Phase damit beschäftigt, verschiedene Produktionsprobleme zu lösen und gleichzeitig vertikale Geschäftssysteme zu entwickeln. Ich war damals fast verrückt geworden. Das System der ersten Generation war immer noch schwer zu erholen. Es war wirklich schmerzhaft und glücklich.

Das erste vertikale Subsystem, das online ging, war das Vertragssystem. Damals gab es keinen Vertrag, nachdem Benutzer Gebote abgegeben hatten. Viele Benutzer waren sehr besorgt und legten den Vorrang. Später wurde allein das Vertragssystem auf drei Versionen umgestellt. Die erste Version generierte nur PDFs, die zweite Phase erfolgte online mit elektronischen Signaturen, die dritte Phase fügte Wasserzeichen und angepasste und dynamisch generierte PDFs hinzu, gefolgt von der Entwicklung eines Punktesystems: Benutzereinladungen, Investitions- und andere Produktionspunkte können zum Eintauschen von Bargeldgutscheinen usw. verwendet werden. Extrahieren Sie das Nachrichtensystem: Site-Nachrichten, Textnachrichten, E-Mails usw.; Starten Sie das Online-Überwachungssystem, die Geschäftsüberwachung und die Serviceüberwachung Frühwarnung bei Ausfällen; jede Geschäftsabteilung wird weiterhin Anforderungen stellen und online gehen. Finanzsystem: Finanzpersonal berechnet Beträge und abnormale Transaktionen; entwickelt ein Vertriebssystem; mit vielen Drittsystemen.

Das System der ersten Generation wurde in Eile erstellt und die Produktschnittstelle war schrecklich. Wir begannen sofort mit der Planung von Website 2.0, APP2.0 und H52.0. Als Reaktion auf die Anforderungen des Front-End-Systems entwickelten wir ein CMS System im Back-End zur Veröffentlichung von Projekt- und Unternehmensankündigungen, Neuigkeiten usw. ; Die Produktseite der zweiten Generation plant im Allgemeinen viele Big-Data-Analysen. Es wird auf der offiziellen Website angezeigt, wohin Investitionspräferenzen und Investitionsbeträge gehen Die Datenanalyse erfolgt über eine Karte, und es werden auch Kalender, gesammelte Daten usw. ausgezahlt, da sie für die Offlineverarbeitung konzipiert sind Während der Planung werden die Daten von der MySQL-Slave-Bibliothek mit dem Mongodb-Cluster synchronisiert, und die Mapreduce-Technologie von Mongdo wird zur Verarbeitung großer Datenmengen verwendet. Unsere Datenbankschicht wird zur folgenden Architektur

MySQL wird in Echtzeit mit Mongodb synchronisiert. Wir verwenden das Tool tungsten-relicator, das einen Überwachungsagenten auf der MySQL-Serverseite startet, um das Binlog-Protokoll von MySQL in Echtzeit zu überwachen. Auf der Mongodb-Serverseite wird außerdem ein Dienst gestartet. Auf der Clientseite überwacht der Agent die Datenänderungen und sendet sie an den Server. Der Server analysiert sie und fügt sie in den Mongodb-Cluster ein, um eine Echtzeitsynchronisierung zu erreichen Bild oben. Ich habe ursprünglich einen Artikel geschrieben, um es vorzustellen: Big Data Practice-Data Synchronization Article tungsten-relicator (mysql->mongo) , tatsächlich ist dieses Tool nicht besonders stabil im Einsatz, aber da Am Anfang gab es nicht viele Optionen, aber nachdem ich mich allmählich damit vertraut gemacht hatte, wurde es stabil.

Wir haben mutig Golang verwendet, um das Datenbereinigungssystem zu entwickeln, aber jetzt ist es 1.8, mit dem ich noch nie in Berührung gekommen bin, und zum Glück hat es auch das Team selbst trainiert ist sehr einfach und effizient, obwohl ich auf das N getreten bin. Es gab viele Fallstricke, aber am Ende haben wir es pünktlich in die Produktion gebracht und später mit Golang ein Backend entwickelt, das auf dem Beego-Framework basierte. Das Big-Data-Analysesystem wurde später auf eine andere Generation aktualisiert. In jedem Front-End-Geschäftssystem wurden große Anstrengungen unternommen, um Benutzerdaten zu sammeln und diese schließlich in Mongodb zu speichern Die bereinigten Ergebnisse wurden zur Verwendung durch das Front-End-Geschäftssystem gespeichert. Später wurde eine neue Version des Datenanalysesystems mit beego+echart erstellt.

Architekturdiagramm eines Big-Data-Systems

Da der Druck auf die Back-End-Datenbank weiter zunimmt, wurden das Back-End-Managementsystem und das Business-System von Master und Slave getrennt; das Back-End-Managementsystem hat einen Cache hinzugefügt und einen unabhängigen Image-Server gestartet wurde mit Nginx erstellt; Systementwicklung der zweiten Generation. Dabei war es auch die am schnellsten wachsende Phase des Unternehmens, in der zahlreiche Aktivitäten online gestartet wurden.

Diagramm der Systemarchitektur der zweiten Generation:

Fassen wir kurz zusammen:
Die Architektur der zweiten Generation hat verschiedene Geschäftssysteme eingeführt, Master und Slave getrennt und eine Big-Data-Plattform aufgebaut, um eine technische Grundlage für mehr Datenverarbeitung in der Zukunft zu schaffen
Nachteile: Nach der Aufteilung jedes Geschäftssystems sind die Aufrufe zwischen den einzelnen Projekten kompliziert; es gibt viele Back-End-Systeme und es gibt separate Kontosysteme zwischen den einzelnen Systemen, um die Betriebsüberwachung der Plattform abzuschließen

Systemarchitektur der dritten Generation

Nachdem die Entwicklung des Systems der zweiten Generation abgeschlossen war, standen wir vor drei schmerzhaften Problemen. Das erste bestand darin, dass die Aufrufbeziehungen zwischen Systemen in den frühen Tagen des Systems der dritten Generation exponentiell zunahmen. Wir haben viele grundlegende Komponenten hinzugefügt, was dieses Problem verschärft. Das zweite Problem ergänzt das erste Problem und es gibt zu viele Aufrufbeziehungen zwischen Systemen. Wenn Sie eines der Subsysteme verschieben, müssen Sie möglicherweise die Konfigurationsdatei ändern Aufgrund der Aktualisierung eines Systems müssen häufig auch andere Systeme passiv aktualisiert werden, was die Inbetriebnahme und den Wechsel bei Problemen erschwert. Das dritte Problem besteht darin, dass wir viele Back-Ups entwickelt haben. Endsysteme, aber die Konten sind nicht einheitlich. Jedes Subsystem verfügt über ein eigenes Kontocenter und Geschäftsmitarbeiter müssen sich hin und her anmelden, um ihre tägliche Arbeit zu erledigen. Mit zunehmendem Geschäftsvolumen wird dieses Problem immer wichtiger.

Also begannen wir mit Forschung und Systemauswahl usw. Das erste zu lösende Problem bestand darin, die SOA-Service-Governance einzuführen und die Entkopplung zwischen Systemen durch Service-Registrierung und -Erkennung zu lösen. Wir haben damals viel recherchiert und uns schließlich aus keinem anderen Grund für Dubbo entschieden Viele Menschen gingen mit basischem Wasser durch das Wasser. Um das zweite Problem zu lösen, haben wir das Konfigurationscenter eingeführt. Damals haben wir Qihoo360/QConf von Spring, Spring-Cloud-Config, Taobaos Diamond und Baidus Disconf recherchiert. Das war perfekt für Spring Cloud, aber von hier aus stellten wir fest, dass Spring-Cloud und Spring-Boot den Grundstein für die Architekturauswahl der vierten Generation legten. Tatsächlich wurde disconf nur verwendet eine kleine Anzahl von Projekten und wurde nicht vollständig beworben; Das dritte Problem wird durch das Account Center gelöst, das Cas zur Implementierung von Single Sign-On, Shiro zur Berechtigungskontrolle und Dubbo zur Bereitstellung von Serverschnittstellen wie der Berechtigungsliste nach der Anmeldung verwendet.

Architekturdiagramm nach der Transformation

Auf dieser Grundlage haben wir viele grundlegende Komponenten extrahiert, darunter Zeichenklassen, Datumsklassen, Verschlüsselungsklassen usw., und wir haben einen FastDFS-Cluster zur Verarbeitung des Dateisystems erstellt. Unabhängig davon wurde ein geplantes Planungssystem entwickelt, das alle geplanten Aufgaben in das Planungssystem integriert. Welches System auch immer geplante Aufgaben benötigt, kann der Seite automatisch Planungsstrategien hinzufügen.

Später begann das Unternehmen mit dem Aufbau einer Crowdfunding-Plattform. Dieses Mal wurde das System vollständig in Java entwickelt und die App-Seite übernahm ein hybrides Entwicklungsmodell. Alle Seiten der ersten Ebene wurden nativ entwickelt, alle Seiten der zweiten Ebene In diesem Modell verwenden alle Backends Dubbo für den Dienst. Die endgültige Architektur ist wie folgt:

In der Abbildung ist nur ein Teil des Systems aufgeführt, stattdessen werden andere Dienste genutzt.

Das System der dritten Generation führte die SOA-Service-Governance ein und führte ein einheitliches Account Center und grundlegende Komponenten ein. Der Nachteil besteht darin, dass die Entwicklungsumgebung komplexer ist

Systemarchitektur der vierten Generation

Die Leute sind immer unzufrieden und die Technologie hofft immer, das beste Architektursystem zu verwenden. Während der Entwicklung der Systemarchitektur der dritten Generation wurde mir die Bequemlichkeit von Spring Cloud und Spring Boot immer bewusster Spring Boot gefällt mir sehr gut. Das Spring Cloud-System erfüllt auch alle Aspekte, die in einem großen System berücksichtigt werden müssen Andererseits hat das Land begonnen, P2P-Unternehmen strikt dazu zu verpflichten, Einlagen bei Banken zu haben. Nach der Analyse der relevanten Schnittstellen der Bank haben wir festgestellt, dass unser System gleichzeitig einer umfassenden Transformation bedarf Um den regulatorischen Anforderungen gerecht zu werden, hat das Unternehmen auch Baitiao-bezogene Produkte entwickelt, was ebenfalls ein großes Projekt ist. Unter Ausnutzung der beiden oben genannten Hintergründe haben wir beschlossen, Microservices bei der Arbeit an Bankdepot- und Baitiao-Projekten vollständig zu nutzen.

Es gibt drei Gründe, warum wir Dubbo aufgeben und Spring Cloud voll und ganz nutzen: 1. Dubbo wurde seit vielen Jahren nicht aktualisiert und Spring Cloud wird ständig aktualisiert und aktualisiert Die Cloud berücksichtigt nahezu alle Microservices, z. B. ein einheitliches Konfigurationscenter und ein Routing-Center 3. Spring Cloud ist nicht aufdringlich und perfekt in andere Spring-Projekte integriert, wodurch die Entwicklung effizienter wird.

Nachdem wir uns nun für die Verwendung von Spring Boot + Spring Cloud für die Transformation entschieden haben, steht die Auswahl der Microservice-Technologie fest. Wie soll die Transformation gestartet werden? Schließlich darf die Systemtransformation der neuen Generation nicht gleichzeitig das ursprüngliche Geschäft beeinträchtigen. Das Wichtigste ist, dass das ursprüngliche System zwar nach dem verteilten Entwicklungsmodell entwickelt wurde, einige Systeme jedoch aufgrund des alten Systems immer noch über einen eigenen unabhängigen Bibliotheksbetrieb verfügen Wenn das System Subsystemdaten ändern oder abfragen muss, müssen diese über Schnittstellenaufrufe zwischen Diensten abgerufen werden. Daher planen wir, das Springcloud-Projekt aus neu entwickelten Projekten und Projekten zu starten, die transformiert werden müssen. Das endgültige Systemarchitekturdiagramm sieht wie folgt aus.

Auf dem Weg der Architektur gibt es keinen Endpunkt, und die Verbesserung der Architektur dient dazu, das Geschäft besser zu unterstützen.