Архитектура биллинга: фундамент, на котором нельзя экономить

Основная статья: Биллинг

Любая коммерческая компания в какой-то момент начинает принимать деньги от пользователей за свои услуги или товары. Многие при этом принимают простейшее решение – заключают договор с агрегатором платежей, который берет все заботы на себя. Однако с ростом аудитории и расширением рынка в новые страны возникает необходимость подключать новые методы оплаты, работать с новыми валютами, уметь гибко управлять ценами и скидками, работать с возвратом денег, делать финансовые сверки и отчитываться перед аудиторами. С инженерной точки зрения это означает экспоненциальный рост сложности системы биллинга и возрастающую зависимость от него внешних систем – финансистов и бюджетирования, бизнес-аналитики, маркетинга, службы поддержки клиентов. Как выстроить биллинг, который будет работать безупречно, рассказывает Engineering Manager в международной компании Wheely Анатолий Рябов. В качестве разработчика, а позже менеджера он создал и внедрил ряд сервисов, в том числе систему финансовых сервисов, которые позволили компании выйти на новые рынки, повысить доходность бизнеса и упрочить репутацию среди клиентов.

Анатолий Рябов: «Несмотря на привлекательность быстрых и простых решений `в лоб`, биллинг лучше сразу разрабатывать, ориентируясь на лучшие практики. Опираясь на свой опыт работы в различных компаниях и анализ биллинговых систем, я кратко расскажу о том, какие требования должны применяться к системе биллинга, а также о нюансах разработки и проектирования архитектуры биллинга».

Что такое биллинг крупной компании?

Биллингом обычно называют «комплекс процессов и решений на предприятиях связи, ответственных за сбор информации об использовании телекоммуникационных услуг, их тарификацию, выставление счетов абонентам, обработку платежей» (Wikipedia). Мы же будем говорить об электронном биллинге – системе приема и передачи электронных платежей, управления внутренней экономикой и платными сервисами, хранящей всю историю о платежных операциях и сопутствующих инструментах.

Отмечу, что биллинг не занимается непосредственным оказанием услуг, а только сигнализирует внешним системам о том, что услугу надо включить или выключить.

Разработка

Требования к системе

К биллингу предъявляется ряд конкретизированных и точных требований:

1. Безопасность кода и информации (Security)

• a. Разделение уровней доступа к задачам, коду и данным
• b. Гарантирование неизменности кода в production-среде
• c. Создание безопасных сред разработки и эксплуатации
• d. Хранение журнала операций для отслеживания активности и аудита

2. Отказоустойчивость (Fault Tolerance)

• a. Реализация принципа graceful degradation – отказ одной подсистемы не должен влиять на работоспособность остальных
• b. Возможность быстрого восстановления после отказа любой подсистемы
• c. Резервирование оборудования и данных для обеспечения непрерывности работы при любых обстоятельствах
• d. Автоматическое перенаправление транзакций, переключение на резервные базы данных, а также управление нагрузкой и балансировка запросов

3. Надежность (Reliability)

• a. Гарантирование исполнения пользовательского сценария и списания средств
• b. Гарантирование отсутствия дубликатов платежей
• c. Обеспечение целостности данных
• d. Ведение подробного журнала всех операций с заказами и платежами
• e. Возможность восстановления состояния счетов на любую дату и время

4. Масштабируемость (Scalability)

• a. Реализация бесшовной горизонтальной и/или вертикальной масштабируемости
• b. Возможность развертывания в различных зонах доступности (AZs)

5. Производительность (Performance)

• a. Оптимизация времени отклика и скорости обработки запросов, эффективное использование аппаратных ресурсов с учетом того, что обработка платежей почти никогда не происходит в реальном времени

6. Мониторинг (Traceability)

• a. Логирование и мониторинг всех API-команд, системных активностей, состояния внешних партнеров и внутренних систем
• b. Использование автоматических систем обнаружения аномалий

7. Управление конфигурациями (Configurability)

• a. Централизованное управление конфигурациями
• b. Управление изменениями в конфигурации без прерывания работы системы

При разработке необходимо учесть ряд факторов, которые могут быть не сразу очевидны:

• Одним из ключевых аспектов является наличие множества внешних связей. Это включает как интеграции с партнерами, в том числе платежные системы и инструменты, так и внутренние связи в рамках продукта. Это накладывает очень много ограничений и требует постоянной актуализации кода.
• В связи с этим необходимо быть готовым к возможным погрешностям в расчетах. Например, платежи, которые кажутся успешно подтвержденными платежной системой, могут на самом деле не быть проведенными, и вы узнаете об этом только после подсчета поступивших на банковский счет средств. Многие платежные системы проводят расчеты с задержкой в несколько месяцев, удерживают комиссии и штрафы и используют собственные внутренние курсы валют. Поэтому необходимы регулярные сверки между вашей биллинговой системой и PSP.
• Чем больше платежных систем вы поддерживаете, тем сложнее становится поддержка. Агрегаторы могут менять API без предупреждения, ломаться и обновляться в неподходящее время, выдвигать неожиданные требования и вести себя непредсказуемо. Это может привести к большому количеству ошибок и проблем, которые необходимо быстро обнаруживать и исправлять. Рассмотрите возможность унификации работы с агрегаторами с самого начала, чтобы избежать проблем в будущем. Ваш внутренний API должен скрывать различия в API партнеров.
• Если вы планируете международную экспансию, учтите, что в разных странах регуляторы могут иметь свои требования к различным аспектам – от дизайна и размеров шрифтов в платежных формах до запрашиваемых документов и размера штрафа за возврат денег пользователю. В дополнение к законам о защите персональных данных во многих юрисдикциях существуют отдельные требования к организациям, занимающимся обработкой платежей.

Особенности процесса разработки

• Придерживайтесь принципа «меньше, но лучше». Качество имеет больший приоритет, чем количество и скорость. Время, потраченное на планирование, всегда оказывается более ценным, чем время, затраченное на устранение последствий катастрофы на продакшене.
• Безопасность, отказоустойчивость, надежность – это минимум основополагающих принципов, которые определяют все решения разработчиков в повседневной работе. В идеале даже на уровне написания кода можно следовать всем семи требованиям, описанным выше.
• Защита информации на всех уровнях – это приоритет. Это включает в себя серверы приложений и данные в DMZ, строгий контроль доступа к данным и коду, а также разделение кода/приложений, конфигурации и логинов/паролей/ключей к API.
• Тщательное тестирование всех компонентов биллинга и максимальное покрытие кода тестами обеспечивают надежность и стабильность системы.
• Некоторые компоненты системы могут иметь свою собственную систему деплоя, учитывающую повышенные требования к безопасности.
• Большую часть рабочего времени команда разработки будет заниматься поддержкой изменений API и анализом последствий сбоев. Это важно учитывать при формировании команды.

Архитектура

Техническая реализация и инфраструктура

В самых общих чертах схема взаимодействий системы биллинга выглядит примерно так:

Анатолий Рябов

Но чаще, конечно, она выглядит как-то так:

Анатолий Рябов

Архитектура опирается на те же основные принципы – безопасность, отказоустойчивость, надежность. Исходя из них:

• Система биллинга должна быть максимально изолирована от внешнего мира, находясь в демилитаризованной зоне (DMZ). Все запросы от партнеров, приложений и сайтов должны поступать на серверы вне биллингового кластера, где проводится первичная проверка и определение валидности запроса. В Интернет запросы должны идти через прокси-серверы (gateways).
• Биллинговый кластер должен включать не только серверы приложения, но и базы данных, отдельные инстансы систем мониторинга и аналитических систем. Связь с другими компонентами продукта должна осуществляться по API или через систему событий
• Для обработки банковских карт следует использовать сервер, находящийся внутри High Security части DMZ, соответствующий стандартам PCI DSS. Это гарантирует, что никто не сможет получить доступ к его коду и данным без явного взаимодействия с несколькими сотрудниками компании.

В биллинговый кластер обычно включаются серверы приложения, базы данных и отдельные инстансы систем мониторинга и аналитических систем.Игорь Лейпи, ГК Softline: Объем поставок российских операционных систем в ближайшие годы увеличится как минимум вдвое 3.4 т

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

Базы данных в биллинговом кластере обычно используются для хранения пользовательских данных и информации о платежах. Для обработки больших объемов данных и улучшения производительности может быть использовано шардирование. Данные о том, где искать информацию о пользователе или платеже, могут храниться отдельно в подготовленных Lookup-ах.

Отдельные инстансы систем мониторинга и аналитических систем обычно используются для отслеживания состояния биллингового кластера и анализа его работы. Это помогает вовремя обнаруживать и устранять проблемы, а также оптимизировать работу системы.

Биллинговый кластер должен быть гибким и позволять динамически добавлять или удалять серверы в зависимости от нагрузки на систему.

Типовая схема биллингового кластера может выглядеть следующим образом:

Анатолий Рябов

Внешние взаимодействия

Асинхронная архитектура (event-based) позволяет системе биллинга обрабатывать большое количество внешних запросов и операций параллельно и независимо друг от друга. Это уменьшает время отклика и обеспечивает более эффективное использование ресурсов. Кроме того, асинхронность позволяет системе продолжать работу даже в случае сбоев или задержек в отдельных компонентах.

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

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

Автор: Анатолий Рябов, руководитель команд разработки крупной международной компании