Як влаштована система SMSDirect

    image
 
Здравствуйте, хабражітелі!
 
Прочитавши тут про порівнянні смс-сервісів для розсилок , ми вирішили розповісти вам про свій досвід побудові подібної системи, яка вірою і правдою служить нам в i-Free кілька років і постійно допрацьовується і вдосконалюється. Сподіваємося, наш досвід буде вам корисний. Загалом, тим, кому цікаво, прошу під кат.
 
 
 

Що являє собою наша система смс-розсилок?

Основне завдання системи SMSDirect — розсилка або відправка одиночних смс-повідомлень.
 
 Frontend
Сервіс представляє цілий комплекс, вершиною айсберга якого є клієнтська частина — сайт. Це точка входу в систему. Тут є особистий кабінет (якщо ти хочеш завантажити бази розсилок вручну), а також набір методів API для створення розсилок і відправки повідомлень.
Для входу в систему клієнт повинен зареєструватися, а далі скористатися або набором методів API, або інтерфейсом особистого кабінету. Тут реалізуються такі функції: завантаження і зберігання користувацьких баз клієнта (абонентських списків), а також створення і керування розсилками за цими списками (або введеними вручну номерам).
 
 Backend
Що складають системи: рішення, здатне обробити великий обсяг однотипних даних і формувати з них розсилки і надійний механізм, що зв'язує нашу систему з операторами. Принциповим завданням тут є зберігання величезного обсягу користувацьких баз, їх швидка обробка і доступ до них.
 
 Маршрутизація
Так як обсяг даних у нас дуже великий, нам потрібно було вирішити, як здійснювати їх обробку, розподіл і роутинг.
Після того, як ми розділили весь обсяг даних по декількох внутрішнім підключеннях, нам необхідно було домогтися, щоб кожне повідомлення потрапило в необхідний шлюз. Відповідно, повідомлення потрібно певним чином розподілити по операторам. Такий розподіл здійснюється в комплексі маршрутизації, який являє собою систему додатків, яка займається напрямком мільйонів повідомлень з того чи іншого шлюзу. Розподіл здійснюється на основі аналізу атрибутів повідомлення: приналежність абонента до того чи іншого оператора (не просто по коду, а по обслуговуючому оператору), тексту повідомлення, номеру відправника, тобто властивості повідомлення піддаються повному аналізу та обробці. Тим самим ми вирішуємо задачу розподілу повідомлень: начебто розсилка одна, а повідомлення розподіляються і йдуть різними шляхами в залежності від свого оператора (номера абонента) і, наприклад, номера відправника. Роутингом трафіку займаються кілька виділених серверів, що представляють частина інфраструктури за межами UI і бекенд.
 
 

Внутрішня архітектура

 
 
 
В якості веб-сервера, який обробляє звернення користувача до UI і запити API, виступає nginx.
Це рішення класичне, практично універсальне для подібних завдань. Рівнем нижче, логічно було б розгорнути веб-сервер Apache, але ми їм вирішили не користуватися, тим самим заощаджуючи ресурси (весь функціонал нам не потрібен, а платити повну ціну за необхідний нам 1% його можливостей недоцільно), а створили власне ядро ​​на Perl. Це те, що, власне, і є основою системи.
 
 Чому Perl?
Коротка відповідь: Так вже вийшло Так історично склалося.
Довгий відповідь: Це Холіварние питання, насправді немає ніяких особливих причин використовувати ту або іншу мову. Ключовим питанням у великому і складному проекті є грамотно спроектована архітектура, а не мова. У нас є фахівці, які знають і люблять різні мови, історія склалася так, що при розробці цього проекту найбільшу старанність проявили специ, знаючі Perl :) Водночас, раз вже в підсумку обраний Perl, можна відзначити плюси цієї мови, найважливішими з яких, безсумнівно, є CPAN (читай — готові рішення для будь-якої задачі) і зрілість мови (читай — гарантована працездатність коду при оновленнях (тут шпилька на адресу PHP)).
 
 Ядро
Ядро взаємодіє з веб-сервером за допомогою інтерфейсу FastCGI, який, по-перше служить для пробрасиванія прийшов до нас запиту і прийнятого nginx в наше ядро, по-друге FastCGI та пов'язані з ним модулі представляють механізм запуску ядра в вигляді кількох «демонів», тобто ядро ​​запущено завжди.
 
Саме ядро ​​розбито на кілька окремих «демонів», кожен з яких відповідає за свою частину процесів. Самі основні з них — це сайт з особистим кабінетом, набір API, функціонал, який відповідає за завантаження файлів від користувача (абонентські бази), також у ядрі передбачена сервісна частину, не взаємодіє, із зовнішніми даними та орієнтована виключно на внутрішні (службові ) процеси. Сама по собі ця частина ділиться на кілька низькорівневих функцій. Наприклад, коли користувач завантажив базу абонентів, спочатку система бачить її як просто якийсь файл з даними, не придатними для роботи. Після завантаження файлу відбувається його обробка — перевіряються номери абонентів на коректність довжини і префікси, відкидаються порожні і занадто короткі номери, тобто, «сирий» файл перетворюється в деяку стандартну внутрішню структуру, що містить номери абонентів, ID, ідентифікатор регіону і деякі інші службові параметри.
 
 База даних
Офлайн користувачем бази зберігаються на диск і лежать в файлової системі, але після того, як по них пробіглися наші сервісні скрипти, з них витягується необхідна описує інформація, яка зберігається в базу даних. Ця інформація структурована, у ній можна робити запити з фільтрами по кожному атрибуту.
При обробці баз і виділенні деяких необхідних сутностей з них, або при обробці отриманої статистки, сортування займає колосальний обсяг. Звичайні сортувальники є малопридатними для такого обсягу і складності сортировок, тому для цього ми використовуємо MSORT.
 
 Файлова система
Оскільки користувач завантажує нам великі за обсягом абонентські листи, їх потрібно десь зберігати, плюс кожна розсилка генерит величезна кількість власних службових даних: блок сформованих повідомлень по розсилці, статуси, отримані на дані блоки, а також підсумковий файл для експорту. Проміжні файли видаляються після того, як розсилання завершується. Наприклад, розсилка на 10 млн. повідомлень викликає по кожному з них по 3-5 сигналів, а це вже 30-50 млн.запісей у файл. Загалом, у нас генеруються мільярди записів, які ми не повинні втратити, тому що в будь-який момент клієнту може знадобитися розібратися в деталях. Для цього до нашого ядру підключено окреме файлове сховище.
У деяких випадках виникає гостра необхідність знайти якусь конкретну запис в тому чи іншому файлі, будь це база номерів або якась інша статистика. Читати його перебором від початку до кінця довго і витратно, тому в ряді процесів ми використовуємо багатьма забуте засіб — Berkeley DB (BDB). Це своєрідних хеш на диску, який містить в собі якийсь ідентифікатор, який говорить про зміщення у файлі, з якого необхідно зчитувати необхідні відомості.
 
 Маршрутизація та доставка інформації до операторів
Ядро взаємодіє з внутрішньою системою маршрутизації, яка розсилає смски операторам. Ця частина була розроблена i-Free і підтримується силами інфраструктури компанії.
Ми підключені до операторів, і передаємо повідомлення (смс-повідомлення) за допомогою нативних засобів. Як правило, це SMPP, який виділяє оператор своїм постачальникам.
    
Джерело: Хабрахабр

0 коментарів

Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.