В последние годы только ленивый не слышал о микросервисах. «Долой монолитную архитектуру, микросервисы — это будущее веб-разработки!» — об этом трубят буквально все компании, в технологическом стеке которых появились Kubernetes и начали внедряться практики DevOps.
Вот только стоит ли вам что-то менять в софте, если и так все работает? Давайте разбираться.
Микросервисная архитектура: что это?
Микросервисная архитектура — это подход к веб-разработке, при котором приложение разбивается на множество частей, каждая из которых выполняет какую-то единственную функцию. Каждый микросервис «привязан» к отдельному домену (используя при этом автономное хранилище с данными и не зависимые от внешних модулей средства для связи с этим хранилищем) и может быть развернут независимо.
Сегодня микросервисы выступают главным антагонистом монолитной архитектуры, где вся бизнес-логика взаимосвязана между собой.
Связь микросервисов друг с другом: меньше зависимостей, больше универсальности
С точки зрения конечного пользователя, разница между монолитной и микросервисной архитектурой будет заметна только тогда, когда он столкнется с неправильной работой системы, ведь в случае с монолитными приложениями, багов может быть намного больше. А все — из-за большого количества зависимостей.
Поэтому, чтобы сократить число ненужных связей, микросервисы взаимодействуют друг с другом через универсальные API. По мере необходимости, в дальнейшем, вы сможете подключать новые и отключать уже ненужные блоки, не теряя при этом жизнеспособности обновленного ПО.
Какие технологии используются для создания микросервисной архитектуры?
Чаще всего для создания микросервисов используются инструменты Docker (для контейнеризации) и Kubernetes (для оркестровки контейнеров), идеальные для развертывания в корпоративных средах.
Конечно же, вы всегда можете остановить свой выбор и на виртуальных машинах, однако в последнем случае вы будете вынуждены оплачивать даже минуты простоя вашего ПО.
Преимущества и недостатки микросервисов
Выясним плюсы и минусы микросервисов.
Плюсы:
- нет привязки к конкретным языкам и технологиям;
- простая интеграция со сторонними решениями и возможность повторного использования;
- практически бесконечная масштабируемость;
- простота обслуживания (управление серверной частью в монолитном ПО всегда было в ответственности владельца ПО, а в случае микросервисов все лежит в компетенции облачного провайдера);
- отказоустойчивость;
- упрощенная симметричная архитектура приложения вместо иерархической (что свойственно для монолитных продуктов) с одноранговыми зависимостями между компонентами;
- внесение правок без рисков “обрушить” всю систему.
Минусы:
- процесс тестирования собранного воедино ПО сложный, потому что микросервисы базируются на отдельных доменах;
- миграция монолитной архитектуры в микросервисную может обойтись очень дорого;
- управлять версиями ПО становится сложнее;
- могут возникать проблемы с отзывчивостью, так как количество кода, исполняемого не стороне бэкенда, увеличивается;
- для развертывания микросервисов вам потребуются опытные специалисты.
Долой монолит. Да здравствуют микросервисы
По сравнению с монолитной архитектурой ПО, микросервисы практически всегда оказываются в выигрыше. Ведь в случае с моноблоком все связи, данные и функции работают как единое целое. То есть, если вы решите модернизировать ваш софт, это потянет за собой и дополнительные правки и во многих других компонентах приложения. А это — ваше время и деньги.
Кроме того, в случае монолита, если у вас “сломается” какой-то из кодовых блоков, обрушится и вся система. Поэтому рассчитывать на стабильную работу такого приложения точно не стоит.
С другой стороны, далеко не весь, изначально монолитный софт можно разбить на микросервисы без радикального рефакторинга кода (что тоже есть ваше время и деньги). Дело в том, что у вас в любом случае обнаружатся компоненты, которые с логической точки зрения могут функционировать автономно друг от друга, но на практике они созависимы.
Нужны ли вам микросервисы, если «и так все нормально работает»?
В 2019 году независимый опрос показал, что около 92% респондентов активно наращивают количество микросервисов в своих решениях для бизнеса, а около трети респондентов способны оценить преимущества нововведений уже в первые месяцы их внедрения. Правда, вместе с этим, еще около 50% компаний оказываются и вовсе в неведении, какие плюсы могут принести им эти технические инновации.
Так стоит ли игра свеч? Или же микросервисы — это очередное технологическое «ноу-хау», которое скоро устареет?
С учетом всех вышеперечисленных преимуществ, микросервисная архитектура должна казаться поистине настоящей панацеей для любого бизнеса. И правда, с учетом достаточно сложной структуры большинства современных приложений, без разделения их на отдельные модули выходит путаница, нерациональный расход человеческих ресурсов и возникновение кучи багов.
Тем не менее, существуют случаи, когда такое слепое следование IT-трендам выливается в проблемы с производительностью. Ведь, как мы знаем, каждый из микросервисов/веб-сервисов “привязывается” к отдельному источнику данных (СУБД). А это значит, что при одновременном использовании многих функций приложения подобная его структура будет подразумевать синхронное выполнение не одного десятка пользовательских запросов. И чем больше будет микросервисов-компонентов приложения, тем будет больше рисков того, что сервер окажется перегруженным.
Поэтому разработчикам приходится оставлять более крупногабаритные модули, связи в которых выстраивались бы без участия сетевых протоколов. Они несут меньшую нагрузку на сервер и снижают риски DDoS-атак.
Еще одна проблема микросервисов заключается в отсутствии стандартизации. Изначально разработчики редко заморачиваются над согласованием форматов. При взаимодействии микросервисов друг с другом это упущение может повлечь за собой ошибки, здорово усложнить процедуру отладки и увеличить общее количество трудноустранимых багов.
И наконец, переход на микросервисы может оказаться слишком дорогим. Наверняка вы могли столкнуться с проблемой того, что некоторые компоненты, которые, по идее, можно было бы разделить между собой на отдельные микросервисы, в пределах существующего функционала работают неразрывно друг от друга. Полностью переписывать их — затея далеко не всегда рациональная.
В таких ситуациях имеет смысл задействовать веб-сервисы — частный вариант сервис-ориентированной архитектуры, который описывает механизмы взаимодействия API с основной кодовой базой, используя универсальные форматы представления данных XML, JSON и т.д., а также стандартный протокол HTTP. При этом, как и микросервисы, веб-сервисы не имеют привязки к языку разработки или программной платформе.
При таком компромиссном решении вы сможете сохранить производительность вашего приложения, а также снизить себестоимость его миграции на новую архитектуру.
Заключение
Как видим, микросервисы — это не лекарство от всех болезней, а всего лишь один из подходов к обеспечению масштабируемой и простой в управлении архитектуры ПО. Обычно их внедряют глобальные корпорации, такие, как Google, Netflix и Amazon, которые предлагают конечным пользователям тысячи отдельных услуг. С другой стороны, изначально выбранная микросервисная архитектура ПО станет хорошим фундаментом для построения гибкой и отказоустойчивой системы.
Поэтому — внимательно взвесьте все плюсы и минусы, оцените риски и только тогда уже ищите разработчиков.
Источник статьи: https://habr.com/ru/company/vdsina/blog/553176/