1. Що таке мікросервіси і чим вони відрізняються від традиційної монолітної архітектури?
Найкраща відповідь:
Мікросервіси — це архітектурний стиль, при якому додаток поділяється на маленькі незалежні сервіси, кожен з яких фокусується на конкретній функціональності. Ці сервіси слабо зв'язані між собою і взаємодіють через API (наприклад, HTTP або черги повідомлень).
Різниця:
- Монолітна архітектура: Усі компоненти (UI, логіка, дані) інтегровані в одну кодову базу.
- Мікросервіси: Компоненти незалежні, що дозволяє їх окреме розгортання, масштабування та розробку.
2. Чи можете ви пояснити основні переваги використання мікросервісів у розподілених системах?
Найкраща відповідь:
- Масштабованість: Масштабування окремих сервісів залежно від їх навантаження.
- Гнучкість: Використання різних технологій для різних сервісів.
- Ізоляція помилок: Збої в одному сервісі не впливають на інші.
- Швидка розробка: Команди можуть працювати і розгортати сервіси незалежно.
- Обслуговуваність: Менші, орієнтовані на конкретну задачу сервіси легші в управлінні та рефакторингу.
3. Як мікросервіси взаємодіють між собою, і які є поширені патерни для цієї взаємодії?
Найкраща відповідь:
Мікросервіси взаємодіють за допомогою:
- HTTP/REST API: Для синхронної взаємодії.
- Черги повідомлень (наприклад, RabbitMQ, Kafka): Для асинхронної взаємодії.
- gRPC: Високопродуктивний протокол для комунікації.
Патерни: - Синхронний (Запит-Відповідь): Виклики RESTful API.
- Асинхронний (Подієво-орієнтований): Черги повідомлень для розділення взаємодій.
- API Gateway: Централізований маршрут для запитів.
- Виявлення сервісів: Динамічне знаходження сервісів у мережі.
4. Опишіть реальний сценарій, де мікросервіси є ідеальним вибором для архітектури.
Найкраща відповідь:
Велика платформа електронної комерції (наприклад, Amazon), яка має функції, такі як аутентифікація користувачів, каталог товарів, обробка платежів та відстеження замовлень. Кожна з цих функцій може працювати як окремий мікросервіс, що дозволяє незалежне масштабування, розробку та стійкість.
5. Які основні недоліки монолітної архітектури?
Найкраща відповідь:
- Проблеми масштабованості: Увесь додаток потрібно масштабувати, навіть для локальних запитів.
- Проблеми з обслуговуванням: Великі кодові бази важче налагоджувати та оновлювати.
- Затримки при розгортанні: Зміни вимагають перезавантаження всього додатку.
- Тісна прив'язка: Одна помилка може порушити роботу всього системи.
- Обмеження технологій: Обмеженість до єдиного технологічного стеку.
6. В яких випадках монолітна архітектура буде кращим вибором, ніж мікросервіси?
Найкраща відповідь:
Для маленьких додатків або команд, де:
- Додаток має обмежену функціональність.
- Масштабування та незалежна розробка не є пріоритетами.
- Простий код зменшує складність і оперативні витрати.
7. Які проблеми можуть виникнути, якщо компанія, що використовує монолітну архітектуру, швидко масштабуватиме свою користувацьку базу?
Найкраща відповідь:
- Блокування продуктивності: Зростаючий трафік уповільнює роботу додатку.
- Неефективне масштабування: Масштабування вимагає оновлення всієї системи.
- Складність обслуговування: Великі кодові бази ускладнюють налагодження та оновлення.
- Час простою: Уся система стає вразливою до єдиної точки відмови.
8. Які основні принципи проектування архітектури мікросервісів?
Найкраща відповідь:
- Слабка зв'язність: Незалежні сервіси еволюціонують без впливу на інші.
- Єдина відповідальність: Кожен сервіс орієнтований на одну область.
- Автономність: Кожен сервіс керує власними даними, технологічним стеком і розгортанням.
- Витривалість: Обробка помилок без збоїв.
- Децентралізоване управління даними: Кожен сервіс управляє своєю базою даних.
- API-орієнтована комунікація: Забезпечення безперебійної взаємодії між сервісами.
## 9. Чому децентралізоване управління даними є критично важливим у мікросервісах і які виклики це приносить?
Найкраща відповідь:
Важливість: Це дозволяє сервісам функціонувати автономно і зменшує залежності.
Виклики:
- Консистентність даних: Синхронізація даних між сервісами є складною.
- Складні запити: Запити, що охоплюють кілька сервісів, стають важкими для виконання.
- Дублювання даних: Збільшує вимоги до сховища і потенційні несумісності.
10. Яка найкраща стратегія для розкладу монолітної архітектури на мікросервіси?
Найкраща відповідь:
- Визначення доменів: Використовуйте підхід, орієнтований на предметну область (DDD), для ізоляції ключових бізнес-доменів.
- Пілотні маленькі модулі: Починайте з некритичних модулів, щоб мінімізувати ризики.
- Поступова міграція: Поступово виділяйте та розгортайте сервіси, забезпечуючи функціональність системи.
- Тестування: Виконуйте інтеграційне та функціональне тестування, щоб забезпечити безперебійну взаємодію.
11. Як ви б ідентифікували критичні піддоменні частини в монолітному додатку, які можна виділити в мікросервіси?
Найкраща відповідь:
- Підхід, орієнтований на предметну область (DDD): Визначення обмежених контекстів у бізнес-логіці.
- Аналіз навантаження: Орієнтуйтеся на високонавантажені або часто оновлювані модулі.
- Мапування залежностей: Ізолюйте модулі з мінімальними залежностями.
- Бізнес-пріоритети: Вибір доменів, які мають значну бізнес-цінність або є проблемними.
Ці відповіді дають стислий, але вичерпний огляд мікросервісів та їхніх відмінностей від монолітної архітектури, а також практичні інсайти щодо їх переваг, викликів і реального застосування.
Гарного дня!
Перекладено з: Dot Net Microservices: Interview Question Part-1