СИНХРОНІЗАЦІЙНИЙ МОДУЛЬ ДЛЯ СТОРОННІХ ІНТЕГРАЦІЙ МЕТОДОМ ІН’ЄКЦІЇ ДАНИХ В СЕРЕДНІЙ ТА ВЕЛИКИЙ БІЗНЕС - Scientific conference
Main page
UA RU EN

Congratulation from Internet Conference!

Hello

Рік заснування видання - 2011

СИНХРОНІЗАЦІЙНИЙ МОДУЛЬ ДЛЯ СТОРОННІХ ІНТЕГРАЦІЙ МЕТОДОМ ІН’ЄКЦІЇ ДАНИХ В СЕРЕДНІЙ ТА ВЕЛИКИЙ БІЗНЕС

24.09.2021 22:00

[1. Information systems and technologies]

Author: Севастьянов В.М., магістрант, кафедра комп’ютерних систем та мереж, Чернівецький національний університет імені Юрія Федьковича, м. Чернівці; Воробець Г.І., к.ф.-м.н., доцент, кафедра комп’ютерних систем та мереж, Чернівецький національний університет імені Юрія Федьковича, м. Чернівці


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

1. великий інтернет магазин по типу Розетки хоче відслідковувати аналітику рентабельності товарів з допомогою якогось стороннього сервісу; 

2. бухгалтера які хочуть використовувати дану систему для того щоб слідкувати за часом, який потратили робочі на якийсь конкретний проект, але вести облік проектів і своїх клієнтів вони звикли з допомогою іншого сервісу; 

Що в першому, що в другому випадку дві системи повинні підтримувати великі об’єми даних цілісно і в актуальному стані одночасно. В цьому і є основна функція розробки, що я пропоную реалізувати. Якщо ми розпочнемо досліджувати ринок таких сервісів ми не знайдемо рішення, яке могло б задовільнити всі вимоги. 

До прикладу:

● https://www.skysync.com/solutions/migrate-sync/ - сервіс може синхронізувати дані, але тільки у вигляді файлів, що є дуже вузькоспеціалізовано.

● https://www.elastic.io/data-migration/ - додаток здібний мігрувати дані, проте реалізовано це з допомогою технології веб-хуків, що не дозволить синхронізувати сервіси, які не мають підтримки вищеназваної.

Отже, вимогами до даної розробки є:

1. Можливість налаштування системи для роботи з інтеграціями по протоколу HTTPS, що є найпоширенішим засобом транспортування даних на даний момент, майже всі SaaS (software-as-a-service) додатки мають прекрасно описану API документацію для інтеграції з іншими сервісами.

2. Можливість налаштування автентифікації додатку, для того щоб вона могла отримувати доступ до систем, що знаходяться на обох сторонах процесу синхронізації.

3. Система може бути реконфігурована в любий момент часу людиною, яка має базові знання в створенні HTTPS запитів.

4. Як користувач даної системи я повинен мати змогу налаштувати моделі даних, які будуть синхронізуватись, а також запускати синхронізацію окремих моделей, та всіх одразу.

Методика та отримані результати досліджень. 

Для реалізації заданих вимог буде зручно використати хмарні сервіси, оскільки це значною мірою зменшить час розробки та допоможе оптимізувати вартість потужностей. На даний момент кращим вибором на ринку таких платформ є AWS (Amazon Cloud Services) через стабільність та різноманіття інструментів. Нас цікавить набір таких додатків:

● AWS Lambda - високо економні без серверні функції, що можуть бути викликані з допомогою HTTP протоколу. Оплата відбувається лише за використаний процесорний час.

● AWS EC2 - віддалені сервери конфігурованої потужності.

● AWS SQS - високошвидкісні черги для обміну даними, зазвичай використовуються для спілкування сервісів в мікро-сервісному додатку.

Наш мікро-сервісний додаток можемо поділити на такі сервіси: 

● сервіс синхронізації (synchronization service) - додаток, що буде порівнювати дані між собою та з їхнім попереднім станом(data snapshot) і на основі цього приймати рішення куди яку дію потрібно надіслати; 

● сервіс-шлюз (gateway service) - додаток-прошарок, що буде посередником між усіма іншими сервісами; 

● та лямбда-функції для доступу до даних (data access lambda-functions) - функції, які використовуватимуться для того щоб виконувати CRUD (create, read, update, delete) операції в обидвох синхронізованих системах;

Схема взаємодії сервісів в мікро-сервісному додатку (рис. 1).



Рис. 1 Схема взаємодії мікросервісів

Вхідною точкою даної системи буде сервіс API Gateway, через який користувач системи зможе надіслати всі необхідні конфігурації та запускати синхронізацію з такою періодичністю з якою буде необхідно. Всі параметри конфігурації можна буде змінити у живому часі, якщо синхронізація не запущена.

Алгоритм виглядає таким чином:

1. Користувач надсилає запит з конфігурацією, система сприймає дані, та зберігає їх у нереляційну БД. (Можна пропустити, якщо конфігурація вже була збережена)

2. Користувач надсилає дані, з своїх зареєстрованих моделей, невеликими порціями.

3. Одночасно з цим, Gateway Service автентифікується у інтегрованій системі і відсилає запит Data Access Lambda на діставання всіх даних з інтегрованої системи.

4. Дані обох систем збираються і надсилаються до Data Synchronization Service, проходять всі необхідні валідації, трансформуються до загального інтерфейсу, порівнюються і на основі порівняння створюються події, які мають відбутись у обох системах.

5. Data Synchronization Service відправляє всі події до Gateway Service і зберігає снепшот фінальних даних (для майбутнього відслідковування змін)

6. Gateway Service надсилає події відповідним системам, та очікує їхнього виконання.

7. Gateway Service сигналізує про завершення синхронізац  ії та показує логи помилок (валідаційні, авторизаційні і т. д.).

За допомогою таких сервісів як Lambda та EC2 буде відбуватись горизонтальне масштабування, тобто буде зростати кількість серверів і відповідно зберігатись швидкість при високих нагрузках.

Сервіс SQS дозволяє використовувати асинхронні черги як засіб спілкування в межах мікросервісної архітектури. Він надзвичайно швидкий і дозволяє передавати до 64 мб за одне повідомлення.

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

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

Література:

1. Документація AWS сервісів. – [Електронний ресурс]. – режим доступу - https://docs.aws.amazon.com/

2. Мікросервіси. – [Електронний ресурс]. – режим доступу - https://habr.com/ru/post/249183/ 



Creative Commons Attribution Ця робота ліцензується відповідно до Creative Commons Attribution 4.0 International License
допомога Знайшли помилку? Виділіть помилковий текст мишкою і натисніть Ctrl + Enter

Another articles in this section

Сonferences

Conference 2024

Conference 2023

Conference 2022

Conference 2021



Міжнародна інтернет-конференція з економіки, інформаційних систем і технологій, психології та педагогіки

Наукова спільнота - інтернет конференції

:: LEX-LINE :: Юридична лінія

Інформаційне суспільство: технологічні, економічні та технічні аспекти становлення