Что значит монолитная структура: Значение, Определение, Предложения . Что такое монолитная структура

Содержание

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

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

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

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

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

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

Производительность. В централизованной базе кода и репозитории один интерфейс 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 публикаций на различные темы, такие как технологии, наука, бизнес, финансы и образование.

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

монолит, SOA, микросервисы или бессерверная?.. Часть 1 / Хабр

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


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

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

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

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

Несмотря на то, что у нас был положительный опыт использования микросервисов в Google, мы [в Scaylr] пошли по монолитному маршруту, потому что наличие одного монолитного сервера предполагает меньше работы для нас как для двух инженеров.
Стивен Червински, руководитель отдела проектирования в Scaylr

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

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


Упрощенная разработка и развертывание

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

Меньше сквозных проблем

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

Лучшая производительность

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

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

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


Кодовая база со временем становится громоздкой

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

Сложно внедрять новые технологии

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

Ограниченная гибкость

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

В итоге

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

SOA

Сервис-ориентированная архитектура (далее SOA — service-oriented architecture) — это стиль архитектуры программного обеспечения, который предполагает модульное приложение, состоящее из дискретных и слабосвязанных программных агентов, которые выполняют конкретные функции. SOA разделяет компоненты по двум основным ролям: поставщик и потребитель сервисов. Обе эти роли могут играть программные агенты. Концепция SOA заключается в следующем: приложение может быть спроектировано и построено таким образом, что его модули легко интегрируются и могут быть легко использованы повторно.

Плюсы SOA


Повторное использование сервисов

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

Легкость в сопровождении

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

Более высокая надежность

Службы легче отлаживать и тестировать, чем огромные куски кода, как в монолитах. Это, в свою очередь, делает продукты на основе SOA более надежными.

Параллельная разработка

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

Минусы SOA


Сложность в управлении

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

Высокие инвестиционные затраты

Разработка SOA требует значительных предварительных инвестиций в человеческие ресурсы, технологии и разработку.

Дополнительная нагрузка

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

В итоге

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

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

Определение

в кембриджском словаре английского языка

Примеры монолитных

монолитных

Когда-то монолитных звукозаписывающих компаний утратили свою власть.

Из NPR