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

В процессе изучения пишу свой pet-проект на github, в котором есть интеграция с OpenAI (ChatGPT) и TTS сервисом. Планирую еще сделать интеграцию с каким нибудь AI для генерации изображений (например dreamstudio.ai).

Так-же пришлось написать маленький срипт на Python с использованием FastAPI и Silero AI для TTS запросов. Бот умеет отвечать голосом, зачитывая ответы с ChatGPT. Для этого пришлось поднять отдельный сервис.

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

Кстати, превью для этой записи, я тоже сгенерировал на dreamstudio.ai

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

Из подручных средств был забикс и графана.

Оказалось что для nodejs есть модуль prom-client который умеет экспортировать метрики, но вот незадача — с pm2 как и другие модули он работать не умеет.

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

Исправляем упущение: pm2-prom-client

Модуль в принципе для prometheus, но нам он тоже подошел

Вся его суть сводится к передачи по шине pm2 метрик в агентский процесс с последующим экспортом в plain-text либо json

Сегодня поговорим о деплое с нулевым даунтаймом в NodeJs приложении.

Для того что бы это было возможным, ваше приложение должно быть запущено в child process. Например используйте PM2 / ts-node-dev

Итак:

Первое что нам нужно сделать, это сообщить о том, что новый (задеплоенный) процесс готов принимать на себя работу передеплоемого приложения. Для этого необходимо вызвать

process.send(“ready”)

В вашем приложении, после того как все необходимые зависимости перейдут в состояние готовности. Например коннект с базой установится и т.п.

Так же в нашем приложении нужно добавить логику, по завершению всех текущих операций при получении сигнала терминации (SIGINT)

process.on(“SIGINT”, () => {
  this.connection.close(); // Например закроем текущие соединение с AMQP и перестанем принимать новые сообщения
  setTimeout(() => {
    process.exit()
  }, 5000) // Подождем 5 сек пока завершаться текущие процессы
})

Запуская такое приложение, например при помощи ts-node-dev, вы можете заметить что после control+c приложение завершается не сразу, а через 5 минут.

Что произойдет:

• Новое приложение, запущенное в child process запускается и сообщает ready, после чего начинает бизнес логику
• одновременно с этим старому процессу посылается SIGINT и оно переходит в режим завершения работы и финализазции, после чего уничтожается.

Пример

class App {
  private isOnline = true

  public start() {
    console.log(“Started”)
    this.restartListener()
    this.loop()
  }

  private loop() {
    if (!this.isOnline) return
    console.log(“Some business logic like redis/sql/amqp and others operation”)
    this.loop()
  }

  private restartListener() {
     if (typeof process.send !== “function”) return

     process.send(“ready”)
     process.on(“SIGINT”, () => {
       this.isOnline = false
       setTimeout(() => {
         process.exit()  
       }, 3000)
     })
  }

}

В этой небольшой статье ничего не будет про план нумерации астериска. Речь пойдет про ARI — гибкий интерфейс управления Астериском.

Как только в астериск приходит инвайт, и вызов уходит в нашу программу (Stasis) мы получаем возможность для низкоуровневого построения звонка.

Взаимодействие с ARI происходит через прием событий по websocket от астериска, обработку и создания новых событий через HTTP REST API в сторону ARI.

StasisStart

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

Упрощенная схема обычного звонка

1. Получили инвайт (StasisStart) событие от ARI, что сигнализирует о созданном канале A
2. Создали канал B с эндпоинтом в сторону сип пира, либо в локальный прокси. (пример. SIP/MY_PEER/79001231122)
3. Канал А из п.1 и B из п.2 объядинили в bridge
4. Сделали дозвон (dial) в канал B
5. Подождали ARI событие ChannelStateChange для канала B. И в случае если state — ‘Up’, запускаем ответ в канал A и звонок диалог начинается.
6. При получении события ChannelHangupRequest для канала A либо B разрушаем звонок.

Сессия звонка

Созданных каналов может быть множество и есть необходимость знать, к каким звонкам относятся события по каким каналам. Поэтому при создании каналов в сторону другого абонента, можно записывать в стор для созданного канала указатель на id канала A, а в сторе для канала A хранить все данные, включая CDR и прочую техническую информацию.

В качестве хранилища я бы рекомендовал использовать redis, так как при больших cps и интенсивных запросах в базу данных может образоваться существенная нагрузка на жесткие диски и просесть производительность.

Оптимизация

Для оптимальной работы вашего ARI приложения под большим cps, я бы рекомендовал свести к минимуму запросы в реляционную базу данных. В своей практике я использовал запросы для небольшой ограничительной логики в момент инициализации звонка и для записи CDR после окончания звонка. Все остальные запросы выполняются в рэдис.

Тест производительности

Для тестирования я использовал консольную утилиту baresip, инициировав баш скриптом 200 дозвонов по пулу тестовых номеров, которые отвечают tt-monkeys.

200 параллельно запущенных звонков сумарно потребили около 5% загрузки на CPU. Все звонки завершились успешно, включая записанные CDR.