Cómo hacer un sistema de pago hágalo usted mismo

Hola Habr! Nosotros en RBKmoney escribimos un nuevo procesamiento de pagos. Desde cero Bueno, ¿no es un sueño?

Sin embargo, como siempre, en el camino hacia el sueño, la mayor parte del camino tuvo que nadar a lo largo de los ríos con trampas, en parte, para andar en sus propias bicicletas ensambladas. De esta manera, recibimos muchos conocimientos interesantes y útiles que nos gustaría compartir con ustedes.

Le diremos cómo se escribió todo el procesamiento de pagos de RBKmoney, como lo llamamos. Cómo lo hicieron resistente a cargas y fallas de equipos, cómo se les ocurrió la posibilidad de su escalamiento horizontal casi lineal.

Y al final, cuando todos despegamos, sin olvidar la comodidad de los que estaban dentro, nuestro sistema de pago fue creado con la idea de ser interesante principalmente para los desarrolladores, aquellos que lo crean.

Con esta publicación, abrimos una serie de artículos en los que compartiremos aspectos técnicos específicos, enfoques e implementaciones, así como experiencia en el desarrollo de grandes sistemas distribuidos en principio. El primer artículo es un artículo de revisión, en él designamos los hitos que revelaremos en detalle, y algunas veces en gran detalle.

Cuando crea un sistema de pago, debe considerar un montón de cosas diferentes y desarrollar muchas soluciones. Desde el procesamiento que puede procesar miles de solicitudes simultáneas simultáneas de débito de dinero hasta interfaces fáciles de usar. Trivial, si no tienes en cuenta los pequeños matices.

La cruda realidad es que hay organizaciones de pago detrás del procesamiento de pagos, que no tienen los brazos abiertos y aceptan ese tráfico, y a veces incluso nos piden "que no nos envíen más de 3 solicitudes por segundo". Y las personas que, tal vez, por primera vez en Internet decidieron pagar por algo, miren las interfaces. Y cualquier jamb UX, incomprensibilidad y retraso: esta es una ocasión para entrar en pánico.

Una canasta en la que puede colocar compras incluso durante los tornados

Nuestro enfoque para crear el procesamiento de pagos es proporcionar la capacidad de iniciar siempre un pago. No importa lo que esté sucediendo dentro de nosotros: el servidor se quemó, el administrador se confundió en las redes, la electricidad se cortó en el edificio / distrito / ciudad, tenemos un diesel hmm ... perdimos. No importa El servicio aún le permitirá iniciar el pago.

El enfoque suena familiar, ¿verdad?

Sí, nos inspiramos en el concepto descrito en Amazon Dynamo Paper . Los chicos de Amazon también construyeron todo para que el usuario pueda poner el libro en la canasta, sin importar el horror que sucediera al otro lado de su monitor.

Por supuesto, no violamos las leyes de la física y no hemos descubierto cómo refutar el teorema del CAP . No es un hecho que el pago se realice de inmediato; después de todo, puede haber problemas en el lado de los bancos, pero el servicio creará una solicitud y el usuario verá que todo funcionó. Sí, y lo ideal es que sigamos siendo una docena de listados de pedidos pendientes con una deuda técnica, lo cual es un pecado, podemos responder 504 ocasionalmente.

Echemos un vistazo al búnker, una vez que el tornado salga por la ventana.

Era necesario que nuestra pasarela de pago siempre estuviera disponible. Si la carga máxima ha aumentado, algo se ha caído o ha entrado en mantenimiento en la CC: el usuario final no debería notarlo en absoluto.

Esto se decidió minimizando los lugares donde se almacena el estado del sistema; es obvio que las aplicaciones sin estado son fáciles de escalar hasta el horizonte.

Las aplicaciones mismas están girando en contenedores Docker, los registros desde los cuales nos fusionamos de manera confiable en el repositorio central de Elasticsearch; se encuentran a través de Service Discovery, y los datos se transmiten a través de IPv6 dentro del servicio Macro .

Todos los microservicios que se recopilan y trabajan juntos, junto con los servicios relacionados, son un servicio macro, que en última instancia le proporciona una pasarela de pago, como lo ve desde el exterior como nuestra API pública.

SaltStack vigila el pedido, que describe todo el estado de Macroservice.

Volveremos con una descripción detallada de toda esta granja.

Con aplicaciones más fáciles.

Pero si almacena el estado en algún lugar, asegúrese de hacerlo en una base de datos en la que el costo de falla de una parte de los nodos sea mínimo. Además, para que no tenga un nodo maestro con datos. De modo que con un tiempo de espera predecible para responder a las solicitudes. ¿Es tu sueño aquí? Entonces, incluso para repararlo, no era particularmente necesario, y eso les gustó a los desarrolladores erlangistas.

Sí, ¿no hemos dicho que toda la parte en línea de nuestro procesamiento en Erlang está escrita?

Como muchos ya habrán adivinado, no teníamos otra opción como tal.

Todo el estado de la parte en línea de nuestro sistema se almacena en Basho Riak . También le diremos cómo cocinar Riak y no romperse los dedos (porque se romperá el cerebro), pero por ahora continuemos.

¿Dónde está el dinero, Lebowski?

Si toma una cantidad infinita de dinero, es posible que pueda construir un procesamiento infinitamente confiable. Pero esto no es exacto. Y no nos dan mucho dinero. Justo en el nivel del servidor "calidad, pero China".

Afortunadamente, esto condujo a efectos positivos. Cuando comprenda que, como desarrollador, será un poco difícil para usted obtener 40 núcleos físicos con 512 GB de RAM, debe salir y escribir pequeñas aplicaciones. Pero se pueden implementar tantas veces como desee: los servidores siguen siendo económicos.

Incluso en nuestro mundo, los servidores tienden a no volver a la vida después de un reinicio, o incluso a detectar fallas en el suministro de energía en el momento más inoportuno.

Con la vista puesta en todos estos horrores, aprendimos cómo construir un sistema con la expectativa de que cualquier parte del mismo se rompa de repente. Es difícil recordar si este enfoque causó algún inconveniente para el desarrollo de la parte de procesamiento en línea. ¿Quizás esto está relacionado de alguna manera con la filosofía de los erlangistas y su famoso concepto LetItCrash ?

Pero con los servidores es más fácil.

Descubrimos dónde colocar las aplicaciones, hay muchas, son escalables. La base también se distribuye, no hay maestro, los nodos quemados no son una pena, podemos cargar rápidamente el carrito con servidores, venir al DC y dejarlos con horquillas en los bastidores.

¡Pero este no es el caso con las matrices de discos! La falla de incluso un almacenamiento en disco pequeño es una falla de una parte del servicio de pago, que no podemos permitirnos. ¿Almacenamiento duplicado? Demasiado poco práctico.

Y no queremos permitirnos costosos arreglos de discos de marca. Incluso por un simple sentido de belleza: no mirarán al lado de los bastidores donde los sustantivos se empaquetan en filas pares. Y es irrazonablemente caro.

Al final, decidimos no usar matrices de discos en absoluto. Todos los dispositivos de bloque que tenemos están ejecutando CEPH en los mismos servidores económicos: podemos colocarlos en racks en las grandes cantidades que necesitamos.

Con el hardware de red, el enfoque no es muy diferente. Tomamos a los campesinos medios, obtenemos un buen equipo adecuado para la tarea que es bastante económico. En caso de una falla del interruptor, el segundo funciona en paralelo, y OSPF está configurado en los servidores, se garantiza la convergencia.

Por lo tanto, tenemos un sistema conveniente, tolerante a fallas y universal: un estante lleno de servidores simples y baratos, varios conmutadores. El próximo stand. Y así sucesivamente.

Simple, conveniente y en general, muy confiable.

Escuche las reglas de conducta a bordo.

Nunca quisimos venir a la oficina, trabajar y cobrar en efectivo. El componente financiero es muy importante, pero no reemplazará el placer de un trabajo bien hecho. Ya hemos escrito sistemas de pago, incluso en lugares de trabajo anteriores. Y más o menos imaginé lo que no queremos hacer. Y no quería soluciones estándar, sino probadas, no quería una empresa aburrida.

Y decidimos llevar la máxima frescura al trabajo. En el desarrollo de sistemas de pago, las nuevas soluciones a menudo son limitadas, dicen, ¿por qué necesita un acoplador? Vamos sin él. Y en general No es seguridad. Negar

Decidimos no prohibir nada, sino alentar todo lo nuevo. Entonces, en nuestra producción, creamos un servicio macro a partir de una enorme pila de aplicaciones en contenedores acoplables, administrado a través de SaltStack , clusters Riak, Consul as a Service Discovery, una implementación original de rastreo de consultas en un sistema distribuido y muchas otras excelentes tecnologías.

Y todo esto es tan seguro que puede publicar el programa Bugbounty en hackerone.com sin vergüenza.

Por supuesto, los primeros pasos a lo largo de este camino estaban llenos de una cantidad absolutamente indecente de rastrillos. A medida que los revisemos, le diremos, también, por ejemplo, por qué no tenemos un entorno de prueba, y todo el procesamiento puede implementarse en la computadora portátil del desarrollador con un simple make up .
Como un montón de cosas interesantes.

¡Gracias por elegir nuestra aerolínea!

PD: contenido original! Todas las fotos en la publicación son escenas de la vida de nuestra oficina.