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