Como criar um sistema de pagamento faça você mesmo

Olá Habr! Nós da RBKmoney escrevemos um novo processamento de pagamento. Do zero. Bem, não é um sonho?

No entanto, como sempre, no caminho para o sonho, a maior parte do caminho teve que nadar ao longo dos rios com armadilhas, parte - para andar de bicicleta montada. Dessa forma, recebemos muitos conhecimentos interessantes e úteis que gostaríamos de compartilhar com você.

Informaremos como todo o processamento do RBKmoney Payments foi gravado, como chamamos. Como eles o tornaram resistente a cargas e falhas de equipamentos, como eles tiveram a possibilidade de sua escala horizontal quase linear.

E no final, quando todos decolamos, sem esquecer o conforto daqueles que estavam lá dentro, nosso sistema de pagamento foi criado com a idéia de ser interessante principalmente para desenvolvedores, aqueles que o criam.

Com este post, abrimos uma série de artigos nos quais compartilharemos itens técnicos, abordagens e implementações específicas, bem como a experiência no desenvolvimento de grandes sistemas distribuídos em princípio. O primeiro artigo é um artigo de revisão, nele designamos os marcos que divulgaremos em detalhes e, às vezes, em grandes detalhes.

Ao criar um sistema de pagamento, você precisa considerar várias coisas diferentes e desenvolver muitas soluções. Do processamento que pode processar milhares de solicitações simultâneas simultâneas de débito em dinheiro a interfaces amigáveis. Banal, se você não levar em conta as pequenas nuances.

A dura realidade é que existem organizações de pagamento por trás do processamento de pagamentos, de modo nenhum com os braços abertos aceitando esse tráfego e, às vezes, até pedindo "para nos enviar não mais que 3 solicitações por segundo". E as pessoas que, talvez, pela primeira vez na Internet decidiram pagar por algo, olham para interfaces. E qualquer batente UX, incompreensibilidade e atraso - esta é uma ocasião para entrar em pânico.

Uma cesta na qual você pode fazer compras mesmo durante tornados

Nossa abordagem para criar o processamento de pagamentos é fornecer a capacidade de sempre iniciar um pagamento. Não importa o que está acontecendo dentro de nós - o servidor se esgotou, o administrador ficou confuso nas redes, a eletricidade foi cortada no prédio / distrito / cidade, temos um diesel hmm ... perdemos. Isso não importa. O serviço ainda permitirá que você inicie o pagamento.

A abordagem parece familiar, certo?

Sim, fomos inspirados pelo conceito descrito no Amazon Dynamo Paper . Os caras da Amazon também construíram tudo para que o usuário pudesse colocar o livro na cesta, independentemente do horror que estava acontecendo do outro lado do monitor.

Obviamente, não violamos as leis da física e não descobrimos como refutar o teorema da PAC . Não é fato que o pagamento seja feito imediatamente - afinal, pode haver problemas do lado dos bancos, mas o serviço criará uma solicitação e o usuário verá que tudo funcionou. Sim, e, idealmente, ainda temos uma dúzia de listagens de pendências com uma dívida técnica, o que é um pecado, podemos responder 504 ocasionalmente.

Vamos olhar para o bunker, uma vez que o tornado do lado de fora da janela

Era necessário disponibilizar nosso gateway de pagamento sempre. Se o pico de carga aumentou, algo caiu ou entrou em manutenção no controlador de domínio - o usuário final não deve perceber isso.

Isso foi decidido minimizando os locais onde o estado do sistema está armazenado - é óbvio que os aplicativos sem estado são fáceis de escalar para o horizonte.

Os aplicativos em si estão girando nos contêineres do Docker, os logs dos quais confiamos de maneira confiável no repositório central do Elasticsearch; eles se encontram por meio da descoberta de serviços e os dados são transmitidos pelo IPv6 dentro do serviço Macro .

Todos os microsserviços coletados e trabalhando juntos, juntamente com serviços relacionados, são um serviço de macro, que fornece um gateway de pagamento, como você vê de fora como nossa API pública.

O SaltStack fica de olho no pedido, que descreve todo o estado do Macroservice.

Voltaremos com uma descrição detalhada de toda essa fazenda.

Com aplicativos mais fáceis.

Mas se você armazenar o estado em algum lugar, certifique-se de que em um banco de dados o custo da falha de uma parte dos nós seja mínimo. Além disso, para que ele não tenha um nó mestre com dados. De modo que com tempo de espera previsível para responder às solicitações. É o seu sonho aqui? Então, mesmo para atendê-lo, não era particularmente necessário e que os desenvolvedores erlangistas gostaram.

Sim, não dissemos que toda a parte on-line do nosso processamento em Erlang está gravada?

Como muitos provavelmente já adivinharam, não tivemos escolha como tal.

Todo o estado da parte on-line do nosso sistema é armazenado no Basho Riak . Também lhe diremos como cozinhar Riak e não quebre seus dedos (porque você quebrará seu cérebro), mas por enquanto vamos continuar.

Onde está o dinheiro, Lebowski?

Se você receber uma quantia infinita de dinheiro, poderá criar um processamento infinitamente confiável. Mas isso não é exato. E eles não nos dão muito dinheiro. Bem no nível do servidor "qualidade, mas China".

Felizmente, isso levou a efeitos positivos. Quando você entende que, como desenvolvedor, será um pouco difícil obter 40 núcleos físicos endereçados a 512 GB de RAM, é preciso sair e escrever pequenos aplicativos. Mas eles podem ser implantados quantos você quiser - os servidores ainda são baratos.

Mesmo em nosso mundo, todos os servidores tendem a não voltar à vida após uma reinicialização, ou mesmo a detectar falhas na fonte de alimentação no momento mais inoportuno.

De olho em todos esses horrores, aprendemos a construir um sistema com a expectativa de que qualquer parte dele necessariamente se quebre de repente. É difícil lembrar se essa abordagem causou algum inconveniente para o desenvolvimento da parte de processamento on-line. Talvez isso esteja de alguma forma relacionado à filosofia dos erlangistas e seu famoso conceito LetItCrash ?

Mas com servidores é mais fácil.

Nós descobrimos onde colocar os aplicativos, existem muitos deles, eles são escaláveis. A base também é distribuída, não há mestre, os nós queimados não são uma pena, podemos carregar rapidamente o carrinho com servidores, chegar ao DC e deixá-los com garfos nos racks.

Mas este não é o caso com matrizes de disco! A falha de até um pequeno armazenamento em disco é uma falha de parte do serviço de pagamento, que não podemos pagar. Armazenamento duplicado? Muito impraticável.

E não queremos comprar matrizes de disco com marca caras. Mesmo a partir de um simples senso de beleza - eles não olharão para os racks onde os substantivos estão agrupados em linhas pares. E é irracionalmente caro.

No final, decidimos não usar matrizes de disco. Todos os dispositivos de bloco que temos estão executando o CEPH nos mesmos servidores baratos - podemos colocá-los em racks nas grandes quantidades que precisamos.

Com o hardware de rede, a abordagem não é muito diferente. Tomamos os camponeses do meio, obtemos um equipamento bom e adequado para a tarefa, é bastante barato. Em caso de falha do switch, o segundo funciona em paralelo e o OSPF é configurado nos servidores, assegurando a convergência.

Assim, temos um sistema conveniente, tolerante a falhas e universal - um rack cheio de servidores simples e baratos, vários switches. O próximo estande. E assim por diante

Simples, conveniente e geral - muito confiável.

Ouça as regras de conduta a bordo

Nós nunca quisemos ir ao escritório, trabalhar e ser pago em dinheiro. O componente financeiro é muito importante, mas não substituirá o prazer de um trabalho bem feito. Já criamos sistemas de pagamento, inclusive em locais de trabalho anteriores. E aproximadamente imaginamos o que não queremos fazer. E eu não queria soluções padrão, mas comprovadas, não queria uma empresa chata.

E decidimos colocar a máxima frescura no trabalho. No desenvolvimento de sistemas de pagamento, novas soluções costumam ser limitadas, dizem eles, por que você precisa de uma janela de encaixe? E em geral. Não é segurança. Negar.

Decidimos não proibir nada, mas sim incentivar tudo novo. Portanto, em nossa produção, construímos um serviço de macro a partir de uma enorme pilha de aplicativos em contêineres docker, gerenciados por SaltStack , clusters Riak, Consul como serviço Discovery, uma implementação original do rastreamento de consultas em um sistema distribuído e muitas outras excelentes tecnologias.

E tudo isso é tão seguro que você pode publicar o programa Bugbounty no hackerone.com sem vergonha.

Obviamente, os primeiros passos ao longo desta estrada estavam cheios de uma quantidade absolutamente indecente de ancinhos. À medida que os examinamos, diremos, por exemplo, por que não temos um ambiente de teste e todo o processamento pode ser implantado no laptop do desenvolvedor com make up simples.
Como um monte de coisas interessantes.

Obrigado por escolher nossa companhia aérea!

PS: Conteúdo original! Todas as fotos do post são cenas da vida de nosso escritório.