Microservices vs Monolithic Architecture

Question

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

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

Answer 1

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

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

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

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

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

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

Answer 2

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

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

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

Answer 3

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

Плюсы:

• развертыванию: более маневренности выкатить новые версии сервиса за счет укороченного сборки + тест + развертывание циклов. Кроме того, гибкость в использовании служб безопасности, репликации, сохранения и мониторинга конфигураций.
• Надежность: неисправность микросервиса влияет на эту микросервисную систему самостоятельно и ее потребителей, тогда как в монолитной модели служебная ошибка может разрушить весь монолит.
• Доступность: развертывание новой версии микросервиса требует небольшого простоев, тогда как развертывание новой версии службы в монолите требует типично более медленного перезапуска всего монолита.
• Масштабируемость: каждый микросервис можно масштабировать независимо, используя пулы, кластеры, сетки. Характеристики развертывания делают микросервисы отличным сочетанием эластичности облака.
• Модифицируемость: больше гибкости при использовании новых фреймворков, библиотек, источников данных и других ресурсов. Кроме того, микросервисы слабо связаны, модульные компоненты доступны только через их контракты и, следовательно, менее склонны превращаться в большой шар грязи. Динамическое обнаружение и привязка через реестр (например, Apache ZooKeeper, Netflix Eureka) иногда используется для прозрачности местоположения.
• Управление: приложение развитие усилие делится на команды, которые меньше и работают более независимо.
• Design автономность: команда имеет свободу использовать различные технологии, рамки и шаблоны для разработки и реализации каждого microservice, и может изменить и перераспределить каждый microservice независимо

Минусы:

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

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