Системные требования приложения Биллинг
Нефункциональные требования, которые распространяются на весь продукт
1. Операционная среда и окружение
1.1. Client MangoBilling (java-приложение)
1.1.1. Требования к аппаратному обеспечению (включая настройки)
  • Процессор: не ниже Pentium R 2,9 GHz
  • Оперативная память: не ниже 2Гб
  • Жесткий диск: не менее 100 МБайт свободного места
  • Разрешение экрана: 1920x1080
1.1.2. Требования к программному обеспечению (включая настройки)
  • Операционная система: Windows XP и старше
  • Виртуальная машина: JRE 1.6
  • Браузер: Chrome 41+
1.1.3. Требования к СПД (включая настройки)
  • Требования к сети передачи данных (соответствует требованиям T-REC-Y.1541 Class 5):
  • Без определения параметров: потери пакетов, задержки и джиттер
  • Ширина канала (на одно рабочее место):
  • входящий трафик: от 256 Кбит/с
  • исходящий трафик: от 50 Кбит/с
  • по результатам исследования #63305 (Анализ объема трафика Billing).
1.1.4. Требования к версионной совместимости
1. При первом запуске приложения МБ происходит сравнение версии клиента с версией конфигурационного файла сервера приложений. Если версии не совпадают, то ошибка, если версии совпадают, то запоминается время сравнения версии, клиента запускается.
2.
1) При выполнении каждого запроса (команды) клиент МБ проверяет, что разница между текущим временем и временем последнего сравнения версии не превышает некоторого параметра (по умолчанию 30 минут), если время не превышено, то команда выполняется.
2) Если время превышено, то происходит сравнение версии клиента и сервера приложений. Если версии совпадают, команда выполняется, если версии не совпадают, то пользователю выдается сообщение: "Ваша версия МБ устарела, пожалуйста, перезапустите МБ".
3) В окне с сообщение доступна только одна кнопка "OK", остальной интерфейс МБ заблокирован. При нажатии на OK клиент МБ закрывается.
3. Для подсчета времени используется timestamp без учета тайм-зон.
1.2. Системное ПО
1.2.1 Версии JAVA и Tomcat
1. Приложения МБ должны корректно работать в следующем окружении: Java 1.8 и Tomcat 8
2. На пользовательских машинах для всех пользователей клиента МБ нужно установить Java 1.8.
3. Выполнить переход на Java 1.8 модулей: mb_web_crm, фхд.
4. Выполнить переход на Java 1.8 модулей: paymasterdirect . Для совершения автоплатежей paymaster необходимо использовать протокол TLS 1.2.
1.2.2 PGbouncer
1. Необходимо настроить Pgbouncer с poolmode = transction, для уменьшения количества коннекшенов к БД биллинга.
2. Внедрить PGbouncer в серверные модули МБ.
2. Доступность
2.1. Управление нагрузкой на БД
ТУ стриминг репликация
1. Размещение команд МБ на различных серверах БД: master, short_lag, long_lag приведено в файле команды (1).xlsx
2. Перенести команды с londiste (src = londiste , dest_fin <> short+long) в соответствии с таблицей команды (1).xlsx.
3. Команда, которая не может выполнится на слейве, по причине начала обновления слейва, должна запускаться несколько раз.
Повторные команды на short посылаются 1 раз в 1 секунду, на Long 1 раз в 1 минуту.
Если время выполнения запроса на short было более половины лага, то второй раз запрос не посылается на short, а отправляется на long.
Повторные команды на long посылаются в течении половины лага.
4. Команды, направляемые на различные слейвы в зависимости от запрашиваемых данных.
StatisticsTrafficGet при запросе данных за текущий день направляется на short_lag, в остальных случаях на long_lag.
StatisticsRegionTrafficGet при запросе данных за текущий день направляется на short_lag, в остальных случаях на long_lag.
SalesComplexStatisticsGet при запросе данных за текущий месяц направляется на short_lag, в остальных случаях на long_lag.
TBD При отправке данных команд на long_lag c short_lag выводить пользователю в интерфейсе сообщение: "В связи с большим объемом запрашиваемых данных в отчет могут не попасть данные за последнее время (от нескольких минут до 6 часов)"
5. Для каждой команды необходимо хранить в БД source - наименование сервера БД, на котором она выполняется (master, short_lag, long_lag, londiste).
6. Время отставания (lag) для hort_lag, long_lag должны хранится в БД.
7. В случае, если команда выполняется долго необходимо реализовать прелоадер, который появляется на время выполнения команды. Визуальный вид прелоадера должен позволять однозначно идентифицировать на каком из серверов выполняется команда (master, short_lag, long_lag, londiste), само наименование сервера в прелоадере выводится не должно.
8. Необходимо реализовать метод, который позволяет обновить source серверных команд, при изменение значения в БД. Доступ к методу реализовать в виде url ссылки.
9. TBD По каждой команде журналировать факт переключений ее выполнения с short на long, факт принципиального невыполнения команды из-за накатки логов, продолжительность времени команды до ее отмены.
10. Третий этап: Перенести команды с londiste в соответствии с указанием в столбце dest_server файла: 2016-07-128Статистика по командам только londiste (1) (1).xls
3. Безопасность
4. Производительность
Ожидаемое количество пользователей клиента МБ
1. Общее число пользователей клиента МБ: РФ - до 1000 активных пользователей (не считая заблокированных), Германия - до активных 200 пользователей (не считая заблокированных). Примечание: Рост от начала 2016 года примерно в 2 раза
2. Одновременная работа с приложением МБ (запущен клиент МБ): РФ - до 500 пользователей, Германия - до 100 пользователей.


Made on
Tilda