Монолитная это: МОНОЛИТНЫЙ | это… Что такое МОНОЛИТНЫЙ?

Монолитная vs Микросервисная архитектура

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

Монолитное приложение (назовем его монолит) представляет собой приложение, доставляемое через единое развертывание. Таким является приложение, доставленное в виде одной WAR или приложение Node с одной точкой входа.

Пример

Давайте представим классический интернет-магазин. Стандартные модули: UI, бизнес-логика и дата-слой. Возможны способы взаимодействия с сервисом: API REST и веб-интерфейс.

При построении монолита все эти вещи будут управляться внутри одного и того же модуля. Я не написал «один и тот же процесс», так как это было бы неверно для сценариев, в которых несколько экземпляров нашего модуля будут работать для более высоких нагрузок.

Рассмотрите пример на следующем рисунке, где все части находятся в одном и том же модуле развертывания:

Достоинства

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

Еще одна вещь — это сквозные (E2E) тесты. В монолитной архитектуре их легче выполнить.

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

Теперь давайте рассмотрим негативный аспект монолитной архитектуры.

Недостатки

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

Это перерождение замедляет процесс разработки: каждую будущую функцию будет сложнее развивать. Из-за того что компоненты растут вместе, их также необходимо менять вместе. Создание новой функции может означать прикосновение к 5 различным местам: 5 мест, в которых вам нужно написать тесты; 5 мест, которые могут иметь нежелательные побочные эффекты для существующих функций.

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

В монолите практически нет изоляции. Проблема или ошибка в модуле может замедлить или разрушить все приложение.

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

Что такое микросервисная архитектура?

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

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

По сравнению с монолитом в микросервисах у вас есть несколько единиц развертывания. Каждый сервис развертывается самостоятельно.

Пример

Давайте вновь рассмотрим в качестве примера Интернет-магазин.

Как и раньше, у нас есть: UI, бизнес-логика и дата-слой.

Здесь отличие от монолита состоит в том, что у всех вышеперечисленных есть свой сервис и своя база данных. Они слабо связаны и могут взаимодействовать с различными протоколами (например, REST, gRPC, обмен сообщениями) через свои границы.

На следующем рисунке показан тот же пример, что и раньше, но с разложением на микроуслуги.

Каковы преимущества и недостатки этого варианта?

Достоинства

Микросервисы легче держать модульными. Технически это обеспечивается жесткими границами между отдельными сервисами.

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

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

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

Более короткое время запуска и возможность развертывания микросервисов независимо друг от друга действительно выгодны для CI / CD. По сравнению с обычным монолитом он намного плавнее.

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

В микросервисах изолируемые разломы лучше по сравнению с монолитным подходом. Хорошо спроектированная распределенная система переживет сбой одного сервиса.

Недостатки

Все звучит довольно хорошо, но есть и недостатки.

Распределенная система имеет свою сложность: в ней вам приходится иметь дело с частичным отказом, более затруднительным взаимодействием при тестировании (тесты E2E), а также с более высокой сложностью при реализации взаимодействия между сервисами.

Транзакции легче проводить в монолите. Решением этой проблемы на микросервисах является Saga Pattern. Хорошее решение, но все же слишком громоздкое для реализации на практике.

Существуют эксплуатационные накладные расходы, а множество микросервисов сложнее в эксплуатации, чем несколько экземпляров сигнального монолита.

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

Изменения, затрагивающие несколько сервисов, должны координироваться между несколькими командами, а это может быть сложно, если команды еще не имели контактов.

Заключение

Все зависит от вашей организационной структуры. У вас есть 6 команд, которые будут работать над одним продуктом? Микросервисы могут подойти.

У вас есть команда из 3 разработчиков? Вероятно, они будут хорошо строить и поддерживать монолит.

Другими факторами являются скорость изменения и сложность. Высокие темпы изменений и высокая сложность могут быть факторами, которые заставляют выбрать архитектуру микросервиса.

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

Сравнение микросервисной и монолитной архитектур

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

Организации могут извлечь выгоду как из монолитной архитектуры, так и из микросервисной в зависимости от ряда различных факторов. При использовании монолитной архитектуры удобно создавать приложения на основе одной базы кода, поэтому ее основное преимущество заключается в быстроте разработки.

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

Простое развертывание. Использование одного исполняемого файла или каталога упрощает развертывание.

Разработка. Приложение легче разрабатывать, когда оно создано с использованием одной базы кода.

Производительность. В централизованной базе кода и репозитории один интерфейс API часто может выполнять ту функцию, которую при работе с микросервисами выполняют многочисленные API.

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

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

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

Как и в случае с Netflix, монолитные приложения работают достаточно эффективно до тех пор, пока они не становятся слишком большими и не вызывают проблем с масштабированием. Чтобы внести небольшое изменение в одну функцию, необходимо выполнить компиляцию и тестирование всей платформы, что противоречит agile-подходу, которому отдают предпочтение современные разработчики.

К недостаткам монолитной архитектуры можно отнести следующие особенности.

Снижение скорости разработки. Большое монолитное приложение усложняет и замедляет разработку.

Масштабируемость. Невозможно масштабировать отдельные компоненты.

Надежность. Ошибка в одном модуле может повлиять на доступность всего приложения.

Препятствия для внедрения технологий. Любые изменения в инфраструктуре или языке разработки влияют на приложение целиком, что зачастую приводит к увеличению стоимости и временных затрат.

Недостаточная гибкость. Возможности монолитных приложений ограничены используемыми технологиями.

Развертывание. При внесении небольшого изменения потребуется повторное развертывание всего монолитного приложения.

Что такое микросервисы?

Микросервисная архитектура (или просто «микросервисы») представляет собой метод организации архитектуры, основанный на ряде независимо развертываемых служб. У этих служб есть собственная бизнес-логика и база данных с конкретной целью. Обновление, тестирование, развертывание и масштабирование выполняются внутри каждой службы. Микросервисы разбивают крупные задачи, характерные для конкретного бизнеса, на несколько независимых баз кода. Микросервисы не снижают сложность, но они делают любую сложность видимой и более управляемой, разделяя задачи на более мелкие процессы, которые функционируют независимо друг от друга и вносят вклад в общее целое.

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

Переход Atlassian к микросервисам

Компания Atlassian начала переход к микросервисам в 2018 году после того, как столкнулась с проблемами роста и масштабирования Jira и Confluence. Мы обнаружили, что наши монолитные архитектуры с одним держателем, работающие в локальной среде, не получится масштабировать в соответствии с будущими потребностями.

Мы решили изменить архитектуру Jira и Confluence и перенести эти продукты из монолитной системы с одним держателем и сохранением состояния в облачные приложения с несколькими держателями и без сохранения состояния, размещенные в Amazon Web Services (AWS). Затем мы решили, что постепенно разобьем эти приложения на микросервисы. Проект получил название «Головокружение», которое появилось после того, как старший разработчик сказал: «Мне очень нравится эта идея, но от нее голова идет кругом». Это наш крупнейший инфраструктурный проект: переход на AWS занял два года, в результате чего всего за 10 месяцев нам удалось перенести более 100 000 клиентов без перерывов в обслуживании. Кроме того, мы собираемся разбить службы на микросервисы.

Преимущества микросервисов

Микросервисы не являются волшебной палочкой, но они решают ряд проблем, с которыми сталкиваются растущие компании при развитии ПО. Поскольку архитектура микросервисов состоит из независимо работающих модулей, каждую службу можно разрабатывать, обновлять, развертывать и масштабировать отдельно от остальных. Обновления можно выполнять чаще, повышая надежность, время бесперебойной работы и производительность программного обеспечения. Раньше мы выпускали обновления раз в неделю, а теперь делаем это до двух-трех раз в день.

Благодаря микросервисам мы можем увереннее масштабировать команды и географические области по мере роста Atlassian за счет разделения по линиям владения службами. Перед тем как мы начали работу над проектом «Головокружение», у Atlassian было пять разных центров разработки по всему миру. Возможности этих распределенных команд были ограничены централизованным монолитом, и нам нужно было поддерживать их автономно. Микросервисы позволяют нам это делать.

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

Кроме того, микросервисы упрощают для команд обновление кода и ускоряют циклы релиза благодаря непрерывной интеграции и непрерывной поставке (CI/CD). Команды могут поэкспериментировать с кодом и вернуться к предыдущей версии, если что-то пойдет не так.

Таким образом, микросервисы дают следующие преимущества.

Гибкость. Продвигайте гибкие методы работы среди небольших команд, которые регулярно выполняют развертывание.

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

Непрерывное развертывание. Теперь у нас есть регулярные и ускоренные циклы релиза. Раньше мы выпускали обновления раз в неделю, а теперь можем делать это примерно два-три раза в день.

Легкость обслуживания и тестирования. Команды могут экспериментировать с новыми функциями и возвращаться к предыдущей версии, если что-то не работает. Это упрощает обновление кода и ускоряет выпуск новых функций на рынок. Кроме того, в отдельных службах легко находить и исправлять ошибки и баги.

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

Гибкость технологий. При использовании архитектуры микросервисов команды могут выбирать инструменты с учетом своих предпочтений.

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

Довольные команды. Команды Atlassian, работающие с микросервисами, гораздо лучше отзываются о своей работе благодаря автономности и возможности самостоятельно создавать и развертывать приложения, не дожидаясь одобрения запроса pull в течение нескольких недель.

Недостатки микросервисов

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

С помощью проекта «Головокружение» мы создали общие функциональные возможности, которые станут основой существующих и будущих продуктов (как приобретенных, так и разработанных самостоятельно). Если ваша компания разрабатывает только один продукт, микросервисы могут и не понадобиться.

К недостаткам микросервисов можно отнести следующие особенности.

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

Экспоненциальный рост расходов на инфраструктуру. У каждого нового микросервиса может быть своя стоимость комплекта тестов, инструкций по развертыванию, инфраструктуры хостинга, инструментов мониторинга и т. д.

Дополнительные организационные расходы. Командам требуется дополнительный уровень коммуникации и сотрудничества, чтобы координировать работу над обновлениями и интерфейсами.

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

Отсутствие стандартизации. Без общей платформы может возникнуть ситуация, в которой расширяется список языков, стандартов ведения журналов и средств мониторинга.

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

Советы Atlassian по переходу с монолитной архитектуры на архитектуру микросервисов

Многие проекты начинаются как монолитные, а затем, по мере развития, переходят к архитектуре микросервисов. По мере добавления в монолитный проект новых возможностей рано или поздно возникают сложности при работе нескольких разработчиков с единой базой кода. Учащаются конфликты в коде и увеличивается риск того, что при обновлении одной возможности появятся баги в другой, не связанной возможности. Если такие нежелательные ситуации возникают, возможно, настало время обсудить переход на микросервисы.

Ниже приведены рекомендации, которые мы сформулировали в процессе перехода.

Составьте стратегию перехода

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

Инструменты

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

Мы также создали в Microscope инструмент под названием ServiceQuest, с помощью которого можно автоматически обнаружить проверки кода перед развертыванием в рабочей среде, в том числе проверки качества, проектирования служб, конфиденциальности, безопасности и надежности.

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

Управляйте ожиданиями

«Чтобы трансформировать компанию, нужен старший исполнительный спонсор, который отвечает за результаты и готов принимать необходимые компромиссные решения», — сказал Шри Вишванат, технический директор Atlassian. Этот человек должен помочь организации инвестировать в новые инструменты, системы и процессы, чтобы сделать улучшения постоянными.

«При проведении масштабного переноса инфраструктуры с привлечением большого количества людей компания хочет знать об окупаемости инвестиций», — сказал Майк Триа, директор по разработке платформы в Atlassian. Очень важно поддерживать связь с руководящей группой, заинтересованными сторонами, клиентами, партнерами и остальными командами из отдела разработки. Убедитесь, что они понимают ваш замысел и представляют ожидаемые преимущества. Кроме того, не забывайте отмечать успехи.

Поддерживайте изменение культуры разработки

«Культура разработки имеет большое значение в таких масштабных проектах, — сказал Вишванат. — Необходимо сделать так, чтобы в коллективе всегда узнавали о новых проблемах». Переход — это технический процесс, который в том числе предполагает изменения на уровне сотрудников и организации. В 2015 году в компании Atlassian программисты писали код и «перебрасывали его через стену» команде по эксплуатации, которая запускала и развертывала приложение. К концу 2017 года мы внедрили культуру DevOps с принципом «кто разработал, тот и поддерживает», согласно которому каждый разработчик в Atlassian самостоятельно следит за работой своих служб.

«В ходе этого проекта я потратил больше всего времени на то, чтобы помочь команде по техническому обеспечению надежности сайта успешно выполнить задачи, потому что изменение культуры разработки стало самым большим долгосрочным изменением для Atlassian в результате работы над проектом «Головокружение»», — сказал Триа.

Сохраняйте баланс между скоростью и доверием

Проект «Головокружение» можно было завершить намного быстрее. За первые четыре месяца мы выполнили 80 % переносов. Мы могли бы перенести последнюю часть пользователей, однако у нас не было гарантии, что они получат ожидаемую надежность и производительность. Мы решили следовать одной из основных ценностей Atlassian — «Не #@!% клиента».

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

Когда мы добрались до последних 500 клиентов, которых было сложнее всего перенести, мы назначили каждого из них разработчику Atlassian с помощью интеграции Jira Software и Trello.

Подведем итог…

В январе 2016 года у нас было около 15 микросервисов. Сейчас их более 1300. Мы перенесли 100 000 клиентов в облако, разработали при этом новую платформу, изменили нашу культуру разработки и в итоге создали новые инструменты. Теперь у нас есть довольные автономные команды и более развитая культура DevOps.

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

Поскольку во многих организациях используются микросервисы с распределенной архитектурой, компания Atlassian разработала продукт Compass, предназначенный для управления сложными распределенными архитектурами по мере их масштабирования. Это расширяемая платформа для разработчиков, которая объединяет разрозненные сведения по сотрудничеству и всем результатам разработки в едином центре с возможностью поиска.

Подробнее о Compass

Chandler Harris

Чендлер Харрис — специалист по маркетинговым стратегиям и писатель для Atlassian. Он написал более 40 публикаций на различные темы, такие как технологии, наука, бизнес, финансы и образование.

Поделитесь этой статьей

Что такое монолит? | Определение из TechTarget

К

• Айви Вигмор

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

Несколько примеров использования этого термина в ИТ:

 Монолитная архитектура – это традиционная модель программирования, что означает, что элементы программы переплетены и взаимозависимы. Эта модель контрастирует с более поздними модульными подходами, такими как микросервисная архитектура (MSA).

Монолитная интегральная схема (ИС) представляет собой набор схем на одной полупроводниковой пластине или кристалле, а не состоит из отдельных элементов, как дискретная схема.

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

Монолитная корпорация – это крупная отдельная и недиверсифицированная организация.

В общем контексте монолит – это отдельная, крупная каменная конструкция, которая может быть географической или искусственной. Примеры включают гору, которая не является частью хребта, стоячий камень и памятник. Слово происходит от древнегреческого