So erstellen Sie ein Do-it-yourself-Zahlungssystem

Hallo Habr! Wir bei RBKmoney haben eine neue Zahlungsabwicklung geschrieben. Von Grund auf neu. Nun, ist es nicht ein Traum?

Auf dem Weg zum Traum musste der größte Teil des Weges jedoch wie immer mit Fallstricken entlang der Flüsse schwimmen, um auf Ihren eigenen montierten Fahrrädern zu fahren. Auf diese Weise haben wir viele interessante und nützliche Kenntnisse erhalten, die wir gerne mit Ihnen teilen möchten.

Wir werden Ihnen sagen, wie die gesamte RBKmoney Payments-Verarbeitung geschrieben wurde, wie wir sie genannt haben. Wie sie es widerstandsfähig gegen Lasten und Geräteausfälle machten, wie sie auf die Möglichkeit einer nahezu linearen horizontalen Skalierung kamen.

Und am Ende, als wir alle losfuhren, wurde unser Zahlungssystem mit dem Gedanken geschaffen, vor allem für Entwickler interessant zu sein, für diejenigen, die es erstellen.

Mit diesem Beitrag eröffnen wir eine Reihe von Artikeln, in denen wir sowohl spezifische technische Dinge, Ansätze und Implementierungen als auch Erfahrungen bei der Entwicklung großer verteilter Systeme im Prinzip teilen. Der erste Artikel ist ein Übersichtsartikel. Darin bezeichnen wir die Meilensteine, die wir detailliert und manchmal sehr detailliert offenlegen werden.

Wenn Sie ein Zahlungssystem erstellen, müssen Sie eine Reihe verschiedener Dinge berücksichtigen und viele Lösungen entwickeln. Von der Verarbeitung, die Tausende von gleichzeitigen Anfragen zur Geldabbuchung gleichzeitig verarbeiten kann, bis hin zu benutzerfreundlichen Oberflächen. Trite, wenn Sie die kleinen Nuancen nicht berücksichtigen.

Die harte Realität ist, dass es Zahlungsorganisationen gibt, die hinter der Zahlungsabwicklung stehen, überhaupt nicht mit offenen Armen, die solchen Verkehr akzeptieren und manchmal sogar darum bitten, "uns nicht mehr als 3 Anfragen pro Sekunde zu senden". Und Leute, die sich vielleicht zum ersten Mal im Internet entschieden haben, für etwas zu bezahlen, schauen sich Schnittstellen an. Und jeder Pfosten UX, Unverständlichkeit und Verzögerung - dies ist ein Anlass zur Panik.

Ein Korb, in den Sie auch bei Tornados einkaufen können

Unser Ansatz zur Erstellung der Zahlungsabwicklung besteht darin, die Möglichkeit zu bieten, immer eine Zahlung zu starten. Es spielt keine Rolle, was in uns passiert - der Server ist durchgebrannt, der Administrator war in den Netzwerken verwirrt, der Strom im Gebäude / Bezirk / Stadt wurde abgeschaltet, wir haben einen Diesel hmm ... wir haben verloren. Nicht wichtig. Mit dem Service können Sie die Zahlung weiterhin starten.

Der Ansatz kommt mir bekannt vor, oder?

Ja, wir haben uns von dem in Amazon Dynamo Paper beschriebenen Konzept inspirieren lassen. Die Jungs von Amazon haben auch alles so gebaut, dass der Benutzer das Buch in den Korb legen kann, egal was für ein Horror auf der anderen Seite seines Monitors passiert ist.

Natürlich verstoßen wir nicht gegen die Gesetze der Physik und haben nicht herausgefunden, wie wir den CAP-Satz widerlegen können. Es ist keine Tatsache, dass die Zahlung sofort erfolgt - schließlich kann es Probleme auf der Bankseite geben, aber der Service erstellt eine Anfrage und der Benutzer sieht, dass alles funktioniert hat. Ja, und wir sind im Idealfall immer noch ein Dutzend Rückstände mit einer technischen Verschuldung, was eine Sünde ist. Wir können gelegentlich 504 beantworten.

Schauen wir in den Bunker, sobald der Tornado vor dem Fenster steht

Es war notwendig, unser Zahlungsgateway immer verfügbar zu machen. Unabhängig davon, ob die Spitzenlast zugenommen hat, etwas gefallen ist oder im DC gewartet wurde - der Endbenutzer sollte dies überhaupt nicht bemerken.

Dies wurde durch Minimierung der Orte entschieden, an denen der Status des Systems gespeichert ist. Es ist offensichtlich, dass zustandslose Anwendungen leicht bis zum Horizont skaliert werden können.

Die Anwendungen selbst drehen sich in Docker-Containern, deren Protokolle wir zuverlässig in das zentrale Elasticsearch-Repository einbinden. Sie finden sich über Service Discovery und die Daten werden über IPv6 innerhalb des Makrodienstes übertragen .

Alle Mikrodienste, die zusammen mit verwandten Diensten gesammelt werden und zusammenarbeiten, sind Makrodienste, die Ihnen letztendlich ein Zahlungsgateway bieten, wie Sie es von außen als unsere öffentliche API betrachten.

SaltStack behält die Bestellung im Auge, die den gesamten Status von Macroservice beschreibt.

Wir werden mit einer detaillierten Beschreibung dieser gesamten Farm zurückkommen.

Mit Anwendungen einfacher.

Wenn Sie den Status jedoch irgendwo speichern, stellen Sie sicher, dass Sie ihn in einer Datenbank speichern, in der die Ausfallkosten eines Teils der Knoten minimal sind. Auch damit es keinen Masterknoten mit Daten gibt. So dass mit vorhersehbarer Wartezeit auf Anfragen zu reagieren. Ist es dein Traum hier? Selbst um es zu warten, war es nicht besonders notwendig, und dass es den Erlangist-Entwicklern gefiel.

Ja, haben wir nicht gesagt, dass der gesamte Online-Teil unserer Verarbeitung in Erlang geschrieben ist?

Wie viele wahrscheinlich bereits vermutet haben, hatten wir als solche keine Wahl.

Der gesamte Status des Online-Teils unseres Systems wird in Basho Riak gespeichert. Wir werden Ihnen auch sagen, wie man Riak kocht und sich nicht die Finger bricht (weil Sie sich das Gehirn brechen), aber jetzt machen wir weiter.

Wo ist das Geld, Lebowski?

Wenn Sie unendlich viel Geld nehmen, können Sie möglicherweise eine unendlich zuverlässige Verarbeitung aufbauen. Das ist aber nicht richtig. Und sie geben uns nicht viel Geld. Direkt auf Serverebene "Qualität, aber China".

Glücklicherweise führte dies zu positiven Effekten. Wenn Sie verstehen, dass es für Sie als Entwickler etwas schwierig sein wird, 40 physische Kerne für 512 GB RAM zu erhalten, müssen Sie kleine Anwendungen schreiben. Sie können jedoch beliebig oft bereitgestellt werden - die Server sind immer noch kostengünstig.

Selbst in unserer Welt werden Server nach einem Neustart nicht wieder zum Leben erweckt oder können im ungünstigsten Moment sogar einen Stromversorgungsausfall feststellen.

Mit Blick auf all diese Schrecken haben wir gelernt, wie man ein System mit der Erwartung baut, dass ein Teil davon notwendigerweise plötzlich kaputt geht. Es ist schwer zu erinnern, ob dieser Ansatz Unannehmlichkeiten für die Entwicklung des Online-Verarbeitungsteils verursachte. Vielleicht hängt das irgendwie mit der Philosophie der Erlangisten und ihrem berühmten Konzept LetItCrash zusammen ?

Aber mit Servern ist es einfacher.

Wir haben herausgefunden, wo Anwendungen platziert werden sollen. Es gibt viele davon. Sie sind skalierbar. Die Basis ist auch verteilt, es gibt keinen Master, verbrannte Knoten sind nicht schade, wir können den Wagen schnell mit Servern beladen, zum DC kommen und sie mit Gabeln in den Racks lassen.

Dies ist jedoch bei Festplatten-Arrays nicht der Fall! Der Ausfall selbst eines kleinen Festplattenspeichers ist ein Ausfall eines Teils des Zahlungsdienstes, den wir uns nicht leisten können. Doppelter Speicher? Zu unpraktisch.

Und wir wollen uns keine teuren Marken-Disk-Arrays leisten. Selbst aus einem einfachen Sinn für Schönheit - sie werden nicht neben die Gestelle schauen, in denen die Substantive in gleichmäßigen Reihen verpackt sind. Und es ist unangemessen teuer.

Am Ende haben wir uns entschieden, überhaupt keine Festplatten-Arrays zu verwenden. Alle Blockgeräte, die wir haben, führen CEPH auf denselben kostengünstigen Servern aus - wir können sie in großen Mengen in Racks stellen, die wir benötigen.

Bei Netzwerkhardware ist der Ansatz nicht viel anders. Wir nehmen die Mittelbauern, wir bekommen eine gute, geeignete Ausrüstung für die Aufgabe ist recht günstig. Bei einem Switch-Fehler arbeitet der zweite parallel und OSPF ist auf den Servern konfiguriert. Die Konvergenz ist gewährleistet.

So haben wir ein praktisches, fehlertolerantes und universelles System - ein Rack voller einfacher, billiger Server und mehrerer Switches. Der nächste Stand. Usw.

Einfach, bequem und insgesamt - sehr zuverlässig.

Hören Sie sich die Verhaltensregeln an Bord an

Wir wollten nie ins Büro kommen, arbeiten und bar bezahlt werden. Die finanzielle Komponente ist sehr wichtig, ersetzt jedoch nicht das Vergnügen einer gut gemachten Arbeit. Wir haben bereits Zahlungssysteme geschrieben, auch an früheren Arbeitsorten. Und grob vorgestellt, was wir nicht wollen. Und ich wollte keine Standardlösungen, sondern bewährte Lösungen, ich wollte kein langweiliges Unternehmen.

Und wir haben uns entschlossen, die maximale Frische in die Arbeit zu bringen. Bei der Entwicklung von Zahlungssystemen sind neue Lösungen oft begrenzt. Sie sagen, warum brauchen Sie überhaupt einen Docker? Lassen Sie uns darauf verzichten. Und überhaupt. Keine Sicherheit. Verweigern.

Wir haben beschlossen, nichts zu verbieten, sondern alles Neue zu fördern. Daher haben wir in unserer Produktion einen Makroservice aus einem riesigen Stapel von Docker-Container-Anwendungen erstellt, die über SaltStack , Riak-Cluster, Consul as Service Discovery, eine ursprüngliche Implementierung der Abfrageverfolgung in einem verteilten System und viele andere großartige Technologien verwaltet werden.

Und das alles ist so sicher, dass Sie das Bugbounty-Programm ohne Scham auf hackerone.com veröffentlichen können.

Natürlich waren die ersten Schritte entlang dieser Straße mit absolut unanständigen Rechen übersät. Während wir sie durchgingen, werden wir Ihnen sagen, zum Beispiel, warum wir keine Testumgebung haben und die gesamte Verarbeitung mit einfachem make up auf dem Laptop des Entwicklers bereitgestellt werden kann.
Wie ein Haufen interessanter Dinge.

Vielen Dank, dass Sie sich für unsere Fluggesellschaft entschieden haben!

PS: Originalinhalt! Alle Fotos in der Post sind Szenen aus dem Leben unseres Büros.