В чем основная идея микросервисов?

Я читал несколько источников и пытался найти простое объяснение, но к сожалению везде много слов с развернутыми пояснениями, но нигде нет простой картинки, буквально нескольких предложений, которые объясняли бы основную мысль. Хотелось найти что-то такое, что было бы легко понять, краткое объяснение, но в то же время где объяснялась бы основная мысль, чтобы остальные слова были второстепенными. А здесь, на мой взгляд, все плохо, потому что такого лаконичного изложения я не нашел. Является ли это признаком того, что концепция микросервисов довольно расплывчата и вводит в заблуждение? Это беспокоит меня. Также есть довольно много статей, в которых есть предостережения против использования микросервисов, и в которых есть мысли о том, что в большинстве случаев микросервисы не требуются, ваши задачи не такие сложные, и ваша команда не настолько многочисленна, чтобы использовать микросервисы. В итоге у меня сложилось несколько пренебрежительное отношение к идее микросервисов. Правда ли, что микросервисы — это модное слово, которое повторяет несколько старых идей и собирает их вместе?

Во-первых, я перечисляю идеи (как я их понимаю), которые используются для объяснения микросервисов:

  1. Микросервисы обычно объясняются как противоположность монолита. Например, есть монолитное приложение, реализующее несколько функций. Микросервис — это противоположность монолиту, в котором отдельные функции оформлены как отдельные приложения, взаимодействующие друг с другом по какому-то протоколу. Здесь термин микросервисы буквально означает небольшие сервисы. Если рассматривать это объяснение с точки зрения рабочих экземпляров, то хотя у монолита может быть несколько одновременно работающих экземпляров, в данном объяснении это не является основной идеей. В этом объяснении главное разделить на отдельные части выполняемую работу и программный код.

  2. Еще одна идея в объяснении микросервисов — асинхронная обработка запросов и взаимодействие отдельных экземпляров друг с другом. Это довольно старая идея, непонятно, почему это считается какой-то обязательной частью в микросервисах. Ну допустим у нас нет асинхронной обработки и что мы не можем сказать, что у нас есть микросервисы? На мой взгляд, это явно второстепенная функция, которую хотелось бы иметь, но которая не является обязательной.

  3. Разделите свою команду на небольшие команды, работающие над отдельными сервисами с отдельными кодовыми базами, с разными языками программирования и отдельными базами данных. Здесь основная идея — уменьшить количество связей между командами. Связность между службами будет минимальной, если единственным связующим звеном является протокол взаимодействия. Это должно ускорить разработку и упростить внесение изменений в код, поскольку разные команды могут работать независимо. Если изменения не меняют протокол, то остальные части системы этого не замечают.

  4. Использование виртуализации и контейнеризации. Здесь главная проблема, которая решается, — простота развертывания и масштабируемость приложения. Похоже все используют виртуализацию, любая модная вещь должна иметь виртуализацию, давайте тоже ее использовать.

  5. Возможность автоматического обнаружения службы. Сервисы находят друг друга автоматически, легко добавлять новые экземпляры и перемещать их. Нет необходимости перенастраивать систему при изменении топологии экземпляра.

Я искал что-то общее во всех этих идеях и, кажется, нашел. Итак, вот мое определение: микросервисы — это система, построенная из нескольких экземпляров, так что ее легко добавлять, удалять работающие экземпляры и масштабировать всю систему, так что даже в случае сбоя экземпляра система продолжает работать. выполнять. Таким образом, ни одна из приведенных выше идей не является обязательной, а является лишь дополнительным расширением. Мы должны начать с того, какая у нас проблема, и взять идею, которая поможет решить эту проблему. С этой точки зрения главное — это возможность системы иметь несколько запущенных экземпляров, поэтому если какие-то из них перестанут работать, то это не повлияет на функционирование системы. У нас даже может быть монолит, главное возможность запускать несколько экземпляров монолита и возможность работать параллельно. То есть идея разделения системы на отдельные функции (на мелкие сервисы) становится второстепенной и необязательной. Собственно мой вопрос, насколько верно мое понимание основной идеи микросервисов?


person Aleksandr Bondarev    schedule 07.12.2020    source источник
comment
Ваше смелое определение лица опускает важную часть информации ИМХО, а именно то, что микро находится в названии микросервиса, потому что последний предназначен для содержания небольшой и компактной части функциональности (что отличает микросервисный подход от монолитного, где все делается в одном месте).   -  person Tim Biegeleisen    schedule 07.12.2020


Ответы (2)


Ваше понимание ошибочно.

Микрослужбы отличаются друг от друга тем, что одна микрослужба может продолжать работать и выполнять полезные действия, даже если другая целая микрослужба полностью недоступна (например, отключена для обслуживания).

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

В микросервисах каждый микросервис развертывается отдельно и имеет отдельное хранилище данных. Если вам нужно отключить микросервис А для обслуживания, вы отключите все экземпляры микросервиса А, но микросервис Б все еще работает и может выполнять полезные функции.

person user3067860    schedule 10.12.2020

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

person Nitin Gaur    schedule 15.12.2020