Главная » Хабрахабр » Как сделать платежную систему своими руками

Как сделать платежную систему своими руками

Мы в RBKmoney новый платежный процессинг написали. Привет, Хабр! Ну не мечта ли? С нуля.

На этом пути мы получили множество интересных и полезных знаний, которыми хотели бы поделиться с вами. Правда, как всегда, на пути к мечте, большую часть пути пришлось проплыть по рекам с подводными камнями, часть — проехать на собственноручно собранных велосипедах.

Как делали его устойчивым к нагрузкам и сбоям оборудования, как придумали возможность его практически линейного горизонтального масштабирования. Мы расскажем, как написали весь процессинг RBKmoney Payments, так мы его назвали.

И, под конец, как мы со всем этим взлетели, не забыв о комфорте тех, кто находится внутри — наша платежная система создавалась с мыслью о том, чтобы быть интересной в первую очередь для разработчиков, тех, кто ее создает.

Первая статья — обзорная, в ней мы обозначим вехи, которые будем раскрывать подробно, а иногда — очень подробно. Этим постом мы открываем цикл статей, в которых будем делиться как конкретными техническими вещами, подходами и реализациями, так и опытом разработки больших распределенных систем в принципе.

Disclaimer

За это время наша команда разработки заметно обновилась, у руля компании теперь новые люди. Со дня последней публикации в нашем блоге прошло ни много ни мало 5 лет.

От процессинга, способного обработать тысячи одновременных параллельных запросов на списание денег, до удобных и понятных для людей интерфейсов. Когда создаешь платежную систему, нужно учесть кучу самых разных вещей и разработать множество решений. Банально, если не учитывать мелкие нюансы.

А на интерфейсы смотрят люди, которые, может быть, впервые в интернете решились что-то оплатить. Суровая реальность такова, что за платежным процессингом находятся платежные организации, вовсе не с распростертыми объятиями принимающие такой трафик, а иногда даже просящие "присылать нам не более 3 запросов в секунду". И любой косяк UX, непонятность и задержка — это повод запаниковать.

Корзина, в которую можно положить покупки даже во время торнадо

Без разницы, что творится у нас внутри — сгорел сервер, админ запутался в сетях, отключили электричество в здании/районе/городе, у нас дизель хм… потеряли. Наш подход в создании платежного процессинга заключается в том, чтобы предоставить возможность всегда запустить платеж. Сервис все равно позволит запустить платеж. Неважно.

Подход звучит знакомо, не так ли?

Парни из Амазона тоже строили все так, что пользователь должен иметь возможность положить книжку в корзину, какая бы жуть ни творилась по ту сторону его монитора. Да, мы вдохновлялись концепцией, описанной в Amazon Dynamo Paper.

Не факт, что платеж тут же и проведется — ведь могут быть неполадки и на стороне банков, но запрос сервис создаст, и пользователь увидит, что все сработало. Конечно, мы не нарушаем законы физики и не придумали как опровергнуть CAP-теорему. Да и нам до идеала еще десяток листингов беклога с техническим долгом, чего греха таить, можем и 504 ответить изредка.

Заглянем в бункер, раз торнадо за окном

Возросла ли пиковая нагрузка, что-то упало или ушло на обслуживание в ДЦ — конечный пользователь не должен этого замечать вообще. Нужно было сделать наш платежный шлюз доступным всегда.

Это решили минимизацией мест, где хранится состояние системы — очевидно, что stateless-приложения легко масштабировать до горизонта.

Сами приложения у нас крутятся в Docker-контейнерах, логи из которых мы надежно сливаем в центральное Elasticsearch-хранилище; друг друга они находят через Service Discovery, а данные передают по IPv6 внутри Макросервиса.

Все собранные и работающие совместно микросервисы вместе с сопутствующими службами являются Макросервисом, который предоставляет вам в итоге платежный шлюз, каким вы его видите снаружи в виде нашего публичного API.

За порядком приглядывает SaltStack, в котором описано все состояние Макросервиса.

Мы еще вернемся с подробным описанием всего этого хозяйства.

С приложениями легче.

Еще чтобы в ней не было мастер-нод с данными. А вот если хранить где-то состояние, то обязательно в такой базе, в которой минимальна цена выхода из строя части нод. Это тут мечтают? Чтобы могла с предсказуемым временем ожидания на запросы отвечать. Тогда еще чтобы ее обслуживать особо не надо было, и чтобы разработчикам-эрлангистам нравилась.

Да, разве мы еще не сказали, что вся онлайн-часть нашего процессинга на Эрланге написана?

Как многие уже, наверное, догадались выбора у нас как такового и не было.

О том, как готовить Riak и не сломать себе пальцы (потому что мозг вы сломаете обязательно), мы еще расскажем, а пока продолжим дальше. Все состояние онлайн-части нашей системы хранится в Basho Riak.

Где деньги, Лебовски?

Но это не точно. Если взять бесконечное количество денег, возможно, удастся построить бесконечно надежный процессинг. В аккурат на сервера уровня "качественный, но Китай". Да и денег нам особо не выделили.

Когда понимаешь, что тебе как разработчику, будет несколько затруднительно получить 40 физических ядер, адресующих 512GB оперативки, приходится выкручиваться и писать маленькие приложения. К счастью, это привело к положительным эффектам. Зато их можно развернуть сколько угодно много — сервера все-таки недорогие.

Еще в нашем мире любые сервера имеют тенденцию не возвращаться после перезагрузки к жизни, или даже ловить отказ блоков питания в самый неподходящий момент.

Сложно припомнить, вызвал ли этот подход какие-либо неудобства для разработки онлайн-части процессинга. С оглядкой на все эти ужасы, мы научились строить систему с расчетом на то, что любая ее часть обязательно внезапно сломается. Возможно, это как-то связано с философией эрлангистов и их знаменитой концепцией LetItCrash?

Но с серверами легче.

База тоже распределенная, мастера нет, сгоревшие ноды не жалко, можем быстро нагрузить телегу серверами, приехать в ДЦ и покидать их вилами в стойки. Мы разобрались, где размещать приложения, их много, они масштабируются.

Выход из строя даже небольшого дискового хранилища — это отказ части платежного сервиса, чего мы себе позволить не можем. Но с дисковыми массивами так не поступить! Слишком нецелесообразно. Дублировать СХД?

Даже из простого чувства прекрасного — они не будут смотреться рядом со стойками, где ровными рядами набиты ноунеймы. А дорогие брендовые дисковые массивы мы себе позволить не хотим. Да и неоправданно дорого это все стоит.

Все блочные устройства у нас крутятся под CEPH на одинаковых недорогих серверах — мы можем ставить их в стойки в больших, нужных нам количествах. В итоге мы решили не использовать дисковых массивов вообще.

Берем середнячков, получаем хорошее, подходящее под задачи оборудование совсем недорого. С сетевым железом подход не сильно отличается. На случай выхода из строя свитча — параллельно работает второй, а на серверах настроен OSPF, сходимость обеспечена.

Следующая стойка. Таким образом у нас получилась удобная, отказоустойчивая и универсальная система — стойка, набитая простыми дешевыми серверами, несколько свитчей. И так далее.

Просто, удобно и в целом — очень надежно.

Прослушайте правила поведения на борту

Финансовая составляющая очень важна, но она не заменит удовольствия от хорошо сделанной работы. Нам никогда не хотелось приходить в офис, делать работу и получать оплату деньгами. И примерно представляли, чем мы не хотим заниматься. Мы уже писали платежные системы, в том числе и на предыдущих местах работы. А не хотелось стандартных, но проверенных решений, не хотелось скучного энтерпрайза.

В разработке платежных систем часто ограничивают новые решения, мол, зачем вам докер вообще, давайте-ка без него. И мы решили подтянуть в работу максимальный свежак. Несекьюрно. И вообще. Запретить.

Так у нас в продакшене построился Макросервис из огромной кучи приложений в докер-контейнерах, управляемый через SaltStack, кластеры Riak'а, Consul в качестве Service Discovery, оригинальная реализация трассировки запросов в распределенной системе и множество других замечательных технологий. Мы решили ничего не запрещать, а наоборот, поощрять все новое.

И все это безопасно настолько, что можно без стыда публиковать программу Bugbounty на hackerone.com.

Как мы по ним пробежались, мы обязательно расскажем, также расскажем, например, почему у нас нет тестовой среды, а весь процессинг можно развернуть на ноутбуке разработчика простым make up.
Как и еще кучу интересных вещей. Разумеется, первые же шаги по этой дороге оказались усеяны каким-то уж совсем неприличным количеством граблей.

Спасибо, что выбрали нашу авиакомпанию!

S.: Original content! P. Все фотографии в посте — сцены из жизни нашего офиса.


Оставить комментарий

Ваш email нигде не будет показан
Обязательные для заполнения поля помечены *

*

x

Ещё Hi-Tech Интересное!

[Перевод] Рассуждение о священных войнах, а также мольба о мире

Вступление переводчика Я вполглаза слежу за зреющим конфликтом в сообществе Linux. Материалов об этом везде публикуется довольно много, началось всё с этого, в текущем состоянии отражено, например, здесь, а за первоисточником можно обращаться сюда. Среди всего обилия информации меня заинтересовало ...

DevOps на краю Вселенной

Чтобы разобраться, как связана Вселенная, рыба и DevOps, нужно изучить расписание DevOpsConf Russia. Тем более конференция уже через неделю, 1–2 октября, и так и так надо планировать, какие из выступлений удастся послушать. Постараюсь в этом помочь — все-таки я приложил не мало усилий, чтобы программа получилась такой насыщенной. ...