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

Ответ 1

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

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

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

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

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

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

Ответ 2

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

Плюсы:

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

Минусы:

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

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

Ответ 3

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

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

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