💠 Микросервисная архитектура: основные понятия

Микросервисная архитектура — это подход к разработке, при котором система разделяется на слабо связанные друг с другом части, которые разрабатываются и развёртываются независимо друг от друга.

У каждого микросервиса своя бизнес-задача: управлять каталогом, хранить содержимое корзины или проводить оплату заказа. При этом разные микросервисы могут быть реализованы на разных языках программирования и использовать разные СУБД.

🔲 Альтернатива монолиту

Большинство систем, разработанных ранее, построены на монолитной архитектуре. Это тяжеловесные приложения, с огромным количеством строк кода, который часто не документирован и не читаем.

Вносить изменения в такую систему крайне сложно: малейшее изменение кода может вызвать баги в самых неожиданных местах. А ведь любой баг уронит сразу всю систему! А ещё монолит можно релизить только вест целиком.

Микросервисная архитектура предлагает альтернативу монолиту.

✅ Преимущества микросервисной архитектуры

1️⃣ Сокращение Time To Market. Главная цель перехода на микросервисы – увеличение скорости поставки конечной ценности на рынок, или, по-айтишному, сокращение длительности релизного цикла. Если эта цель не выполняется, стоит задуматься, а зачем вам микросервисы.

2️⃣ Масштабируемость. Микросервисы можно масштабировать независимо друг от друга. Например, если возрастает нагрузка на какой-либо сервис, можно создать дополнительные реплики этого сервиса или увеличить вычислительные мощности, не затрагивая систему в целом.

3️⃣ Отказоустойчивость. При падении одного из микросервисов система в целом продолжает функционировать.

4️⃣ Гибкость технологий. Любой микросервис по отдельности можно реализовывать на каком угодно техстеке.

⛔️ Недостатки микросервисной архитектуры

1️⃣ Это дорого. Требуется больше железа и людских ресурсов.

2️⃣ Это сложно. Сложно правильно декомпозировать предметную область и грамотно определить границы сервисов. Сложно искать ошибки, так как приходится применять специальные системы трейсинга. Сложно обеспечить мониторинг.

3️⃣ Сложно поддерживать целостность данных. Если в монолите у нас общая реляционная БД, то и схема данных у нас общая. Целостность и транзакционность находятся под контролем СУБД. В микросервисной архитектуре у каждого сервиса своя БД, а значит нет единой системы, которая бы гарантировала целостность транзакций.

❓ Когда стоит переходить на микросервисы

🔹 Монолит ограничивает эффективность бизнеса. Вносить изменения в код практически невозможно. Релизы очень сложны и долги. Ошибки приводят к большим финансовым и репутационным потерям.

🔹 Есть деньги, ресурсы и компетенции.

🔹 У вас крупный проект с большим количеством разработчиков.

🔹 Вы отлично понимаете свою предметную область. Без этого верно определить границы микросервисов нельзя.

🔹 Вы понимаете, как будут работать распределённые транзакции

❌ Когда не стоит переходить на микросервисы

➖ Малый размер проекта. Если у вас проект маленький или средний по размеру, миграция на микросервисы может привести к ненужной сложности и издержкам.

➖ Не хватает ресурсов. Микросервисы — это дорого и сложно. Если у вас нет достаточно разработчиков, времени, денег, лучше не пытатьсях.

➖ Команда не готова. Микросервисы требуют специальных навыков и знаний. Если ваша команда не имеет их или не хочет менять архитектуру, это может вызвать проблемы.

➖ Текущая архитектура работает. Если ваш монолитный проект устойчив и соответствует потребностям бизнеса.

➖ Нужен быстрый старт. Если вам нужно скорее запустить проект и получить фидбек от пользователей, микросервисы могут замедлить процесс.

➖ Высокие требования к согласованности данных. Микросервисы используют разные базы данных для разных сервисов, что может создавать сложности при согласовании данных.

➖ Тесная связанность компонентов: Если компоненты приложения не могут быть изолированы, переход на микросервисы может быть слишком дорогим.

Подборка материалов про микросервисы — в следующем посте 👈

#микросервисы #архитектура