Привет! Меня зовут Александр Тарасов, я тимлид команды Billing.Arch в Авито. В этой статье я рассказываю, как мы решили проблему высокой зависимости систем платежей и финансового учёта с помощью изменения архитектуры и внедрения новой технологии управления бизнес-процессами.
Эта история о том, как мы переосмыслили и трансформировали существующую микросервисную архитектуру процессинга в Billing и решили сразу 3 фундаментальных проблемы, а наша ключевая метрика time to market улучшилась в 6 раз.
О чём пойдёт речь:
Проблема
Ранее при запуске нового продукта в Авито наша команда погружалась в его детали и реализовывала часть бизнес-логики в процессинге. Такой подход имел определённые издержки, но был осознанным, так как это позволяло ускорить запуск продуктов в период активного роста компании. Со временем продуктовой логики стало так много, что основным фокусом нашей команды являлась её поддержка.
Продуктовые команды могли ждать месяц, пока мы сделаем свою работу. Естественно, пока они ждут, они не зарабатывают, а это упущенная прибыль компании. Когда таких команд стало много, а продуктов ещё больше, то наша команда превратилась в бутылочное горлышко.
Задача
Перед нами стояла задача разработать новую архитектуру, способную обеспечить бизнесу быстрый тест и вывод продуктов на рынок, обрабатывать повышенный трафик в период распродаж и восстанавливаться в случае сбоя. Мы также должны были предоставить инструментарий продуктовым командам, чтобы они могли самостоятельно запускать продукты без нашего участия.
На тот момент – три года назад – процессинг был реализован в виде микросервисной архитектуры на PHP, которая обладал рядом фундаментальных проблем:
в систему процессинга протекала бизнес-логика каждого из продуктов, что делало её поддержку крайне сложной, а последствия инцидентов очень дорогими;
система в случае сбоя не умела сама восстанавливаться и завершать начатые операции, что приводило к неконсистентному состоянию в учёте;
высокая связность систем платежей и процессинга блокировала оказание услуги до момента завершения всех операций в учёте.
В старой системе процессинга регулярно возникали инциденты. Наша команда быстро их устраняла, чтобы спасти пользовательский опыт и деньги. Но всё это человеческий ресурс, который не безграничен. Было понятно, что ч��рез какое-то время с ростом компании ресурса перестанет хватать.
Решение
Первое, что требовалось сделать – снизить сложность системы и улучшить масштабируемость микросервисов. Мы спроектировали новую архитектуру процессинга основываясь на Domain-Oriented Microservice Architecture (DOMA) – это подход к проектированию микросервисов, при котором каждый сервис соответствует конкретному бизнес-домену и инкапсулирует внутри себя все необходимые данные.
Billing был разделен на четыре домена с определением зоны ответственности:
Payments:
– приём и обработка платежей;
– интеграция с провайдерами;
– платёжная страница;
– способы оплаты;
– соответствие требованиям PCI DSS;
– антифрод.Billing:
– процессинг платных услуг;
– интеграция с учётом;
– планировщик списаний;
– инфомодель;
– управление услугами.Ledger:
– финансовый учёт;
– бонусный учёт;
– формирование финансового отчёта;
– интеграция с 1С;
– контрольные процедуры;
– расчёт и отдача балансов.Fiscalization:
– интеграция с провайдерами;
– формирование чеков.
Домены были распределены между отдельными командами, отвечающими за их развитие.
Далее мы прошли ещё одно значительное изменение – платформизацию процессинга. Наша команда перешла от модели совладения продуктами к предоста��лению возможностей бизнесу. Мы внедрили менеджер услуг и API-first для интеграций, чтобы продуктовые команды могли сами запускать продукты. Основной фокус – на опыте разработчиков и осознанном потреблении возможностей процессинга.
Платформа и её архитектура построены на основе Temporal – технологии, разработанной компанией Uber. Это инструмент, который позволяет управлять бизнес-процессами и добиться eventual consistency – согласованности в конечном счёте, когда все данные находятся в актуальном и достоверном состоянии. После проведения оплаты важно, чтобы в финансовом учёте были созданы корректные проводки, и деньги проходили по верным счетам. Temporal помогает решить эту задачу, гарантируя, что все транзакции будут учтены даже после сбоя.
Мы не говорим, что платформа выполнит свою работу моментально сию секунду, но мы гарантируем, что она завершит все свои процессы правильно, и всё будет выглядеть хорошо для пользователя и учета.
Конкурентами Temporal были Camunda BPM, Cadence и Conductor от Netflix.
Comunda плохо подходит для длительных workflow, для Cadence требуется высокая DevOps экспертиза в команде, а Conductor – устаревшее решение, даже сам Netflix отказался от его развития и перешёл на Temporal.
Temporal отвечал нашим запросам. В нём реализована важная нам концепция Durable Execution – способность переживать отказы системы, устойчивость к ошибкам за счёт сохранения состояния процесса.
Если что-то сбойнуло, например, отказала база данных или электричество пропало, то система способна обеспечить целостность данных и завершение начатых операций после восстановления.
Первый пробный запуск Temporal в инфраструктуре Авито показал его пригодность и работоспособность, но и некоторые неучтённые проблемы.
Тогда не было никаких гарантий, что удастся его запустить, потому что никто в компании до нас с ним не работал.
Мы адаптировали его под себя с учётом особенностей нашей инфраструктуры: развернули кла��тер в 3х дата-центрах, добавили балансировку нагрузки с помощью Nginx и реализовали необходимые интеграции с другими системами.
Далее мы решали проблему с долгим оказанием услуг. Раньше у нас была блокирующая обработка транзакций, когда процессы в финансовом учёте блокируют оказание услуги до подтверждения.
Мы с пользователя взяли деньги, но не можем ему сразу начать оказывать услугу. Сперва нам нужно было дождаться, пока сформируется чек, разложатся проводки в финансовом учёте и появится запись в истории операций. Поэтому нам нужно было перейти на неблокирующую обработку, то есть сделать так, чтобы пользователь нажал оплатить, и для него сразу всё заработало, а не заставлять его ждать завершения всех фоновых процессов в учёте.
Пересмотр процесса оплаты и учёта позволил преобразовать блокирующую обработку в неблокирующую. Разделение процессинга позволило нам сделать так, чтобы пользователь получал услугу сразу после подтверждения оплаты от банка, не дожидаясь завершения всех фоновых процессов, которые мы обязаны по закону сделать.
Итог
Весь проект мы делали около трех лет. Микросервисы в новой архитектуре написаны на Golang, PHP больше не используется.
Разделение биллинга на четыре домена позволило структурировать и упростить всю систему. Один большой запутанный клубок превратился в изящную структуру с чётко определёнными зонами ответственности.
Когда мы отказались от бизнес-логики в системе и перестали быть по сути совладельцами продуктов, мы перестали быть боттлнеком – бутылочным горлышком из-за которого запуски продуктов происходили медленно.
Сегодня благодаря внедрению Temporal система умеет самостоятельно восстанавливаться после сбоя и все свои процессы доводить до нужного состояния.
Система написана так, что даже если у нас что-то сломалось, то после восстановления системы операции завершатся, а пользователь об этом даже не узнает. В итоге это стало нашей фичей.
Переход на неблокирующую обработку транзакций ускорил оказание услуги, не дожидаясь выполнения всех фоновых операций в процессинге в реальном времени.
Так, три глобальных изменения позволили нам сократить срок вывода новых платных продуктов с 30 до 5 дней.
Запуск продукта ускорился в шесть раз, а мы получили возможность сфокусироваться на дальнейшем развитии и масштабировании платформы.
Где применяется
Платформа обрабатывает трафик в части транзакционных продуктов:
Аренда спецтехники.
Краткосрочная аренда недвижимости.
Профессиональные услуги.
Узнать бол��ше о задачах, которые решают инженеры AvitoTech, можно по этой ссылке. А вот тут мы собрали весь контент от нашей команды — там вы найдете статьи, подкасты, видео и много чего еще. И заходите в наш TG-канал, там интересно!
