Что значит монолитную структуру: монолитная структура | Перевод монолитная структура?

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

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

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

Что означает монолитная конструкция?

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

Реклама

Trenchlesspedia Объясняет монолитную конструкцию

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

Реклама

Поделись этим термином

Связанные термины

• Ремонт люков
• Восстановление канализации
• Бетон, армированный стекловолокном

• Инфильтрация/приток
• Герметизация швов

Похожие материалы

• Мы должны копать: ремонт люков в небольшом городе
• Взгляд на реконструкцию структурных люков
• Сложный мир канализационных сетей
• Нужны ли обходы дорожного движения для бестраншейных проектов?
• Замена футеровки труб: бестраншейная альтернатива замене труб
• Как сделать ставку на этот бестраншейный городской проект

Теги

Материалы для труб, отвержденных на местеБестраншейное строительствоБестраншейная реабилитация

Актуальные статьи

Бестраншейная реабилитация

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

Бестраншейное строительство

Понимание 4 этапов исследования места

Бестраншейная реабилитация

Как узнать, есть ли в вашем доме асбестоцементные трубы

Бестраншейное строительство

Микротоннелирование против.

Горизонтально-направленное бурение: понимание различий между этими ключевыми бестраншейными методами

Микросервисы против монолитной архитектуры | 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 клиентов в облако, попутно построили новую платформу, трансформировали нашу культуру и в итоге получили новые инструменты. У нас более счастливые, автономные команды и лучшая культура DevOps.

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