Биллинговая система - программный комплекс, осуществляющий учет объема потребляемых абонентами услуг, расчет и списание денежных средств в соответствии с тарифами компании. Не обязательно бежать писать свою билинговую систему после прочтения этого материала, вполне возможно, что эта информация поможет вам сориентироваться и выбрать для себя биллинг из уже предлагаемых решений (как коммерческих, так и некоммерческих), которых уже понаделано достаточное количество. Однако, зная извечную склонность системных администраторов (и линуксоидов в особенности) к изобретению велосипедов, не исключено, что кто-то на базе этих рекомендаций создаст биллинг своей мечты. Весомыми аргументами в пользу разработки собственного биллинга являются цена коммерческих аналогов и несовершенство некоторых широко распространенных решений среднего ценового диапазона. Итак, постараемся подумать над тем, как создать биллинг на базе Linux и open source ПО.
Задачи
Чтобы спланировать внутреннюю архитектуру полнофункциональной биллинговой системы, в первую очередь нужно выделить задачи, которые она должна решать.
* сбор информации о потребляемых услугах (аккаунтинг)
* аутентификация и авторизация абонентов
* контроль денежных средств на счетах абонентов и списание средств в соответствии c действующей тарифной сеткой
* пополнение счетов абонентов
* внесение изменений в тарифы
* предоставление статистики по операциям (клиентская и операторская части)
Кстати, не стоит путать аутентификацию и авторизацию - это разные понятия. Так, аутентификация - процедура идентификации пользователя (обычно сводящаяся к проверке указываемых им данных на совпадение с хранящимися в системе). Авторизация - процесс принятия решения о правомерности доступа пользователя к какому-то конкретному ресурсу (например, к файлу на диске или к определенной услуге связи).
Схема системы
Исходя из задач и запросов бизнеса, можно набросать схему системы. Чтобы не обсуждать какого-то абстрактного сферического коня в вакууме, будем рассматривать типовой пример оператора связи, продающего трафик абонентам.
* коллекторы информации о потребленных услугах
* система аутентификации абонентов
* ядро (бизнес-логика)
* многоуровневая БД
* модуль авторизации
* модуль анализа типов трафика (локальный, пиринговый, etc)
* модуль разграничения доступа
* модуль статистики
* административный интерфейс для ручного управления абонентами
* интерфейс управления счетами абонентов и тарифами для отдела продаж
Основной принцип проектирования системы - строгая модульность, которая в последствии позволит легко модернизировать отдельные компоненты системы в зависимости от меняющихся задач бизнеса. Как в любой сложной системе, придется искать компромисс между сверхуниверсальным комбайном и узкоспециализированным решением.
Коллекторы
Услуги могут быть разными (например - VPN-доступ, dial-up пул, обычный неинкапсулированный трафик, Proxy, VoIP, etc), надо обеспечить доставку ядру системы в единообразном виде информации о том, какой тип услуги, какой абонент, в каком объеме и в какое время потребил. В худшем случае для каждого из типов услуг прийдется разрабатывать свой коллектор, но если повезет - что-то удастся унифицировать. Технологии, которые могут помочь при создании коллекторов - SNMP, Radius, NetFlow.
Многоуровневая база данных
Многоуровневая БД нужна для того, чтобы не работать все время с массивами максимально детальной информации, т.к. это значительно может снизить быстродействие всей системы. Логично выделить 3 уровня:
1. максимально детализированная информация без какой-либо обработки
2. классифицированная и первично агрегированная информация
3. оперативная информация
База первого уровня может понадобиться для разрешения спорных моментов с клиентами. Важно сохранять ее в исходном виде, т.к. возможно будет необходимо постфактум произвести перерасчет выставленных к оплате счетов с учетом скорректированных тарифов или, например, уточненных границ сетей, по которым делится трафик. Не для каждого сервиса можно получить детализированную информацию о соединениях, но к этому надо стремиться. По крайней мере, при подсчете трафика через Web Proxy это решается автоматически, использование NetFlows тоже позволяет делать полную детализацию. Минусом является значительный объем, требующийся для хранения всех этих данных. Однако, т.к. эта информация нужна не очень часто, ее более логично хранить в виде обычных файлов, а не в базе - это уменьшит нагрузку на ваш сервер БД и является более компактным способом хранения.
База второго уровня компактнее, чем первая, поэтому ее можно хранить за более продолжительный период времени. Например, после классификации трафика можно не хранить информацию о локальном трафике, если за него не взимается плата. Также с большой долей вероятности можно считать одним соединением несколько соединений с одним и тем же хостом, произошедшие в приблизительно одно время (типичная ситуация с многопоточными сетевыми клиентами).
Похожие страницы:
