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

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

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

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

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

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

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

Понадобилось снимать из Node.js-приложения метрики по событиям. Например, инкрементить метрику при успешном ответе и всё в таком духе.

В моём распоряжении были Zabbix и Grafana.

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

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

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

Модуль вообще-то для Prometheus, но и нам подходит.

Суть сводится к тому, что метрики передаются по шине pm2 в процесс агента и дальше экспортируются в plain-text или JSON.

Сегодня поговорим о деплое без даунтайма (zero downtime deployment) в Node.js-приложении.

Чтобы это стало возможным, приложение должно работать в дочернем процессе. Например, через PM2 или ts-node-dev.

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

process.send(“ready”)

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

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

process.on(“SIGINT”, () => {
  this.connection.close(); // For example, we will close the current connection to AMQP and stop accepting new messages.
  setTimeout(() => {
    process.exit()
  }, 5000) // Let's wait for 5 seconds until the current processes are completed.
})

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

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

• Новое приложение, запущенное в дочернем процессе, стартует и сообщает «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)
     })
  }

}

В этой небольшой статье не будет ничего про dialplan Asterisk. Речь пойдёт про ARI - гибкий интерфейс для управления Asterisk.

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

Работа с ARI строится так: получаем события от Asterisk по WebSocket, обрабатываем их и создаём новые через HTTP REST API в сторону ARI.

StasisStart

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

Упрощённый сценарий обычного звонка

1. Получили от ARI событие StasisStart о том, что создан канал A.
2. Создали канал B с эндпоинтом в сторону SIP-пира или локального прокси (пример: SIP/MY_PEER/331234567890).
3. Объединили канал A из шага 1 и канал B из шага 2 в бридж.
4. Запустили dial в канал B.
5. Дождались от ARI события ChannelStateChange по каналу B. Если состояние ‘Up’, делаем answer в канале A, и начинается разговор.
6. При получении события ChannelHangupRequest по каналу A или B завершаем звонок.

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

Может понадобиться хранить данные о ходе звонка, включая CDR, по каждому каналу.

В качестве хранилища я бы рекомендовал Redis: при высоком CPS интенсивные запросы в базу могут сильно нагрузить диски и просадить производительность.

Оптимизация

Чтобы ARI-приложение нормально работало при высоком CPS, я бы советовал свести к минимуму запросы в реляционную базу. У меня на практике запросы шли только для небольшой логики лимитов при инициализации звонка и для записи CDR после его завершения. Всё остальное - в Redis.

Ещё рекомендую с точки зрения инфраструктуры держать ARI-приложение на одном хосте с Asterisk, чтобы снизить задержки.

Нагрузочный тест

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

200 параллельных звонков в сумме съели около 5% CPU. Все звонки завершились успешно, CDR записались.