Содержание |
Основная статья: Биллинг
Любая коммерческая компания в какой-то момент начинает принимать деньги от пользователей за свои услуги или товары. Многие при этом принимают простейшее решение – заключают договор с агрегатором платежей, который берет все заботы на себя. Однако с ростом аудитории и расширением рынка в новые страны возникает необходимость подключать новые методы оплаты, работать с новыми валютами, уметь гибко управлять ценами и скидками, работать с возвратом денег, делать финансовые сверки и отчитываться перед аудиторами. С инженерной точки зрения это означает экспоненциальный рост сложности системы биллинга и возрастающую зависимость от него внешних систем – финансистов и бюджетирования, бизнес-аналитики, маркетинга, службы поддержки клиентов. Как выстроить биллинг, который будет работать безупречно, рассказывает 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 и анализом последствий сбоев. Это важно учитывать при формировании команды.
Архитектура
Техническая реализация и инфраструктура
В самых общих чертах схема взаимодействий системы биллинга выглядит примерно так:
.jpg)
Но чаще, конечно, она выглядит как-то так:
.jpg)
Архитектура опирается на те же основные принципы – безопасность, отказоустойчивость, надежность. Исходя из них:
- Система биллинга должна быть максимально изолирована от внешнего мира, находясь в демилитаризованной зоне (DMZ). Все запросы от партнеров, приложений и сайтов должны поступать на серверы вне биллингового кластера, где проводится первичная проверка и определение валидности запроса. В Интернет запросы должны идти через прокси-серверы (gateways).
- Биллинговый кластер должен включать не только серверы приложения, но и базы данных, отдельные инстансы систем мониторинга и аналитических систем. Связь с другими компонентами продукта должна осуществляться по API или через систему событий
- Для обработки банковских карт следует использовать сервер, находящийся внутри High Security части DMZ, соответствующий стандартам PCI DSS. Это гарантирует, что никто не сможет получить доступ к его коду и данным без явного взаимодействия с несколькими сотрудниками компании.
В биллинговый кластер обычно включаются серверы приложения, базы данных и отдельные инстансы систем мониторинга и аналитических систем.Витрина данных НОТА ВИЗОР для налогового мониторинга 
Серверы приложений, исполняющие биллинговый код, как правило, отделены от других серверов для обеспечения безопасности и надежности. Они могут быть разделены на веб-серверы и скриптовые серверы, что позволяет сохранить работоспособность «фронта» при наличии ошибок в процессинге и наоборот.
Базы данных в биллинговом кластере обычно используются для хранения пользовательских данных и информации о платежах. Для обработки больших объемов данных и улучшения производительности может быть использовано шардирование. Данные о том, где искать информацию о пользователе или платеже, могут храниться отдельно в подготовленных Lookup-ах.
Отдельные инстансы систем мониторинга и аналитических систем обычно используются для отслеживания состояния биллингового кластера и анализа его работы. Это помогает вовремя обнаруживать и устранять проблемы, а также оптимизировать работу системы.
Биллинговый кластер должен быть гибким и позволять динамически добавлять или удалять серверы в зависимости от нагрузки на систему.
Типовая схема биллингового кластера может выглядеть следующим образом:
.jpg)
Внешние взаимодействия
Асинхронная архитектура (event-based) позволяет системе биллинга обрабатывать большое количество внешних запросов и операций параллельно и независимо друг от друга. Это уменьшает время отклика и обеспечивает более эффективное использование ресурсов. Кроме того, асинхронность позволяет системе продолжать работу даже в случае сбоев или задержек в отдельных компонентах.
Каждое внешнее взаимодействие или запуск скрипта сопровождается генерацией события, которое затем обрабатывается независимо. Это позволяет изолировать ошибки и сбои, предотвращая их распространение по всей системе. Например, поступающая нотификация записывается на диск в сыром виде и может быть перенаправлена в случае сбоев. Это обеспечивает сохранность данных и возможность их повторной обработки. Кроме того, каждое сообщение обрабатывается независимо, что позволяет изолировать код каждого конкретного метода оплаты и устранять ошибки без воздействия на всю систему.
Описанные мной подходы и принципы могут не только подсветить ключевые аспекты при разработке биллинга, но и предоставить основу, на которую можно опереться при построении архитектуры для сложных биллинговых систем.
Автор: Анатолий Рябов, руководитель команд разработки крупной международной компании
