Сегодня особую популярность получила микросервисная архитектура веб-приложений. У такого подхода есть много известных сторонников. К ним относятся Facebook, Uber, Groupon, Klarna, Amazon, Netflix, eBay, Comcast и другие. Но насколько необходим подобный подход в каждом конкретном случае?
Когда нужны микросервисы?
У микросервисов есть ряд предполагаемых преимуществ. Почему предполагаемых? Дело в том, что их можно получить не только с помощью микросервисов. А большую часть, если даже не все преимущества, можно получить и с помощью монолита.
Микросервисная модель действительно делает приложение более гибким, позволяет перейти на другой уровень решения имеющихся проблем.
Но за все приходится платить, и за микросервисы тоже. Они, как известно, очень дорого обходятся в создании и при обслуживании.
Если вам нужна эта дополнительная гибкость? Прекрасно. Тогда на микросервисы стоит обратить внимание. Возможно, дополнительные затраты в конечном итоге окупятся.
А если нет? Вы серьезно перегрузите стек используемых технологий, что может затруднить для клиента взаимодействие с приложением.
Рассмотрим основные преимущества микросервисов и подумаем, как можно добиться подобных с помощью монолита.
Масштабируемость
Каждая функция микросервисного приложения выполняется на собственных ресурсах, которые могут масштабироваться независимо друг от друга. Конечно, это позволяет эффективно ��онтролировать предоставляемые функциям ресурсы.
Но насколько необходим подобный уровень контроля? Какую загруженность испытывают разные функции приложения? Свойственно ли им индивидуальное масштабирование? Какие у каждой функции требования к ЦП, памяти, хранилищу и графическому процессору?
Добавляем ресурсы, устраняем проблемы монолита
Для многих команд проблему недостатка ресурсов во многих ситуациях проще решить за счет масштабирования аппаратных средств. Т. е. в большинстве случаев детальная оптимизация работающей инфраструктуры ПО экономически нецелесообразна.
Проблемы с производительностью и функционированием в монолите, скорее всего, легче устранить, чем переходить на новый шаблон архитектуры. Конкретное решение зависит от стека используемых технологий, но не потребует особых усилий.
Распределите трафик на независимо масштабируемые кластеры
Если у вас несколько серверов, размещайте перед ними какой-нибудь балансировщик нагрузки. Можно конфигурировать этот балансировщик для маршрутизации трафика в независимо масштабируемые кластеры экземпляра вашего приложения.
Также с помощью независимо масштабируемых очередей можно переносить асинхронные задачи в фоновые задания. Убедитесь, что у вас достаточно очередей для сокращения затрат на инфраструктуру.
Изоляция отказов
Серьезным преимуществом правильно спроектированной архитектуры микросервисов является отсутствие влияния при сбое одной из функций на остальные.
Маршрутизация трафика в изолированные кластеры
Обеспечить определенную степень защиты от сбоев также может идея маршрутизации различных видов трафика в кластеры масштабирования.
Проанализируйте причины прошлых ошибок. Это позволит наилучшим образом распределить трафик. Если есть нестабильная второстепенная функция, которая часто вызывает общий сбой, возможно, стоит направить ее конечную точку в собственный кластер экземпляров приложения. Если есть проблемные фоновые задания, поместите их в их собственную очередь, которая не влияет на другие задания.
Автоматизированное тестирование
Профилактика лучше, чем лечение. Если можно предотвратить или хотя бы сократить ошибки и сбои, тогда придется гораздо меньше беспокоиться об их изоляции.
Формирование навыков тестирования является ключевым фактором уверенности в качестве программного продукта, в его способности надежно обеспечивать требуемую функциональность даже при рабочей нагрузке.
Язык программирования и технологический агностицизм
Не стоит использовать дополнительные языки и технологии вне рамок отдельных сервисов. Как правило, излишняя свобода в выборе языков и технологий может привести к фрагментации и чрезмерно сложному технологическому стеку.
Оцените наглядность и упорядоченность монолита.
Если по специфическим доменным требованиям для конкретных функций нужны специализированные языки, можно рассмотреть возможность использования отдельных сервисов. Следует сравнительно оценить выгоду, которую приносит любая дополнительная технология, с сопутствующими ей затратами на обслуживание.
Безопасность данных
Есть мнение, что защитить монолит сложно, но микросервисы только усложняют эту задачу. Увеличивая сложность стека, вы расширяете зону атаки.
Понятно, что выделение функций в разные сервисы позволяет применять разные уровни безопасности и активности к каждой из них. Однако подумайте, насколько необходим такой уровень контроля.
Не проще ли будет обезопасить весь монолит на самом высоком по необходимости уровне? А есть ли у вас вообще разные требования к безопасности данных?
Автономность команд
Я сторонник автономных групп разработчиков разного профиля. Но не совсем понимаю, откуда для этого появилась идея введения сетевого разграничения.
Предоставление каждой команде в монопольное пользование определенных автономных (изолированных) систем может показаться способом повышения автономии, но на самом деле это может сработать и против нее.
Представим, что одной команде нужно частично изменить функциональность, которой владеет другая команда. В архитектуре микросервисов, вероятно, придется использовать их знания и опыт работы с этим сервисом, чтобы внести туда изменения. Возможно, даже придется подождать, пока они это сделают. Если функция находится в монолите, тогда с большой вероятностью я уже знаком с кодом или, по крайней мере, с его соглашениями.
Степень автономности команд зависит от уровней модульности и согласованности системы. Ни монолит, ни микросервисы ничего не гарантируют и не ограничивают в этом отношении. Следствием микросервисов будет модульность, а монолит будет способствовать большей согласованности.
Модульность монолита
Микросервисы по своей природе приводят к разбиению системы на модули. Монолиты, по сути, не очень помогают в этом, но, конечно же, и не мешают делать это вам.
Слабосвязанный, состоящий из модулей код с ограниченной функциональностью — хорошее решение, независимо от появления дополнительной сложности из-за сетевых границ между этими задачами.
Микросервисы не гарантируют хорошую модульность
Хотя микросервисы и обеспечивают модульность, нет никакой гарантии в качестве этой модульности. Микросервисы могут легко превратиться в тесно связанный «распределенный монолит», если не будет полностью продуман дизайн.
Если вы не сможете разбить монолит на эффективные модули, тогда сложно будет структурировать и успешную архитектуру микросервисов. Микро��ервисы содействуют модульной структуре, но они усложняют задачу.
Независимое развертывание
Одно из преимуществ микросервисов — независимое развертывание. Но необходимость организации нескольких развертываний в разных сервисах затрудняет выпуск новых функций.
Разбивка комплексных изменений
С монолитом вполне можно выделить комплексные и рискованные изменения в отдельные развертывания. Типичным примером является обеспечение прямой и обратной совместимости миграций с требованиями к производительности и развертываниям.
Очевидно, что это усложняет функциональность обновления точно так же, как и в микросервисах.
Управление зависимостями
В микросервисной архитектуре все сервисы независимы, но действительно ли это для вас важно?
В большом монолите довольно сложно управлять зависимостями. Разделение их на несколько небольших списков упрощает управление каждым из них, но может усложнить это для системы в целом.
В монолите рано или поздно вы столкнетесь с «нагромождением зависимостей» и конфликтом между двумя из них. Микросервисы не гарантируют отсутствие проблем, но они должны снизить вероятность их появления.
Следите за обновлениями зависимостей
Очевидно, что поддерживать ваши зависимости в актуальном состоянии желательно. Но на практике, как правило, что-то упускается из виду.
На самом деле использование новейших версий может усугубить эту проблему, поскольку одна зависимость будет двигаться вперед быстрее, чем другие связанные с ней. Поддержка в актуальном состоянии не означает обновление при первой возможности до самой последней версии.
Более простой и понятный код
Это преимущество микросервисов в лучшем случае фиктивное, а в худшем — обман.
Конечно, каждый сервис проще и понятнее. Но система в целом гораздо сложнее и труднее для восприятия. Вы не устраняете сложность, а лишь увеличиваете ее и переносите в другое место.
Модульность монолита
Для монолита не нужно вводить сетевые границы и изолированные процессы, чтобы код стал понятнее для инженеров. Монолит, разбитый на модули с четко определенными и ограниченными задачами, понять будет также легко, если не проще, чем разбитую на отдельные сервисы систему.
Проблемы вашего монолита
Если у вас все же остаются проблемы с монолитом, то вполне вероятно, что это и не совсем монолит.
Вполне возможно, что монолит остается ярким маяком качества кода, инструментария и модульности. Оказавшись в подобной ситуации, возможно, пришло время подумать и о микросервисах. Но это далеко не всегда так. Часто необходимо просто поработать над своим кодом.
Создавать программное обеспечение непросто. Очень сложно организовать большие системы с множеством динамичных компонентов, изменяющихся со временем.
Каюсь. И я строил беспорядочные монолиты. Не хочу обсуждать чьи-либо предпочтения. Но тех, кто надеется решить имеющиеся у монолита проблемы волшебным образом с помощью микросервисов, ждет разочарование.
Когда следует выбирать микросервисы?
Выбор между монолитом и микросервисами часто преподносится как два взаимоисключающих способа мышления. Старая и новая школы. Правиль��о или неправильно. Одно из двух.
Истина в том, что оба подхода допустимы при разных компромиссах. Правильный выбор в значительной степени зависит от контекста, с учетом широкого спектра соображений.
Мое мнение
Для новых, небольших и средних групп разработчиков монолит является выбором по умолчанию. Микросервисы остаются приемлемым вариантом, но для их использования у вас должны быть веские основания.
Средним и крупным командам следует рассмотреть возможность применения микросервисов, но с большой осторожностью и пониманием необходимости компромиссов.
НЛО прилетело и оставило здесь промокод для читателей нашего блога:
— 15% на все тарифы VDS (кроме тарифа Прогрев) — HABRFIRSTVDS.
