Comment faire un système de paiement à faire soi-même

Bonjour, Habr! Chez RBKmoney, nous avons écrit un nouveau traitement des paiements. De zéro. Eh bien, n'est-ce pas un rêve?

Cependant, comme toujours, sur le chemin du rêve, la plupart du temps devait nager le long des rivières avec des pièges, en partie - pour monter sur vos propres vélos assemblés. De cette façon, nous avons reçu beaucoup de connaissances intéressantes et utiles que nous aimerions partager avec vous.

Nous vous expliquerons comment tout le traitement de RBKmoney Payments a été écrit, comme nous l'avons appelé. Comment ils l'ont rendu résistant aux charges et aux pannes d'équipement, comment ils ont proposé la possibilité d'une mise à l'échelle horizontale presque linéaire.

Et au final, comme nous avons tous décollé, sans oublier le confort de ceux qui s'y trouvent, notre système de paiement a été créé avec l'idée d'être principalement intéressant pour les développeurs, ceux qui le créent.

Avec cet article, nous ouvrons une série d'articles dans lesquels nous partagerons à la fois des choses techniques spécifiques, des approches et des implémentations, ainsi que de l'expérience dans le développement de grands systèmes distribués en principe. Le premier article est un article de synthèse, dans lequel nous désignons les jalons que nous divulguerons en détail, et parfois en détail.

Lorsque vous créez un système de paiement, vous devez considérer un tas de choses différentes et développer de nombreuses solutions. Du traitement capable de traiter des milliers de demandes simultanées de débit d'argent aux interfaces conviviales. Trite, si vous ne tenez pas compte des petites nuances.

La dure réalité est qu'il y a des organisations de paiement derrière le traitement des paiements, pas du tout à bras ouverts acceptant un tel trafic, et demandant même parfois "de ne pas nous envoyer plus de 3 demandes par seconde". Et les gens qui, peut-être, pour la première fois sur Internet ont décidé de payer quelque chose, regardent les interfaces. Et tout jambage UX, incompréhensibilité et retard - c'est l'occasion de paniquer.

Un panier dans lequel vous pouvez placer vos achats même pendant les tornades

Notre approche de la création du traitement des paiements consiste à offrir la possibilité de toujours commencer un paiement. Peu importe ce qui se passe en nous - le serveur a grillé, l'administrateur s'est perdu dans les réseaux, l'électricité a été coupée dans le bâtiment / quartier / ville, nous avons un diesel hmm ... nous avons perdu. Peu importe. Le service vous permettra toujours de commencer le paiement.

L'approche semble familière, non?

Oui, nous avons été inspirés par le concept décrit dans Amazon Dynamo Paper . Les gars d'Amazon ont également tout construit pour que l'utilisateur puisse mettre le livre dans le panier, peu importe l'horreur qui se passait de l'autre côté de son écran.

Bien sûr, nous ne violons pas les lois de la physique et n'avons pas compris comment réfuter le théorème de la PAC . Ce n'est pas un fait que le paiement sera effectué immédiatement - après tout, il peut y avoir des problèmes du côté des banques, mais le service va créer une demande et l'utilisateur verra que tout a fonctionné. Oui, et nous sommes idéalement encore une douzaine de listes de backlog avec une dette technique, ce qui est un péché, nous pouvons répondre 504 occasionnellement.

Regardons dans le bunker, une fois la tornade à l'extérieur de la fenêtre

Il était nécessaire de rendre notre passerelle de paiement toujours disponible. Que la charge de pointe ait augmenté, que quelque chose soit tombé ou soit passé en maintenance dans le DC - l'utilisateur final ne devrait pas le remarquer du tout.

Cela a été décidé en minimisant les endroits où l'état du système est stocké - il est évident que les applications sans état sont faciles à mettre à l'échelle à l'horizon.

Les applications elles-mêmes tournent dans des conteneurs Docker, les journaux à partir desquels nous fusionnons de manière fiable dans le référentiel central Elasticsearch; ils se retrouvent via Service Discovery et les données sont transmises via IPv6 dans le service Macro .

Tous les microservices qui sont collectés et fonctionnent ensemble, ainsi que les services associés, sont un Macroservice, qui vous fournit finalement une passerelle de paiement, comme vous le voyez de l'extérieur comme notre API publique.

SaltStack garde un œil sur la commande, qui décrit l'état complet de Macroservice.

Nous reviendrons avec une description détaillée de l'ensemble de cette ferme.

Avec des applications plus faciles.

Mais si vous stockez l'état quelque part, assurez-vous de le faire dans une base de données dans laquelle le coût de défaillance d'une partie des nœuds est minime. De plus, afin qu'il ne dispose pas d'un nœud maître avec des données. Ainsi, avec un temps d'attente prévisible pour répondre aux demandes. Est-ce votre rêve ici? Ensuite, même pour le réparer, ce n'était pas particulièrement nécessaire, et les développeurs erlangistes l'ont aimé.

Oui, n'avons-nous pas dit que toute la partie en ligne de notre traitement à Erlang est écrite?

Comme beaucoup l'ont probablement déjà deviné, nous n'avions pas le choix en tant que tel.

L'état complet de la partie en ligne de notre système est stocké dans Basho Riak . Nous vous dirons également comment cuisiner le Riak et ne pas vous casser les doigts (car vous allez vous casser le cerveau), mais pour l'instant continuons.

Où est l'argent, Lebowski?

Si vous prenez une somme d'argent infinie, vous pourrez peut-être créer un traitement infiniment fiable. Mais ce n'est pas exact. Et ils ne nous donnent pas beaucoup d'argent. Au niveau du serveur "la qualité, mais la Chine".

Heureusement, cela a eu des effets positifs. Lorsque vous comprenez qu'en tant que développeur, il sera quelque peu difficile pour vous d'obtenir 40 cœurs physiques adressant 512 Go de RAM, vous devez sortir et écrire de petites applications. Mais ils peuvent être déployés autant que vous le souhaitez - les serveurs sont encore peu coûteux.

Même dans notre monde, tous les serveurs ont tendance à ne pas reprendre vie après un redémarrage, ou même à intercepter une panne d'alimentation au moment le plus inopportun.

En gardant un œil sur toutes ces horreurs, nous avons appris à construire un système dans l'espoir qu'une partie de celui- ci se briserait nécessairement soudainement. Il est difficile de se rappeler si cette approche a causé des inconvénients pour le développement de la partie traitement en ligne. Peut-être que cela est en quelque sorte lié à la philosophie des Erlangistes et à leur célèbre concept LetItCrash ?

Mais avec les serveurs, c'est plus facile.

Nous avons trouvé où placer les applications, il y en a beaucoup, elles sont évolutives. La base est également distribuée, il n'y a pas de maître, les nœuds brûlés ne sont pas dommage, nous pouvons rapidement charger le chariot avec des serveurs, venir au DC et les laisser avec des fourches dans les racks.

Mais ce n'est pas le cas avec les baies de disques! L'échec, même d'un petit stockage sur disque, est une défaillance d'une partie du service de paiement, que nous ne pouvons pas nous permettre. Stockage en double? Trop peu pratique.

Et nous ne voulons pas nous permettre des baies de disques de marque coûteuses. Même à partir d'un simple sens de la beauté - ils ne regarderont pas à côté des racks où les noms sont emballés en rangées paires. Et c'est excessivement cher.

Finalement, nous avons décidé de ne pas utiliser du tout les baies de disques. Tous les périphériques blocs que nous avons exécutent CEPH sur les mêmes serveurs peu coûteux - nous pouvons les mettre dans des racks en grande quantité dont nous avons besoin.

Avec le matériel réseau, l'approche n'est pas très différente. Nous prenons les paysans moyens, nous obtenons un bon équipement adapté à la tâche est assez peu coûteux. En cas de panne d'un commutateur, le second fonctionne en parallèle et OSPF est configuré sur les serveurs, la convergence est assurée.

Ainsi, nous avons un système pratique, tolérant aux pannes et universel - un rack rempli de serveurs simples et bon marché, plusieurs commutateurs. Le prochain stand. Et ainsi de suite.

Simple, pratique et global - très fiable.

Écoutez les règles de conduite à bord

Nous n'avons jamais voulu venir au bureau, travailler et être payés en espèces. La composante financière est très importante, mais elle ne remplacera pas le plaisir d'un travail bien fait. Nous avons déjà écrit des systèmes de paiement, y compris sur les lieux de travail précédents. Et imaginé à peu près ce que nous ne voulons pas faire. Et je ne voulais pas de solutions standard mais éprouvées, je ne voulais pas d'une entreprise ennuyeuse.

Et nous avons décidé de tirer le maximum de fraîcheur dans le travail. Dans le développement des systèmes de paiement, les nouvelles solutions sont souvent limitées, disent-ils, pourquoi avez-vous besoin d'un docker, allons-y sans. Et en général. Pas de sécurité. Refuser.

Nous avons décidé de ne rien interdire, mais plutôt d'encourager tout ce qui est nouveau. Ainsi, dans notre production, nous avons construit un service de macro à partir d'une énorme pile d'applications dans des conteneurs docker, géré via SaltStack , les clusters Riak, Consul as a Service Discovery, une implémentation originale du suivi des requêtes dans un système distribué et de nombreuses autres technologies de pointe.

Et tout cela est si sûr que vous pouvez publier le programme Bugbounty sur hackerone.com sans honte.

Bien sûr, les toutes premières étapes de cette route étaient jonchées de râteaux absolument indécents. Au fur et à mesure que nous les parcourons, nous vous dirons, expliquons également, par exemple, pourquoi nous n'avons pas d'environnement de test, et tous les traitements peuvent être déployés sur l'ordinateur portable du développeur avec un make up simple.
Comme un tas de choses intéressantes.

Merci d'avoir choisi notre compagnie aérienne!

PS: contenu original! Toutes les photos dans le post sont des scènes de la vie de notre bureau.