Технології розробки і підтримки складного продукту: досвід «Гідри»

image
У нашому блозі ми вже розповідали про біллінгу для операторів зв'язку «Гідра» — наших підходах до розробки складних продуктів, а також описували реальні кейси впровадження системи. Сьогодні ми докладніше поговоримо про стеку технологій та інструментів, які використовуються в процесі розробки й експлуатації нашого проекту.

Архітектура
Перш, ніж описувати використовувані технології, уважніше розглянемо, з чого складається система білінгу.

  • Дані — інформація про спожитих абонентами послуги, баланси особових рахунків, деталізація платежів і списань.
  • Ядро — частина системи, в якій ведуться всі операції з даними. У «Гідрі» воно інтегровано з даними — бізнес-логіка знаходиться прямо в СУБД у вигляді збережених процедур. Модифікувати дані безпосередньо зовнішніми додатками заборонено, це можна робити тільки через API.
  • AAA-сервер (Authentication, Authorization, Accounting) — елемент, який відповідає за аутентифікацію, авторизацію і облік інформації про спожитих абонентами послуги.
  • Платіжний шлюз — приймає інформацію про проведені платежі з різних платіжних систем.
  • Особистий кабінет абонента і веб-панель управління — інтерфейси для доступу та роботи з системою.
image

Загальне уявлення архітектури системи

Тепер поговоримо вже про конкретних технологіях.

СУБД: Oracle і MongoDB
Наша білінгова система використовує для обліку первинних даних і зберігання фінансової інформації реляційну СУБД Oracle. Вона ідеально підходить для цих цілей. Основна база зберігає дані і ядро системи. Ми використовуємо вырожденную трирівневу архітектуру — бізнес-логіка (збережені процедури і функції в Oracle) і дані (таблиці) тісно інтегровані в СУБД, в якості клієнта виступає браузер («тонкий клієнт»), а веб-інтерфейс служить програмною оболонкою ядра.

Але деякі модулі Гідри, наприклад, RADIUS-сервер, що працюють під високим навантаженням і можуть отримувати тисячі запитів в секунду з жорсткими обмеженнями на час обробки запиту. Крім того, в БД нашого автономного RADIUS-сервера дані зберігаються у вигляді набору AVP (attribute/value pair). У такому сценарії реляційна СУБД вже не виглядає кращим рішенням, і тут на допомогу приходить MongoDB з її сховищем документів довільної структури, швидкої видачею відповіді і горизонтальної масштабованістю.

При експлуатації більш ніж на 100 інсталяціях Гідри протягом останніх 5 років серйозних проблем з Mongo ми не виявили. Але пара нюансів все ж є. По-перше, після раптового відключення сервера БД хоч і відновлюється завдяки журналу, але відбувається це повільно. На щастя, необхідність у цьому виникає нечасто. По-друге, навіть при невеликому розмірі БД рідко використовувані дані скидаються на диск і коли запит до них все-таки приходить, їх вилучення займає багато часу. У результаті порушуються обмеження на час виконання запиту.

Все це відноситься до движка MMAPv1, який застосовується в Mongo за замовчуванням. З іншими (WiredTiger і InMemory) ми поки не експериментували — проблеми не настільки серйозні.

Читайте також: Коли варто і не варто використовувати MongoDB

Робота з даними: JSON
Крім білінгу «Гідра», ми розвиваємо і open-source систему управління бізнес-процесами «Гідра OMS». У цьому проекті використовується ще і СУБД PostgreSQL, а для роботи з даними застосовується JSON. Зокрема, ми зберігаємо в таких полях значення змінних процесу, структура якого визначається в момент впровадження продукту, а не під час його розробки.

Робота з полями таблиці здійснюється через адаптер фреймворку Ruby On Rails для PostgreSQL. Читання і запис працюють в нативному для Ruby режимі — через хеші та списки. Таким чином, ви можете працювати з даними з поля без додаткових перетворень.

Читайте також: Як використовувати обмеження JSON при роботі з PostgreSQL

Оптимізація продуктивності: денормалізація
Ми в Латере багато займаємося оптимізацією продуктивності білінгової системи, що не дивно, враховуючи обсяги наших клієнтів і специфіку телеком-галузі.

На Хабре ми обговорювали матеріал зарубіжних колег про використання денормалізації баз даних. Один з представлених у цій статті прикладів передбачає створення таблиці із проміжними підсумками для прискорення звітів. Звичайно, найскладніше в цьому підході — підтримувати актуальний стан такої таблиці. Іноді можна перекласти це завдання на СУБД — наприклад, використовувати матеріалізовані уявлення. Але, коли бізнес-логіка для отримання проміжних результатів виявляється трохи більш складним, актуальність денормализованных даних доводиться забезпечувати вручну.

Так, Гідра має глибоко опрацьовану систему привілеїв для користувачів, операторів білінгу. Права видаються кількома способами — можна дозволити певні дії конкретному користувачеві, можна заздалегідь підготувати ролі і видати їм різні набори прав, можна наділити певний відділ спеціальними привілеями. Тільки уявіть, наскільки повільними стали б звернення до будь-яких сутностей системи, якщо б кожен раз потрібно було пройти всю цю ланцюжок, щоб переконатися: «так, цього співробітника дозволено укладати договори з юридичними особами» або «ні, у цього оператора недостатньо привілеїв для роботи з абонентами сусіднього філії». Замість цього ми окремо зберігаємо готовий агрегований список діючих прав для користувачів і оновлюємо його, коли в систему вносяться зміни, здатні на цей список вплинути. Співробітники переходять із одного відділу в інший набагато рідше, ніж відкривають чергового абонента в інтерфейсі білінгу, а значить обчислювати повний набір їх прав нам доводиться настільки ж рідше.

Звичайно, денормалізація сховища — це тільки одна з прийнятих заходів. Частина даних варто кешувати і безпосередньо в додатку, але якщо проміжні результати в середньому живуть набагато довше, ніж користувальницькі сесії, є сенс серйозно задуматися про денормалізації для прискорення читання.

Читайте також: Навіщо потрібна денормалізація баз даних, і коли її використовувати

Управління обладнанням: Clojure
Зараз ми використовуємо для виконання команд по управлінню обладнанням Clojure. Специфіка завдання полягає у вимогах до одночасності при виконанні команд і гнучких обмеження. З одного боку не можна «завалити» один пристрій командами, з іншого боку — виконувати всі команди послідовно неефективно, тому що вони можуть одночасно виконуватися на різному устаткуванні. Ця задача легко вирішується бібліотекою core.async, яка додає підтримку go-блоків і каналів, знайомих з мови Go, де з допомогою них реалізовані взаємодіючі послідовні процеси (термін, більше відомий як CSP).

При цьому Сlojure — мова загального призначення, знайти йому застосування не становить великої праці. Так як він базується на JVM, то для нього вже фактично існує величезний вибір бібліотек, тому при його використанні не потрібно писати все заново, що сильно знижує поріг входу.

Навіть якщо ви на дух не переносите Lisp, вам варто ознайомитися з концепціями, які закладені в мову, багато з них змушують по-новому поглянути на програмування.

Читайте також: Чому варто вивчати і використовувати Clojure

Управління проектами та підтримка
Спочатку для завдань відділу впровадження та техпідтримки використовувалася система Jira. Проте з часом стало очевидно, що пристосувати цей інструмент для розробників до завдань відділу впровадження та підтримки не так-то просто. В результаті ми почали шукати альтернативні засоби.

Одним з розглянутих варіантів був сервіс Zendesk, проте перешкодою до його використанню став незручний односторінковий інтерфейс, в якому, і тільки якому, за задумом авторів, повинні працювати співробітники відділу підтримки. Крім того, швидкість роботи Zendesk залишала бажати кращого. З цими проблемами ми зіткнулися в 2013 році, можливо зараз проект зробив крок вперед, однак ми вже знайшли йому альтернативу.

Їй став сервіс Freshdesk — він схожий на Zendesk, але має більш дружелюбним інтерфейсом і досить активно розвивається. Розробники оперативно реагують на запити, в їх системі реалізований і API-інтерфейс.

Для управління проектами впровадження ми використовуємо PM-сервіс Teamwork. У цій системі наочно показані всі необхідні етапи проекту, завдання, які повинні бути виконані, і ті ділянки роботи, які будуть розблоковані після цього. Також вказані відповідальні за рішення поставлених завдань з обох сторін.



Також для деяких завдань досі використовується Jira (ведення завдань, які не підходять за призначенням ні в одну з інших систем управління).

Крім того, ми організували власне сховище даних (Data Warehouse), яке вивантажується інформація з усіх існуючих систем і самого білінгу «Гідра», який застосовується для тарифікації оплаченого часу підтримки (воно автоматично завантажується в біллінг зі сховища) і виставлення рахунків. Ця інформація потім використовується для організації роботи відділу підтримки.

Читайте також: Як організувати підтримку складного продукту

Висновок
Наш проект розвивається вже 9 років, і за цей час ми взяли участь більш ніж в 100 проекти впровадження. Ми постійно працюємо над тим, щоб зробити систему більш надійною та зручною для клієнтів.

У нашому блозі ми продовжимо розповідати про використовуваних нами технологіях та підходах до поліпшення роботи «Гідри».

Інші статті по темі ІТ-інфраструктури від команди «Латеры»:
Джерело: Хабрахабр

0 коментарів

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