Всё обучение
Экономика и финансы
IT
Дизайн
Маркетинг
Менеджмент
Продажи
HR
Бизнес
Реклама и PR
Госслужба
Закупки и логистика
Образование
Юриспруденция
Лингвистика
Психология
Самообразование
Спорт
Киберспорт
Искусство и культура
Медицина
Туризм и сервис
Строительство
Теплоэнергетика и теплотехника
Электроэнергетика и электротехника
Техносферная безопасность
Нефтегазовое дело
Экология и природопользование
Промышленность
Сельское хозяйство
Транспорт
СМИ и медиа
Физика и инженерия
Геодезия
Химия
Энергомашиностроение
Машиностроительные технологии
Биология и биотехнологии
Нанотехнологии и наноматериалы
Социология
История
Филология
Математика и компьютерные науки
Ветеринария
Beauty-индустрия
Философия
Культурология
Политика и политология
Документоведение
image
Редакция Synergy HUB
1 публикация
#Статьи
21 декабря 2021 г.

Микросервисы или монолит: какую архитектуру выбрать для программного обеспечения

Рассказываем, что такое микросервисная архитектура, как она помогает в разработке ПО и в чём её отличие от монолитной.
Время чтения 7 минут

Система микросервисов — это архитектурный стиль разработки программного обеспечения, при котором единое приложение разбивается на небольшие автономные компоненты с определёнными интерфейсами. Эти компоненты (микросервисы) работают в собственном процессе и коммуницируют с остальными. За последние несколько лет микросервисы стали основным стилем в разработке ПО. 

Что такое монолитная архитектура

Если микросервисы — это относительно современный подход к разработке программного обеспечения, то монолитная архитектура — более традиционный стиль. Поэтому, чтобы лучше разобраться во всём, сравним первое со вторым. Приложения, разработанные по монолитной архитектуре, построены как единое целое. Таким сервисом легко управлять, и он эффективен для небольших проектов. 
 

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

  • легко разрабатывать ― вы можете открыть весь проект в интегрированной среде разработки (IDE) или даже в текстовом редакторе;
  • легко запускать ― вы можете нажать кнопку запуска в своей IDE и начать тестирование;
  •  простота развёртывания ― вы можете развернуть всю систему, загрузив один файл, например, файл WAR в приложении Java.

Когда монолитная архитектура не подходит 

Преимущества монолитной архитектуры применимы только к небольшим системам. По мере того, как система вырастает за пределы определённого размера, возникают трудности. И чем больше разрастается система, тем больше трудностей. Это может привести к так называемому «монолитному аду».

  • Развёртывание станет сложнее и рискованнее. Представьте, что вы обнаружили серьёзную ошибку и исправили ее. Теперь необходимо развернуть всю систему. Но прямо сейчас в разработке находятся и другие функции. Риск состоит в том, что, исправляя одну ошибку, вы вводите множество других.

    Решением может стать ограничение развёртывания выпусками так называемого «большого взрыва». Это означает, что установлен крайний срок для фиксации всех изменений и новых функций. Только после того, как вы протестируете всю систему, она будет развёрнута. Это кажется более безопасным вариантом, но проблема в том, что вы больше не можете вносить экстренные исправления. И по мере роста проекта сроки должны становиться все длиннее и дольше. Если ваш проект выходит раз в год, то вы застряли в «монолитном аду»!
     
  • Монолит может стать слишком большим для понимания одним разработчиком. Станет сложно установить границы между модулями. Со временем модули запутаются в массе зависимостей. Представьте: вы работали над монолитом, внесли изменения в модуль, но обнаружили, что сломали другой модуль. 
  • Монолит становится трудно масштабировать. По мере роста проекта увеличивается размер целевого оборудования. В облачной среде это означает обновление до более крупной виртуальной машины. Такое вертикальное масштабирование очень неэффективно, поскольку дорого. Например, если вам нужна новая машина с вдвое большим объёмом памяти, стоимость будет намного выше, чем в два раза. В какой-то момент вы просто зайдёте в тупик.

     

Альтернатива: микросервисная архитектура

Хороший выход из ситуации ― разработка отдельных микросервисов. Принцип заключается в том, что каждый микросервис:

  • разработан отдельной командой;
  • размещён в собственном репозитории (место хранения и поддержания данных, например, Git);
  • выполняет полезную бизнес-функцию;
  • имеет возможность самостоятельного развёртывания;
  • работает автономно и делает что-то полезное и проверяемое;
  • может сотрудничать с другими микросервисами для достижения более крупной цели.
     

Каким образом взаимодействуют микросервисы ― тема для отдельной статьи. Можно создавать простые веб-службы передачи репрезентативного состояния (архитектурный стиль взаимодействия компонентов распределённого приложения в сети, например, REST) или использовать более сложные асинхронные системы обмена сообщениями.

Легко определить, как выглядит микросервисная архитектура, но построить ее намного сложнее! Как определить, какими должны быть микросервисы в вашей системе? Насколько большими они должны быть? Здесь сложно сказать точно, создание микросервисов ― творческий процесс. Давайте рассмотрим особенности микросервисов.

 

Создание микросервисов

К принципам создания микросервисов можно отнести следующие

1. Ориентир на бизнес-возможности. Например, E-commerce сайт ― это не просто «корзина для покупок». Он обрабатывает запасы, каталоги продуктов, выставление счетов, клиентов, заказы и т. д. Здесь целесообразно использовать микросервисы. Так, функция управления запасами ― хороший кандидат на создание микросервиса.

2. Один микросервис ― одна команда. Она его разрабатывает, развёртывает и управляет. Такой подход гарантирует, что микросервис не станет слишком большим. При этом каждый разработчик в команде должен понимать микросервис в целом. Практическое правило компании Amazon гласит: чтобы накормить всю команду на любом собрании, должно хватить двух пицц. Конечно, это нечёткое указание. (Насколько велика пицца?). Лучше быть более конкретным и установить лимит от шести до восьми человек. Может ли команда из восьми человек разработать сервис управления запасами? Если да, то это может быть подходящий кандидат. В противном случае этот микросервис слишком сложен и потребует дальнейшей декомпозиции.

Возможно, у вас не выйдет создать микросервис с первого раза, но с опытом всё получится. Грамотный проект всегда предполагает гибкость. Если работа над микросервисом продвигается туго, его можно разбить на несколько.

3. Один микросервис ― одна задача. Это общий принцип для любого эффективного программного обеспечения. Микросервис должен выполнять одну функцию, причем выполнять ее хорошо. Конечно, понятие «одна функция» ― расплывчатое и подлежит обсуждению. Но стоит помнить, что микросервис должен соответствовать определённой области бизнеса. Представьте, что микросервис управления запасами также занимается расчётом налога на каждый товар. Вам может показаться, что так удобнее. Но это признак того, что где-то не хватает жизненно важного микросервиса. Возможно, в налоговой службе. Только подумайте, налоговые ставки всё время меняются. Было бы неприятно обновлять и тестировать всю службу инвентаризации каждый раз, когда появляется новый налог! Микросервисы должны как можно меньше зависеть друг от друга. Изменение одного из них должно минимально влиять на другие.

4. Самостоятельное развертывание микросервисов. Надо, чтобы каждый можно было повторно развернуть в любое время, не влияя на остальную часть системы. Представьте, что вы обнаружили ошибку в микросервисе инвентаризации. Команда может развернуть изменение в действующей системе без необходимости консультироваться с другими группами разработчиков.

Автоматизация микросервисов
 

Возможно, вы сможете смириться с неудобствами, связанными с развёртыванием монолитного приложения вручную, несколькими «облаками» для его размещения и установкой программного обеспечения на них. Но забудьте о масштабировании до 100 развёртываний или 1000 экземпляров. Микросервисы зависят от автоматизации развёртывания, инициализации и управления конфигурацией. Непрерывная интеграция или непрерывная доставка ― атрибут любого проекта микросервисов.

 

Распределение микросервисов

Микросервисы часто представляют собой распределенные системы. Вы можете развернуть все свои микросервисы на одном сервере. Или, в крайнем случае, у вас может быть один сервер для каждого микросервиса. Это был бы очень эффективный способ добиться разделения! Но для большинства проектов это будет очень дорого.

Лучшее решение ― использовать Docker (проект с открытым исходным кодом для автоматизации развёртывания приложений) для превращения каждого микросервиса в контейнер, а затем использовать инструмент оркестрации (упаковка приложений, основанных на микросервисной архитектуре) для управления запущенными контейнерами. Самый распространённый инструмент оркестровки ― Kubernetes. Kubernetes использует балансировку нагрузки и репликацию для достижения высокого уровня отказоустойчивости приложения. 

 

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

К самым большим преимуществам микросервисной архитектуры можно отнести следующие:

  1.  Модульный принцип, возможность разделения функций, слабая зависимость их друг от друга.
  2. Возможность развернуть отдельные службы в любое время. Изменения и новые функции можно вводить быстро.
  3. Каждый микросервис можно написать на любом языке по вашему выбору. Это называется «программированием полиглота». Например, финансовый микросервис лучше всего написать на Python. А службе обработки графики больше подойдёт C, так как она требует высокой производительности.
  4. Если микросервис становится проблемным, его можно выбросить и переработать с нуля.
  5. Поскольку микросервисы можно распределять, систему легко масштабировать по горизонтали. Это означает, что микросервисы можно разделить между множеством машин. Это намного дешевле, чем вертикальное масштабирование (покупка более дорогого компьютера).

     

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

Есть и недостатки микросервисных архитектур:

  1. Принципы просты, но применить их на практике сложно. Здесь нужен субъективный подход.
  2. Некоторые плохо работающие проекты переходят на микросервисы в надежде решить свои проблемы. Когда дела идут плохо, они ошибочно винят микросервисы.
  3. Необходимо наличие множества инструментов: автоматизация, непрерывная доставка, контроль версий и т. д.
  4. Запуск и тестирование микросервиса изолированно может быть затруднительным.

Направления в сфере Бизнес
Бизнес
IT
Программирование
Python
Java

Как сделать выбор между монолитом и микросервисами

Монолитное приложение целесообразно, если его может разработать и использовать одна команда. Как только вы выйдете за пределы этого размера, ваш «монолитный ад» станет невыносимым. Но нельзя просто переключиться на микросервисы и ожидать, что они решат все ваши проблемы!

Это был краткий обзор микросервисов. Больше о них можно узнать на специальных образовательных программах по web-разработке. Инвестируйте в свою карьеру в сфере IT. 

Статьи по теме Бизнес

#Программирование
#IT
#Мобильные приложения
#Лайфхаки
#Веб-разработка
#Python
#Java