Архітектура мікросервісів на Ruby: практичний посібник із налаштування

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

Тут ми проведемо вас через процес налаштування Ruby на реальних практичних прикладах та надамо корисні рекомендації.

Початок роботи з мікросервісами

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

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

Аналіз взаємодії та обміну повідомленнями  

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

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

Створення мікросервісів на Ruby    

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

Якщо говорити про конкретний проект сервісу, він зазвичай включає такі компоненти:

• Конфігурацію, що містить рівні логування, налаштування бази даних та адресу брокера.
• Ініціалізатори, які відповідають за визначення залежностей.
• Об’єкти передачі даних (DTO) та об’єкти доступу до даних (DAO).
• Репозиторії, що керують операціями доступу до даних.
• Маппери, необхідні для перетворення між DAO та DTO.
• Класи сервісів, необхідні для оркестрування репозиторіїв та реалізації бізнес-кінцевих точок.

Створення простого сервісу «Person»

Тепер розглянемо приклад сервісу «Person». Перший крок пов’язаний із налаштуванням з’єднання з базою даних та визначенням таблиці «person». Модель DAO потрібна для представлення записів у таблиці, а DTO використовується для представлення форми зовнішнього корисного навантаження.

Після цього для перетворення між DTO та DAO використовується мапер. Усі ці компоненти об’єднує репозиторій, щоб забезпечити виконання операцій більш високого рівня. Останнім кроком є використання класу сервісу для об’єднання всіх компонентів та надання структурованої відповіді.

Наприклад, за допомогою методу get можна отримати інформацію про всіх користувачів. Якщо така інформація відсутня, генерується стандартна помилка 404. Якщо така інформація доступна, її перетворюють у DTO та повертають клієнту. Потім сервіс прив’язується до брокера, маршрути пов’язуються, і це гарантує, що вхідні запити будуть надіслані до правильного обробника.

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

Використання шаблонів репозиторіїв

Сервіси в описаній архітектурі не взаємодіють безпосередньо з моделями бази даних. Вони в основному базуються на репозиторіях, які, у свою чергу, ґрунтуються на принципі маперів, DTO та DAO. Такий підхід має кілька конкретних переваг:

• Оскільки всі операції з доступом до даних централізовано зосереджені в репозиторіях, це позитивно впливає на логіку запитів та зберігання даних.
• Основний принцип функціонування ґрунтується на обробці повідомлень та бізнес-логіці.
• Гарантії стабільності контракту завдяки DTO.

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