Мікросервіси
Перш ніж почати, що таке мікросервіс?
Мікросервіс — це невелика, незалежно розгортаєма компонента більшої програми, яка зосереджена на конкретній функціональності. Зазвичай кожен мікросервіс взаємодіє з іншими сервісами через API і має слабку зв’язність. Завдяки цьому забезпечується масштабованість, зручність у розробці та обслуговуванні.
Переваги мікросервісів порівняно з монолітною архітектурою:
Масштабованість: Мікросервіси можуть бути масштабовані відповідно до вимог, що дозволяє оптимізувати використання ресурсів.
Гнучкість: Кожен мікросервіс може бути розроблений, протестований, розгорнутий і обслуговуваний з використанням окремої технології.
Швидша розробка: Малі команди, орієнтуючись на конкретну функціональність, можуть працювати над різними мікросервісами незалежно, що прискорює процеси розробки, тестування та керування версіями.
Стійкість і простота обслуговування: Оскільки мікросервіси є незалежними і слабко зв’язаними з основною системою, ймовірність того, що проблеми в одному мікросервісі вплинуть на загальну систему, зменшується, а обслуговування стає простішим.
Гнучкість у використанні зовнішніх ресурсів: Ізоляція компонентів, що надходять ззовні, підвищує безпеку та стабільність основної служби.
До недоліків мікросервісів можна віднести:
1- Кожен сервіс має свій власний процес розробки. Тому розробка з використанням мікросервісів може бути складнішою, ніж монолітний підхід.
2- Мікросервіси взаємодіють через мережу, що може призводити до затримок, збоїв і труднощів в управлінні комунікацією між сервісами.
3- Якщо кожен мікросервіс має свою базу даних, можуть виникати проблеми із синхронізацією даних і операціями з даними.
4- Для зниження складності керування версіями може знадобитися використання таких інструментів, як Kubernetes для оркестрації контейнерів та автоматизації процесів.
5- Кожен мікросервіс може створювати нові вразливості та збільшувати площу атаки, тому потрібні додаткові заходи безпеки.
Для зменшення впливу цих недоліків існують певні шаблони проектування мікросервісів:
Database Per Service Pattern (Шаблон "База даних для кожного сервісу")
Це підхід, за якого кожен мікросервіс має власну базу даних. До бази даних сервісу можна звертатися лише через API цього сервісу. Інші сервіси не мають прямого доступу до цієї бази.
Якщо вибрано реляційну базу даних, для приховування даних від інших баз використовуються наступні 3 способи:
1- Таблиці, специфічні для сервісу
2- Специфічна для сервісу схема
3- Специфічний сервер бази даних для сервісу
Переваги:
Loose Coupling (Ге́вше з'єднання): Сервіси мають менше зв’язків між собою.
Технологічна гнучкість: Для кожного сервісу можна вибирати найбільш підходящу технологію бази даних.
Недоліки:
1- Оскільки для кожної бази даних потрібно окреме резервне копіювання, відновлення та масштабування, управління стає складнішим.
2- Складніше здійснювати запити до даних інших сервісів, для цього може бути використано компонент API Gateway.
3- Залишити дані узгодженими між сервісами може бути важче.
API Gateway Pattern (Шаблон "API-Гейтвей")
API-Гейтвей виступає як проміжний шар між клієнтами і мікросервісами.
İstekleri doğru servise yönlendirir, yanıtları birleştirir ve genellikle kimlik doğrulama, yük dengeleme ve log tutma gibi ortak işlevleri yönetir.
Avantajları;
1- İstemci etkileşiminin basitleşmesi
2- Ortak işlevler tek bir merkezden yönetilir ve kod tekrarının önüne geçilir.
3- Güvenlik politikaları ve erişim konrolü ile güvenlik arttırılır.
Dezavantajları;
1- API Gateway’in arızalanması durumunda sistem erişime kapanır.
2- Doğru şekilde ölçeklenmediği takdirde gecikmelere ve tıkanıklıklara yol açabilir.
Backend For Frontend Pattern (Шаблон "Аркада для фронтенду")
Це шаблон проектування, за якого для кожного конкретного фронтенду створюється окремий бекенд-сервіс. Кожен бекенд-сервіс проектується відповідно до потреб того фронтенду, для якого він створений.
Переваги;
1- Фронтенди отримують дані, які їм потрібні, що пришвидшує час завантаження і покращує користувацький досвід. Складність у бізнес-логіці зменшується.
2- Оскільки для кожного фронтенду розробляється новий бекенд-сервіс, забезпечується незалежність та гнучкість.
Недоліки;
1- Якщо не визначено спільні функції між сервісами, може виникнути дублювання коду і важкість в обслуговуванні.
2- Для великих систем важче забезпечити узгодженість між бекенд-сервісами.
Command Query Responsibility Segregation (CQRS) (Шаблон "Розділення відповідальностей за запити та команди")
Шаблон CQRS означає підхід до проектування, в якому операції з читання (запити) і запису (команди) розділяються через різні моделі або сервіси. Це дозволяє оптимізувати кожну модель для її конкретної функціональності.
Модель команд може бути оптимізована для обробки складної бізнес-логіки і зміни стану.
Модель запиту оптимізується для швидкого отримання даних і зазвичай використовує денормалізовані вигляди або кеші.
Переваги;
1- Кожна модель може бути оптимізована для своїх операцій, що підвищує продуктивність системи.
2- Операції читання та запису можна масштабувати незалежно, що покращує використання ресурсів.
3- Розділення відповідальностей за команди та запити робить код більш організованим, полегшуючи розуміння і обслуговування.
Недоліки;
1- Керування та синхронізація окремих моделей для команд і запитів додає складності в систему.
2- Забезпечення узгодженості між моделями команд і запитів, особливо в розподілених системах, де дані можуть не оновлюватися одразу, може бути складним.
3- Синхронізація даних між моделями читання і запису може створювати труднощі, особливо при роботі з великими обсягами даних або складними перетвореннями. Для вирішення таких проблем можуть використовуватись техніки event sourcing або message queues (черги повідомлень).
Event Sourcing Pattern (Шаблон "Джерело подій")
У цьому шаблоні зміни стану в системі записуються не безпосередньо як поточний стан, а як послідовність подій. Послідовності подій зберігаються в сховищі подій (Event Store), і інші мікросервіси можуть використовувати це сховище для оновлення своїх станів.
Переваги;
1- Завдяки подіям зберігається повна історія змін системи, що спрощує аудит, налагодження та розуміння еволюції системи.
2- Оскільки зберігаються лише події, система може працювати без проблем навіть за високої частоти записів.
3- Легше додавати нову функціональність.
Недоліки;
1- Керування потоком подій і відтворення стану може бути складнішим, ніж традиційний підхід, і вивчення цього підходу може зайняти деякий час.
2- Потребує більше простору для зберігання, ніж традиційні методи.
3- Запити на події можуть бути складнішими, оскільки для отримання поточного стану потрібно відновлювати його з подій.
Saga Pattern (Шаблон "Сага")
Цей шаблон використовується для управління великими і довготривалими операціями в розподілених системах, де працюють кілька мікросервісів. Кожну операцію розбивають на невеликі кроки, і кожен крок виконується окремо.
Eğer bir adım başarısız olursa, önceki adımları geri almak için “compensating transactions” denilen geri alma işlemleri yapılır.
Bu desen için iki yol vardır;
1- Choreography (Кореографія): Her servis, diğer servislerin yaptığı işleri dinler ve ona göre kendi işini yapar.
2- Orchestration (Оркестрація): Bir ana servis, her servisin hangi adımları yapması gerektiğini söyler ve işlemi yönetir.
Avantajları;
1- Veri tutarlılığı,
2- Dayanıklı sistem
Dezavantajları;
1- Karmaşıklık
2- Geri alma zorlukları
Sidecar Pattern (Шаблон "Сайдкар")
Цей шаблон передбачає, що поряд з основним сервісом працює допоміжний сервіс (sidecar). Цей допоміжний сервіс додає додаткову функціональність без зміни основного коду програми.
Переваги;
1- Можливість додавати функціональність, не впливаючи на основну роботу програми.
2- Навіть якщо виникають проблеми з основним додатком, sidecar може продовжувати працювати, і навпаки.
3- Основний додаток і sidecar можна масштабувати окремо.
Недоліки;
1- Складність,
2- Затримки
Circuit Breaker Pattern (Шаблон "Запобіжник")
Цей шаблон, як і запобіжник в електричному колі, захищає систему від поломок, ізолюючи несправні сервіси.
Процес роботи такий;
1- Closed (Закрито): Система працює в нормальному режимі.
2- Open (Відкрито): Якщо в сервісі виявлено помилку, запобіжник активується і переводить його в стан "відкрито", блокуючи запити до цього сервісу, що дозволяє підтримувати баланс навантаження в системі.
3- Half-Open (Піввідкрито): Стан, коли тестується несправний сервіс. Якщо проблема не вирішується, сервіс знову переходить у стан "відкрито".
Переваги;
1- Запобігає каскадним (Chain) помилкам.
2- Підвищує надійність системи.
2-Підвищує надійність.
Недоліки;
1- Визначити, коли відкривати запобіжник, може бути складно.
2- Можуть знадобитись резервні плани на випадок, якщо сервіс працює ненормально.
Anti-Corruption Layer (ACL) (Шаблон "Антикорупційний шар")
Цей шаблон запобігає впливу дизайну зовнішніх систем і їхніх моделей даних на внутрішню структуру системи. Коли система взаємодіє з іншою системою, структура і правила даних можуть бути різними. ACL керує цими відмінностями, захищаючи внутрішню систему від складних чи несумісних зовнішніх даних.
Переваги;
1- Захист.
2- Гнучкість.
3- Легкість в обслуговуванні.
Недоліки;
1- Затримки.
2- Складнощі зі масштабуванням у великих застосунках.
3- Додаткові шари вимагають додаткового коду і логіки.
Aggregator Pattern (Шаблон "Агрегатор")
Цей шаблон об'єднує дані з різних джерел, створюючи єдиний результат. Збір, обробка та об'єднання даних управляється компонентом або сервісом, який виконує роль агрегатора.
Переваги;
1- Клієнти взаємодіють лише з одним сервісом або точкою доступу, що зменшує складність і забезпечує зручність використання.
2- Дані збираються в одному місці, що зменшує потребу в багатьох викликах і підвищує ефективність.
3- Обробка і трансформація даних здійснюється централізовано, що забезпечує узгодженість і сумісність між різними джерелами.
Недоліки;
1- Робота з різними джерелами даних і форматами може ускладнити реалізацію логіки агрегації.
2- Агрегатор є єдиною точкою, через яку проходять всі дані, тому проблеми з агрегатором можуть вплинути на роботу всієї системи.
3- Збір даних з різних джерел, особливо коли джерела розподілені або виконують складні операції, може призвести до затримок.
4- Масштабування агрегатора для обробки збільшених обсягів даних або запитів може бути складним і вимагати ретельного проектування.
Сподіваюся, що цей матеріал був корисним. Дякую за ваш час!
Перекладено з: 10 Mikroservis Tasarım Deseni