💠 Микросервисная архитектура: основные понятия
Микросервисная архитектура — это подход к разработке, при котором система разделяется на слабо связанные друг с другом части, которые разрабатываются и развёртываются независимо друг от друга.
У каждого микросервиса своя бизнес-задача: управлять каталогом, хранить содержимое корзины или проводить оплату заказа. При этом разные микросервисы могут быть реализованы на разных языках программирования и использовать разные СУБД.
🔲 Альтернатива монолиту
Большинство систем, разработанных ранее, построены на монолитной архитектуре. Это тяжеловесные приложения, с огромным количеством строк кода, который часто не документирован и не читаем.
Вносить изменения в такую систему крайне сложно: малейшее изменение кода может вызвать баги в самых неожиданных местах. А ведь любой баг уронит сразу всю систему! А ещё монолит можно релизить только вест целиком.
Микросервисная архитектура предлагает альтернативу монолиту.
✅ Преимущества микросервисной архитектуры
1️⃣ Сокращение Time To Market. Главная цель перехода на микросервисы – увеличение скорости поставки конечной ценности на рынок, или, по-айтишному, сокращение длительности релизного цикла. Если эта цель не выполняется, стоит задуматься, а зачем вам микросервисы.
2️⃣ Масштабируемость. Микросервисы можно масштабировать независимо друг от друга. Например, если возрастает нагрузка на какой-либо сервис, можно создать дополнительные реплики этого сервиса или увеличить вычислительные мощности, не затрагивая систему в целом.
3️⃣ Отказоустойчивость. При падении одного из микросервисов система в целом продолжает функционировать.
4️⃣ Гибкость технологий. Любой микросервис по отдельности можно реализовывать на каком угодно техстеке.
⛔️ Недостатки микросервисной архитектуры
1️⃣ Это дорого. Требуется больше железа и людских ресурсов.
2️⃣ Это сложно. Сложно правильно декомпозировать предметную область и грамотно определить границы сервисов. Сложно искать ошибки, так как приходится применять специальные системы трейсинга. Сложно обеспечить мониторинг.
3️⃣ Сложно поддерживать целостность данных. Если в монолите у нас общая реляционная БД, то и схема данных у нас общая. Целостность и транзакционность находятся под контролем СУБД. В микросервисной архитектуре у каждого сервиса своя БД, а значит нет единой системы, которая бы гарантировала целостность транзакций.
❓ Когда стоит переходить на микросервисы
🔹 Монолит ограничивает эффективность бизнеса. Вносить изменения в код практически невозможно. Релизы очень сложны и долги. Ошибки приводят к большим финансовым и репутационным потерям.
🔹 Есть деньги, ресурсы и компетенции.
🔹 У вас крупный проект с большим количеством разработчиков.
🔹 Вы отлично понимаете свою предметную область. Без этого верно определить границы микросервисов нельзя.
🔹 Вы понимаете, как будут работать распределённые транзакции
❌ Когда не стоит переходить на микросервисы
➖ Малый размер проекта. Если у вас проект маленький или средний по размеру, миграция на микросервисы может привести к ненужной сложности и издержкам.
➖ Не хватает ресурсов. Микросервисы — это дорого и сложно. Если у вас нет достаточно разработчиков, времени, денег, лучше не пытатьсях.
➖ Команда не готова. Микросервисы требуют специальных навыков и знаний. Если ваша команда не имеет их или не хочет менять архитектуру, это может вызвать проблемы.
➖ Текущая архитектура работает. Если ваш монолитный проект устойчив и соответствует потребностям бизнеса.
➖ Нужен быстрый старт. Если вам нужно скорее запустить проект и получить фидбек от пользователей, микросервисы могут замедлить процесс.
➖ Высокие требования к согласованности данных. Микросервисы используют разные базы данных для разных сервисов, что может создавать сложности при согласовании данных.
➖ Тесная связанность компонентов: Если компоненты приложения не могут быть изолированы, переход на микросервисы может быть слишком дорогим.
Подборка материалов про микросервисы — в следующем посте 👈
#микросервисы #архитектура
Микросервисная архитектура — это подход к разработке, при котором система разделяется на слабо связанные друг с другом части, которые разрабатываются и развёртываются независимо друг от друга.
У каждого микросервиса своя бизнес-задача: управлять каталогом, хранить содержимое корзины или проводить оплату заказа. При этом разные микросервисы могут быть реализованы на разных языках программирования и использовать разные СУБД.
🔲 Альтернатива монолиту
Большинство систем, разработанных ранее, построены на монолитной архитектуре. Это тяжеловесные приложения, с огромным количеством строк кода, который часто не документирован и не читаем.
Вносить изменения в такую систему крайне сложно: малейшее изменение кода может вызвать баги в самых неожиданных местах. А ведь любой баг уронит сразу всю систему! А ещё монолит можно релизить только вест целиком.
Микросервисная архитектура предлагает альтернативу монолиту.
✅ Преимущества микросервисной архитектуры
1️⃣ Сокращение Time To Market. Главная цель перехода на микросервисы – увеличение скорости поставки конечной ценности на рынок, или, по-айтишному, сокращение длительности релизного цикла. Если эта цель не выполняется, стоит задуматься, а зачем вам микросервисы.
2️⃣ Масштабируемость. Микросервисы можно масштабировать независимо друг от друга. Например, если возрастает нагрузка на какой-либо сервис, можно создать дополнительные реплики этого сервиса или увеличить вычислительные мощности, не затрагивая систему в целом.
3️⃣ Отказоустойчивость. При падении одного из микросервисов система в целом продолжает функционировать.
4️⃣ Гибкость технологий. Любой микросервис по отдельности можно реализовывать на каком угодно техстеке.
⛔️ Недостатки микросервисной архитектуры
1️⃣ Это дорого. Требуется больше железа и людских ресурсов.
2️⃣ Это сложно. Сложно правильно декомпозировать предметную область и грамотно определить границы сервисов. Сложно искать ошибки, так как приходится применять специальные системы трейсинга. Сложно обеспечить мониторинг.
3️⃣ Сложно поддерживать целостность данных. Если в монолите у нас общая реляционная БД, то и схема данных у нас общая. Целостность и транзакционность находятся под контролем СУБД. В микросервисной архитектуре у каждого сервиса своя БД, а значит нет единой системы, которая бы гарантировала целостность транзакций.
❓ Когда стоит переходить на микросервисы
🔹 Монолит ограничивает эффективность бизнеса. Вносить изменения в код практически невозможно. Релизы очень сложны и долги. Ошибки приводят к большим финансовым и репутационным потерям.
🔹 Есть деньги, ресурсы и компетенции.
🔹 У вас крупный проект с большим количеством разработчиков.
🔹 Вы отлично понимаете свою предметную область. Без этого верно определить границы микросервисов нельзя.
🔹 Вы понимаете, как будут работать распределённые транзакции
❌ Когда не стоит переходить на микросервисы
➖ Малый размер проекта. Если у вас проект маленький или средний по размеру, миграция на микросервисы может привести к ненужной сложности и издержкам.
➖ Не хватает ресурсов. Микросервисы — это дорого и сложно. Если у вас нет достаточно разработчиков, времени, денег, лучше не пытатьсях.
➖ Команда не готова. Микросервисы требуют специальных навыков и знаний. Если ваша команда не имеет их или не хочет менять архитектуру, это может вызвать проблемы.
➖ Текущая архитектура работает. Если ваш монолитный проект устойчив и соответствует потребностям бизнеса.
➖ Нужен быстрый старт. Если вам нужно скорее запустить проект и получить фидбек от пользователей, микросервисы могут замедлить процесс.
➖ Высокие требования к согласованности данных. Микросервисы используют разные базы данных для разных сервисов, что может создавать сложности при согласовании данных.
➖ Тесная связанность компонентов: Если компоненты приложения не могут быть изолированы, переход на микросервисы может быть слишком дорогим.
Подборка материалов про микросервисы — в следующем посте 👈
#микросервисы #архитектура