Микросервисы против монолитной архитектуры [закрыто]

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

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

Хотя я относительно новичок в мире микросервисов, я постараюсь ответить на ваш вопрос как можно более полно.

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

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

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

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

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

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

Льготы

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

Вызовы

• Возможность развертывания : существует гораздо больше единиц развертывания, поэтому есть более сложные задания, сценарии, области передачи и файлы конфигурации, которые необходимо контролировать при развертывании. (По этой причине непрерывная доставка и DevOps очень желательны для микросервисных проектов.)
• Производительность : сервисам, скорее всего, необходимо обмениваться данными по сети, тогда как сервисам внутри монолита могут быть полезны местные вызовы. (По этой причине при разработке следует избегать «болтливых» микросервисов.)
• Возможность модификации : изменения в контракте с большей вероятностью повлияют на потребителей, развернутых в другом месте, тогда как в монолитной модели потребители с большей вероятностью будут находиться внутри монолита и будут развертываться синхронно с услугой. Кроме того, механизмы повышения автономности, такие как конечная согласованность и асинхронные вызовы, усложняют микросервисы.
• Возможность тестирования: интеграционные тесты сложнее настроить и запустить, поскольку они могут охватывать разные микросервисы в разных средах выполнения.
• Управление : усилие по управлению операциями возрастает, потому что необходимо контролировать больше компонентов среды выполнения, файлов журналов и двухточечных взаимодействий.
• Использование памяти : несколько классов и библиотек часто реплицируются в каждом пакете микросервисов, и общий объем памяти увеличивается.
• Автономность выполнения : в монолите размещена общая бизнес-логика. В микросервисах логика распространяется на микросервисы. Таким образом, при прочих равных, более вероятно, что микросервис будет взаимодействовать с другими микросервисами по сети - это взаимодействие снижает автономность. Если взаимодействие между микросервисами включает изменение данных, необходимость в границах транзакций еще больше снижает автономность. Хорошая новость заключается в том, что во избежание проблем с автономностью во время выполнения мы можем использовать такие методы, как конечная согласованность, управляемая событиями архитектура, CQRS, кэш (репликация данных) и согласование микросервисов с ограниченными контекстами DDD. Эти методы не присущи микросервисам, но были предложены практически всеми авторами, которых я читал.

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

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

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

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