Микросервис CDR

Задание

Любые входящие или исходящие звонки абонентов нашего оператора фиксируются в CDR файле, который собирается на коммутаторе. Данные поступают в виде записей типа:

• тип вызова (01 - исходящие, 02 - входящие);
• номер обслуживаемого абонента;
• номер абонента, с которым осуществлялась связь;
• дата и время начала звонка (ISO 8601);
• дата и время окончания звонка (ISO 8601);
• разделитель данных – запятая;
• разделитель записей – перенос строки;
• данные обязательно формируются в хронологическом порядке;
• в рамках задания CDR может быть обычным txt/csv;

Каждые 10 записей составляют CDR, который отправляется на тарификацию в сервис BRT.

При этом, если звонок начинается до полуночи, а заканчивается после, коммутатор генерирует по такому звонку 2 записи в CDR.

Пример фрагмента CDR:
02,79876543221,79123456789,2025-02-10T14:56:12,2025-02-10T14:58:20

01,79996667755,79876543221,2025-02-10T10:12:25,2025-02-10T10:12:57

Задача 1

Напишите сервис, эмулирующий работу коммутатора, т.е. генерирующий записи действий абонента и собирающий из них CDR файлы.

Условия

1. Установленный список абонентов (не менее 10) хранится в локальной БД (H2); данные о звонках помещаются в соседнюю таблицу этой БД.
2. CDR собирается из записей, которые могут генерироваться параллельно (TODO).
3. На один месяц может приходиться случайное количество CDR файлов. Тарифицируемый период в рамках задания — 1 год.
4. Данные в CDR идут не по порядку, т.е. записи по одному абоненту могут быть в разных частях файла.
5. Хронология звонков при этом должна обязательно соблюдаться.
6. Количество и длительность звонков определяется случайным образом.
7. CDR, по мере генерации, асинхронно отправляются в сервис BRT через брокер сообщений.

Решение

Микросервис cdr представляет собой эмуляцию работы реального коммутатора. Его задачи:

1. Сгенерировать 10 пользователей и сохранить в ин-мемори БД H2.
2. Сгенерировать n количество CDR записей и сохранить в ин-мемори БД H2.
3. Каждые 10 сгенерированных записей отправлять в брокер сообщений RabbitMQ для обработки сервисом BRT.

Сообщения посылаются в формате JSON.

Генерация данных

Генерация данных происходит в момент обновления Spring контекста — когда он собран.

• Генерация пользователей: Реализовано в com.mobile.network.report.service.impl.CustomerServiceImpl#generateCustomers.
• Генерация CDR: Реализовано в com.mobile.network.report.service.impl.CDRRecordGeneratorServiceImpl#generateCDRRecords.

Настройка RabbitMQ

Настройка RabbitMQ (exchange, queue, binding и routing key) автоматически происходит при старте приложения благодаря конфигурации в классе RabbitMQConfiguration. Это позволяет использовать RabbitTemplate для отправки сообщений без дополнительных настроек, уже полностью сконфигурированным.

Алгоритм генерации CDR

CDR записи генерируются по переданному году. Алгоритм:

1. Получаем все номера пользователей из базы.
2. Рандомизируется количество звонков в год от 100 до 599 (totalCalls).
3. Вычисляется количество секунд в году: totalSecondsInYear = endOfYear - startOfYear.
4. Вычисляется средний интервал между звонками: averageIntervalSeconds = totalSecondsInYear / totalCalls.
5. В цикле, начиная с начала года:
6. Проверяется список для отправки в брокер; если в нем ровно 10 записей, отправляем их в брокер, список очищаем (временное решение).
7. Вычисляется интервал, к среднему добавляется случайное отклонение.
8. Проверяется, что время не вышло за границы года.
9. Генерируется одиночная запись CDRRecordDto.
10. Получаем два случайных номера; если они совпадают, присваиваем второму новый номер, пока они не будут разными.
11. Рандомизируем CallType (01 или 02).
12. Рандомизируем длительность разговора от 10 до 600 секунд.
13. Длительность звонка вычисляется как сумма начала звонка и длительности разговора.
14. Собранный объект добавляется в список для последующего сохранения.
15. Собранный объект добавляется в список для последующей отправки в брокер.
16. После цикла проверяется, есть ли в списке для отправки в брокер еще записи; если есть — отправка в брокер (на случай генерации не кратного 10 количеству записей).

База данных

В качестве базы используется H2, работа с ней происходит посредством Spring JPA.

Используемые библиотеки

• MapStruct: Для уменьшения шаблонного кода генерации мапперов Message <-> DTO <-> Entity.
• Lombok: Для уменьшения бойлерплейт кода.

Тестирование

1. Скачать джарник из релиза, и докер компоуз
2. docker compose up в директории где лежит docker-compose.yml
3. Стартануть приложение java -jar report-1.0.2-SNAPSHOT.jar
4. Проверить по http://localhost:15672 что в реббит пришло кол-во сообщений равное кол-ву записей в бд / 10 + 1 http://localhost:8080/h2-console

Доступы:

H2 UI:

• username: user
• password: password

RabbitMQ UI:

• username: test
• password: test

5. Проверить что они пришли в нужный exchange (cdr.report.send), queue (cdr.queue) и имеют верный routing key (cdr_record)