Сравнение микросервисной и монолитной архитектур
Преимущества монолитной архитектуры
Организации могут извлечь выгоду как из монолитной архитектуры, так и из микросервисной в зависимости от ряда различных факторов. При использовании монолитной архитектуры удобно создавать приложения на основе одной базы кода, поэтому ее основное преимущество заключается в быстроте разработки.
К преимуществам монолитной архитектуры можно отнести следующие особенности.
Простое развертывание. Использование одного исполняемого файла или каталога упрощает развертывание.
Разработка. Приложение легче разрабатывать, когда оно создано с использованием одной базы кода.
Производительность. В централизованной базе кода и репозитории один интерфейс 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 и организовать сложные приложения в изолированные независимые сервисы.
На этом мы завершаем первую часть перевода, а о микросервисах и бессерверной архитектуре поговорим во второй части материала.
Что такое монолитная архитектура в программном обеспечении?
К
- Рахул Авати
- Айви Вигмор
Монолитная архитектура — это традиционная унифицированная модель разработки программного обеспечения.
Монолитный в данном контексте означает «составленный в единое целое». Согласно Кембриджскому словарю, прилагательное «монолитный» также означает « слишком большой» и « невозможно изменить . »
Монолитное программное обеспечение спроектировано так, чтобы быть автономным, при этом компоненты или функции программы тесно связаны, а не слабо связаны, как в модульных программах. В монолитной архитектуре каждый компонент и связанные с ним компоненты должны присутствовать для выполнения или компиляции кода и для запуска программного обеспечения.
Монолитные приложения являются одноуровневыми, что означает объединение нескольких компонентов в одно большое приложение. Следовательно, они, как правило, имеют большие кодовые базы, управлять которыми со временем может быть обременительно.
Кроме того, если необходимо обновить один компонент программы, другие элементы также могут потребовать перезаписи, и все приложение должно быть перекомпилировано и протестировано.
Этот процесс может занять много времени и может ограничить гибкость и скорость групп разработчиков программного обеспечения. Несмотря на эти проблемы, этот подход все еще используется, поскольку он предлагает некоторые преимущества. Кроме того, многие ранние приложения были разработаны как монолитное программное обеспечение, поэтому нельзя полностью игнорировать этот подход, когда эти приложения все еще используются и требуют обновлений.
Чтобы понять монолитную архитектуру, давайте рассмотрим пример банковского приложения. Веб-сайт банковского приложения сначала авторизует клиентов, регистрирует их в своей учетной записи и позволяет им совершать онлайн-переводы денег на другие счета. Во весь этот процесс вовлечено несколько компонентов, в том числе пользовательский интерфейс для клиентов, а также службы для аутентификации пользователей, загрузки выписок, денежных переводов и т.
Если приложение использует монолитную архитектуру, оно создается и развертывается как единое приложение, независимо от того, как его использует клиент. Таким образом, независимо от того, обращаются ли пользователи к приложению со своего рабочего стола или с мобильного устройства, приложение остается тесно связанным, а все различные компоненты и модули напрямую связаны друг с другом. Он также может использовать реляционную систему управления базами данных в качестве единого источника данных. Наконец, если изменения необходимы для какого-либо одного компонента, изменения кода потребуются и для всех других затронутых компонентов.
Ключевые компоненты монолитных приложений
Эти компоненты могут включать следующие функции:- Авторизация. Для авторизации пользователя и разрешения ему использовать приложение.
- Презентация. Для обработки запросов протокола передачи гипертекста и ответа с помощью языка гипертекстовой разметки, расширяемого языка разметки или нотации объектов JavaScript.
- Бизнес-логика. Базовая бизнес-логика, управляющая функциональностью и функциями приложения.
- Уровень базы данных. Включает объекты доступа к данным, которые обращаются к базе данных приложения.
- Интеграция приложений. Контролирует и управляет интеграцией приложения с другими службами или источниками данных.
Некоторые приложения могут также включать модуль уведомлений для контроля и отправки автоматических сообщений электронной почты пользователям.
Преимущества монолитной архитектуры У монолитных архитектур есть свои преимущества, поэтому многие приложения до сих пор создаются с использованием этой парадигмы разработки.
Во-первых, монолитные программы могут иметь лучшую производительность, чем модульные приложения. Их также может быть легче тестировать и отлаживать, потому что с меньшим количеством элементов в игру вступает меньше переменных тестирования и сценариев.
В начале жизненного цикла разработки программного обеспечения обычно проще использовать монолитную архитектуру, поскольку разработка может быть проще на ранних стадиях. Единая кодовая база также упрощает ведение журналов, управление конфигурацией, мониторинг производительности приложений и другие задачи разработки. Развертывание также можно упростить, скопировав упакованное приложение на сервер. Наконец, несколько копий приложения могут быть размещены за балансировщиком нагрузки для его горизонтального масштабирования.
Тем не менее, монолитный подход обычно лучше подходит для простых и легких приложений. Для более сложных приложений с частыми ожидаемыми изменениями кода или растущими требованиями к масштабируемости этот подход не подходит.
Как правило, монолитные архитектуры имеют недостатки, которые могут задерживать разработку и развертывание приложений. Эти недостатки становятся особенно существенными при увеличении сложности продукта или при увеличении размера команды разработчиков.
Базу кода монолитных приложений может быть трудно понять, поскольку она может быть обширной, что может затруднить для новых разработчиков изменение кода в соответствии с изменяющимися бизнес-требованиями или техническими требованиями. По мере того, как требования развиваются или усложняются, становится сложно правильно реализовать изменения, не снижая качество кода и не влияя на работу приложения в целом.
После каждого обновления монолитного приложения разработчики должны скомпилировать всю кодовую базу и повторно развернуть все приложение, а не только обновленную часть.
Это затрудняет непрерывное или регулярное развертывание, что затем влияет на гибкость приложения и команды.
Размер приложения также может увеличить время запуска и увеличить задержки. В некоторых случаях разные части приложения могут иметь конфликтующие требования к ресурсам. Это затрудняет поиск ресурсов, необходимых для масштабирования приложения.
Помимо ограниченной масштабируемости, еще одной проблемой монолитного программного обеспечения является надежность. Ошибка в любом компоненте потенциально может вывести из строя все приложение. В примере с банковским приложением предположим, что в модуле авторизации пользователя есть утечка памяти. Эта ошибка может вывести из строя все приложение и сделать его недоступным для всех пользователей.
Наконец, в силу своего размера и сложности монолитные приложения плохо адаптируются к новым технологиям. Новая среда разработки или язык могут повлиять на приложение в целом, поэтому их внедрение может занять много времени и средств. Небольшие организации или компании с ограниченным бюджетом могут не располагать средствами или персоналом для обновления приложения, поэтому они могут в конечном итоге сохранить статус-кво, что может привести к тому, что они не смогут воспользоваться преимуществами нового языка или платформы.
Сегодня многие организации отказываются от монолитных архитектур и внедряют архитектуру микросервисов (MSA), поскольку она предлагает множество преимуществ.
Преимущества архитектуры микросервисов MSA поддерживает модульные приложения, в которых любой отдельный модуль в системе, такой как микрослужба, может быть изменен независимо, не затрагивая другие части программы и не создавая непредвиденных изменений в других элементах.
Модульные программы также лучше адаптируются к итеративным процессам разработки и методам Agile по сравнению с монолитными программами. Они также более масштабируемы и могут тестироваться по отдельности из-за слабой связи между различными компонентами. Модули также взаимодействуют друг с другом, имеют собственные базы данных и увеличивают скорость запуска приложений.
See application architecture , software development , source code , Agile software development , Lean software development , continuous software development , комплект для разработки программного обеспечения , выпуск , артефакт и разработка программного обеспечения .
Последнее обновление: май 2022 г.
Продолжить чтение О монолитной архитектуре- Преимущества монолитной архитектуры, доказывающие, что она не умерла
- Разбейте монолиты на микросервисы за 3 шага
- Декомпозиция монолитной базы данных для микросервисов
- Распределенный монолит: что это такое и как от него избавиться
- Как спланировать и выполнить миграцию на микросервисы
распознавание изображений
Распознавание изображений в контексте машинного зрения — это способность программного обеспечения идентифицировать объекты, места, людей, надписи и действия на цифровых изображениях.
Сеть
- телематика
Телематика — термин, объединяющий слова «телекоммуникации» и «информатика» для описания использования средств связи и ИТ для …
- фильтрация пакетов
Фильтрация пакетов — это процесс пропуска или блокировки пакетов данных на сетевом интерфейсе брандмауэром на основе источника и .
.. - WAN (глобальная сеть)
Глобальная вычислительная сеть (WAN) — это географически распределенная частная телекоммуникационная сеть, которая соединяет между собой несколько локальных …
..Безопасность
- FIDO (быстрая идентификация онлайн)
FIDO (Fast Identity Online) — это набор технических спецификаций безопасности для строгой аутентификации.
- Альянс облачной безопасности (CSA)
Альянс по безопасности облачных вычислений (CSA) — это некоммерческая организация, которая продвигает исследования передовых методов обеспечения безопасности облачных …
- квантовое превосходство
Квантовое превосходство — это экспериментальная демонстрация доминирования и преимущества квантового компьютера над классическими компьютерами с помощью …
ИТ-директор
- сделка
В вычислительной технике транзакция представляет собой набор связанных задач, рассматриваемых как одно действие.
- бережливое управление
Бережливое управление — это подход к управлению организацией, который поддерживает концепцию постоянного совершенствования, долгосрочного …
- идентификатор устройства (идентификация устройства)
Идентификатор устройства (идентификация устройства) — это анонимная строка цифр и букв, которая однозначно идентифицирует мобильное устройство, такое как …
HRSoftware
- вовлечения сотрудников
Вовлеченность сотрудников — это эмоциональная и профессиональная связь, которую сотрудник испытывает к своей организации, коллегам и работе.
- кадровый резерв
Кадровый резерв — это база данных кандидатов на работу, которые могут удовлетворить немедленные и долгосрочные потребности организации.
- разнообразие, равенство и инклюзивность (DEI)
Разнообразие, равенство и инклюзивность — термин, используемый для описания политики и программ, которые способствуют представительству и .
..
..Служба поддержки клиентов
- лид, квалифицированный продуктом (PQL)
Лид, квалифицированный по продукту (PQL), — это физическое или юридическое лицо, которое получило выгоду от использования продукта в результате бесплатного …
- квалифицированный маркетолог лид (MQL)
Квалифицированный маркетолог (MQL) — это посетитель веб-сайта, уровень вовлеченности которого указывает на то, что он может стать клиентом.
- успех клиента
Успех клиента — это стратегия, направленная на то, чтобы продукция компании отвечала потребностям клиента.
Микросервисы против монолитной архитектуры | Atlassian
Преимущества монолитной архитектуры
Организации могут извлечь выгоду из монолитной или микросервисной архитектуры, в зависимости от ряда различных факторов. При разработке с использованием монолитной архитектуры основным преимуществом является высокая скорость разработки из-за простоты наличия приложения, основанного на одной кодовой базе.
К преимуществам монолитной архитектуры относятся:
Простое развертывание — Один исполняемый файл или каталог упрощает развертывание.
Разработка — Когда приложение создается с использованием одной кодовой базы, его легче разрабатывать.
Производительность . В централизованной кодовой базе и репозитории один API часто может выполнять ту же функцию, которую многочисленные API выполняют с микросервисами.
Упрощенное тестирование . Поскольку монолитное приложение представляет собой единую централизованную единицу, сквозное тестирование может быть выполнено быстрее, чем с распределенным приложением.
Простая отладка . Весь код находится в одном месте, поэтому проще выполнить запрос и найти проблему.
Недостатки монолитной архитектуры
Как и в случае с Netflix, монолитные приложения могут быть весьма эффективными до тех пор, пока они не станут слишком большими и масштабирование не станет проблемой.
Внесение небольшого изменения в одну функцию требует компиляции и тестирования всей платформы, что противоречит гибкому подходу, которому отдают предпочтение современные разработчики.
К недостаткам монолита относятся:
Более низкая скорость разработки. – Большое монолитное приложение делает разработку более сложной и медленной.
Масштабируемость — Вы не можете масштабировать отдельные компоненты.
Надежность . Ошибка в любом модуле может повлиять на доступность всего приложения.
Барьер для внедрения технологии — Любые изменения в структуре или языке влияют на все приложение, что часто делает изменения дорогостоящими и трудоемкими.
Отсутствие гибкости – Монолит ограничен уже используемыми в монолите технологиями.
Развертывание — небольшое изменение в монолитном приложении требует повторного развертывания всего монолита.
Что такое микросервисы?
Архитектура микрослужб, также называемая просто микрослужбами, представляет собой архитектурный метод, основанный на ряде независимо развертываемых служб. Эти сервисы имеют свою бизнес-логику и базу данных с определенной целью. Обновление, тестирование, развертывание и масштабирование происходят внутри каждой службы. Микросервисы разделяют основные бизнес-задачи, связанные с предметной областью, на отдельные независимые базы кода. Микросервисы не уменьшают сложность, но делают любую сложность видимой и более управляемой, разделяя задачи на более мелкие процессы, которые функционируют независимо друг от друга и вносят свой вклад в общее целое.
Внедрение микросервисов часто идет рука об руку с DevOps, поскольку они являются основой для методов непрерывной доставки, которые позволяют командам быстро адаптироваться к требованиям пользователей.
Путь Atlassian к микросервисам
Atlassian пошла по пути микросервисов в 2018 году после того, как столкнулась с проблемами роста и масштабирования с Jira и Confluence.
Мы обнаружили, что наши однопользовательские монолитные архитектуры, работающие локально, не смогут масштабироваться в соответствии с будущими потребностями.
Мы решили изменить архитектуру Jira и Confluence и перенести их из однопользовательской монолитной системы с отслеживанием состояния в многопользовательские облачные приложения без сохранения состояния, размещенные на Amazon Web Services (AWS). Затем мы со временем разложили бы их на микросервисы. Проект получил название «Головокружение» после того, как старший инженер сказал: «Мне очень нравится эта идея, но она вызывает у меня головокружение». На сегодняшний день это был наш крупнейший инфраструктурный проект: на завершение перехода на AWS ушло два года, в результате чего более 100 000 клиентов перешли чуть более чем за 10 месяцев без перерывов в обслуживании. Мы также взяли на себя обязательство разделить сервисы на микросервисы.
Преимущества микросервисов
Микросервисы ни в коем случае не панацея, но они решают ряд проблем для растущего программного обеспечения и компаний.
Поскольку архитектура микросервисов состоит из модулей, работающих независимо друг от друга, каждый сервис можно разрабатывать, обновлять, развертывать и масштабировать, не затрагивая другие сервисы. Обновления программного обеспечения можно выполнять чаще, что повышает надежность, время безотказной работы и производительность. Мы перешли от отправки обновлений один раз в неделю к двум-трем раза в день.
По мере роста Atlassian микросервисы позволяют нам более надежно масштабировать команды и географические местоположения за счет разделения по линиям владения сервисами. До того, как мы запустили Vertigo, у Atlassian было пять различных центров разработки по всему миру. Эти распределенные команды были ограничены централизованным монолитом, и нам нужно было поддерживать их автономным образом. Микросервисы позволяют нам это делать.
Преимущества Vertigo включают повышенную скорость развертывания, аварийное восстановление, снижение затрат и более высокую производительность.
Это позволяет нам быстрее достигать нашей цели, одновременно предоставляя клиентам дополнительную ценность.
Кроме того, микросервисы упрощают для команд обновление кода и ускоряют циклы выпуска благодаря непрерывной интеграции и непрерывной доставке (CI/CD). Команды могут экспериментировать с кодом и откатываться, если что-то пойдет не так.
Вкратце, преимущества микросервисов таковы:
Гибкость . Продвигайте гибкие способы работы с небольшими командами, которые часто развертываются.
Гибкое масштабирование . Если микросервис достигает предела своей нагрузки, новые экземпляры этого сервиса можно быстро развернуть в соответствующем кластере, чтобы уменьшить нагрузку. Теперь мы работаем с несколькими арендаторами и не имеем гражданства, а клиенты распределены по нескольким экземплярам. Теперь мы можем поддерживать гораздо большие размеры экземпляров.
Непрерывное развертывание . Теперь у нас частые и более быстрые циклы выпуска.
Раньше мы выпускали обновления раз в неделю, а теперь можем делать это два-три раза в день.
Легко поддерживать и тестировать . Команды могут экспериментировать с новыми функциями и откатывать их, если что-то не работает. Это упрощает обновление кода и ускоряет вывод новых функций на рынок. Кроме того, легко изолировать и исправлять сбои и ошибки в отдельных службах.
Возможность независимого развертывания . Поскольку микросервисы представляют собой отдельные единицы, они позволяют быстро и легко независимо развертывать отдельные функции.
Технологическая гибкость . Микросервисные архитектуры позволяют командам свободно выбирать нужные им инструменты.
Высокая надежность — вы можете развернуть изменения для конкретной службы без угрозы остановки всего приложения.
Более довольные команды . Команды Atlassian, которые работают с микросервисами, намного счастливее, поскольку они более автономны и могут создавать и развертывать себя, не дожидаясь одобрения запроса на вытягивание неделями.
Недостатки микросервисов
Когда мы перешли от небольшого количества монолитных кодовых баз к большому количеству распределенных систем и сервисов, лежащих в основе наших продуктов, возникла непреднамеренная сложность. Сначала мы изо всех сил пытались добавить новые возможности с той же скоростью и уверенностью, что и в прошлом. Микросервисы могут добавить повышенную сложность, что приведет к разрастанию разработки или быстрому и неуправляемому росту. Может быть сложно определить, как разные компоненты связаны друг с другом, кому принадлежит конкретный программный компонент или как избежать вмешательства в зависимые компоненты.
С Vertigo мы создали общую функциональность, которая будет поддерживать наши существующие продукты и будущие продукты, которые мы приобретаем и создаем. Если вы работаете с одним продуктом, микросервисы могут не понадобиться.
К недостаткам микросервисов можно отнести:
Разрастание разработки .
Микросервисы усложняют работу по сравнению с монолитной архитектурой, поскольку существует больше сервисов в большем количестве мест, созданных несколькими командами. Если разрастание разработки не контролируется должным образом, это приводит к снижению скорости разработки и снижению производительности.
Экспоненциальные затраты на инфраструктуру . Каждая новая микрослужба может иметь собственную стоимость набора тестов, сценариев развертывания, инфраструктуры хостинга, инструментов мониторинга и т. д.
Добавлены организационные накладные расходы — командам необходимо добавить еще один уровень коммуникации и совместной работы для координации обновлений и интерфейсов.
Проблемы отладки — у каждой микрослужбы есть собственный набор журналов, что усложняет отладку. Кроме того, один бизнес-процесс может выполняться на нескольких компьютерах, что еще больше усложняет отладку.
Отсутствие стандартизации.
. Без общей платформы может произойти распространение языков, стандартов ведения журналов и мониторинга.
Отсутствие четкого права собственности — Чем больше сервисов вводится, тем больше становится количество команд, использующих эти сервисы. Со временем становится трудно узнать, какие услуги команда может использовать и к кому обратиться за поддержкой.
Советы Atlassian по переходу с монолитной архитектуры на микросервисную
Многие проекты изначально начинаются как монолит, а затем развиваются в микросервисную архитектуру. По мере добавления новых функций в монолит может стать обременительным, когда многие разработчики работают над единой кодовой базой. Конфликты кода становятся более частыми, и увеличивается риск обновления одной функции, приводящей к ошибкам в несвязанной функции. Когда возникают эти нежелательные шаблоны, возможно, пришло время подумать о переходе на микросервисы.
Ниже приведены некоторые из лучших практик, которые мы извлекли из нашей миграции:
Планирование стратегии миграции
Мы потратили значительное количество времени на определение последовательности того, как мы хотим мигрировать клиентов.
Мы знали, что многие из наших клиентов будут иметь другие профили и другую динамику использования после их миграции, поэтому мы заранее спланировали это заранее.
Инструменты
Правильные инструменты необходимы при миграции микросервисов. Мы не сразу мигрировали клиентов, а сначала инвестировали и создали инструменты для миграции, зная, что это будет марафон, а не спринт. Самым важным инструментом, который мы создали, был Microscope, наш собственный внутренний каталог сервисов для отслеживания всех микросервисов. Каждый разработчик в Atlassian может использовать Microscope для просмотра всей информации о любом микросервисе в компании.
Мы также создали в Microscope инструмент под названием ServiceQuest, который автоматически обнаруживает проверки кода перед его выпуском, включая проверки качества, дизайна услуг, конфиденциальности, безопасности и надежности.
Кроме того, на основе наших технологических стеков был создан инструмент. У нас есть внутренняя служба, которая позволяет нам запускать новую службу в определенном стеке, и это предшествует таким вещам, как ведение журнала, мониторинг и кэширование.
Наконец, мы максимально автоматизировали, в том числе и сам процесс миграции. Мы создали собственную панель инструментов для эффективного просмотра всех миграций в режиме реального времени.
Управляйте ожиданиями
Для трансформации компании требуется спонсор из высшего руководства, который отвечает за результаты и готов добиваться необходимых компромиссов, — сказал Шри Вишванат, технический директор Atlassian. Этот человек должен позволить организации инвестировать в новые инструменты, системы и процессы, чтобы сделать улучшения постоянными.
В связи с масштабной миграцией инфраструктуры, в которой задействовано множество людей, бизнес хочет знать о возврате инвестиций, — сказал Майк Триа, руководитель отдела платформ Atlassian. Очень важно поддерживать связь с исполнительной командой, заинтересованными сторонами, клиентами, партнерами и остальными командами НИОКР. Убедитесь, что они знают, что вы делаете, включая ожидаемые выгоды. Кроме того, обязательно отмечайте успехи.
Примите смену культуры
«Культура имеет большое значение в таких масштабных проектах», — сказал Вишванат. «Вы хотите убедиться, что когда возникает проблема, она просачивается каждый раз». Когда вы выполняете миграцию, это не просто техническая миграция, а изменение людей и организации. Atlassian в 2015 году был «написать код и перебросить его через стену» для операционной группы, которая его запускала и развертывала. К концу 2017 года мы внедрили культуру DevOps, согласно которой «вы создаете это, вы запускаете это», когда каждый разработчик в Atlassian использует свои собственные сервисы.
«Я потратил больше времени на то, чтобы убедиться, что наша команда SRE добилась успеха в этом проекте, чем почти на любую другую работу, которую я делал во время проекта, потому что культурный сдвиг был самым большим долгосрочным изменением для Atlassian в результате Vertigo», Tria сказал.
Баланс скорости и доверия
Головокружение можно было сделать намного быстрее.
По прошествии первых четырех месяцев мы выполнили 80% миграций. Мы могли бы перенести последнюю часть пользователей, хотя и не могли гарантировать, что они будут обладать той надежностью и производительностью, которые нам нужны. Мы придерживаемся одной из основных ценностей Atlassian: не #@!% клиента.
Вместе с нашими инженерами мы создали систему сдержек и противовесов, чтобы поддерживать высокую надежность, и мы соблюдали высокие стандарты, к которым стремились. Потому что, если вы построите его правильно с первого раза, вы сэкономите время и сэкономите головную боль в долгосрочной перспективе.
Когда мы добрались до последних 500 клиентов, которых было труднее всего мигрировать, мы использовали интеграцию Jira Software и Trello, чтобы назначить каждого клиента инженеру Atlassian.
Вкратце…
В январе 2016 года у нас было около 15 микросервисов. Теперь у нас их более 1300. Мы перевели 100 000 клиентов в облако, попутно построили новую платформу, трансформировали нашу культуру и в итоге получили новые инструменты.