В последние годы только ленивый не слышал о микросервисах. «Долой монолитную архитектуру, микросервисы — это будущее веб-разработки!» — об этом трубят буквально все компании, в технологическом стеке которых появились Kubernetes и начали внедряться практики DevOps.

Вот только стоит ли вам что-то менять в софте, если и так все работает? Давайте разбираться.

Микросервисная архитектура: что это?

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

Сегодня микросервисы выступают главным антагонистом монолитной архитектуры, где вся бизнес-логика взаимосвязана между собой.

Связь микросервисов друг с другом: меньше зависимостей, больше универсальности

С точки зрения конечного пользователя, разница между монолитной и микросервисной архитектурой будет заметна только тогда, когда он столкнется с неправильной работой системы, ведь в случае с монолитными приложениями, багов может быть намного больше. А все — из-за большого количества зависимостей.

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

Какие технологии используются для создания микросервисной архитектуры?

Чаще всего для создания микросервисов используются инструменты Docker (для контейнеризации) и Kubernetes (для оркестровки контейнеров), идеальные для развертывания в корпоративных средах.

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

Преимущества и недостатки микросервисов

Выясним плюсы и минусы микросервисов.

Плюсы:

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

Минусы:

• процесс тестирования собранного воедино ПО сложный, потому что микросервисы базируются на отдельных доменах;
• миграция монолитной архитектуры в микросервисную может обойтись очень дорого;
• управлять версиями ПО становится сложнее;
• могут возникать проблемы с отзывчивостью, так как количество кода, исполняемого на стороне бэкенда, увеличивается;
• для развертывания микросервисов вам потребуются опытные специалисты.

Долой монолит. Да здравствуют микросервисы

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

Кроме того, в случае монолита, если у вас “сломается” какой-то из кодовых блоков, обрушится и вся система. Поэтому рассчитывать на стабильную работу такого приложения точно не стоит.

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

Нужны ли вам микросервисы, если «и так все нормально работает»?

В 2019 году независимый опрос показал, что около 92% респондентов активно наращивают количество микросервисов в своих решениях для бизнеса, а около трети респондентов способны оценить преимущества нововведений уже в первые месяцы их внедрения. Правда, вместе с этим, еще около 50% компаний оказываются и вовсе в неведении, какие плюсы могут принести им эти технические инновации.

Так стоит ли игра свеч? Или же микросервисы — это очередное технологическое «ноу-хау», которое скоро устареет?

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

Тем не менее, существуют случаи, когда такое слепое следование IT-трендам выливается в проблемы с производительностью. Ведь, как мы знаем, каждый из микросервисов/веб-сервисов “привязывается” к отдельному источнику данных (СУБД). А это значит, что при одновременном использовании многих функций приложения подобная его структура будет подразумевать синхронное выполнение не одного десятка пользовательских запросов. И чем больше будет микросервисов-компонентов приложения, тем будет больше рисков того, что сервер окажется перегруженным.

Поэтому разработчикам приходится оставлять более крупногабаритные модули, связи в которых выстраивались бы без участия сетевых протоколов. Они несут меньшую нагрузку на сервер и снижают риски DDoS-атак.

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

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

В таких ситуациях имеет смысл задействовать веб-сервисы — частный вариант сервис-ориентированной архитектуры, который описывает механизмы взаимодействия API с основной кодовой базой, используя универсальные форматы представления данных XML, JSON и т.д., а также стандартный протокол HTTP. При этом, как и микросервисы, веб-сервисы не имеют привязки к языку разработки или программной платформе.

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

Заключение

Как видим, микросервисы — это не лекарство от всех болезней, а всего лишь один из подходов к обеспечению масштабируемой и простой в управлении архитектуры ПО. Обычно их внедряют глобальные корпорации, такие, как Google, Netflix и Amazon, которые предлагают конечным пользователям тысячи отдельных услуг. С другой стороны, изначально выбранная микросервисная архитектура ПО станет хорошим фундаментом для построения гибкой и отказоустойчивой системы.

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

---

На правах рекламы

Многие наши клиенты уже оценили преимущества эпичных серверов!
Это недорогие виртуальные серверы с процессорами AMD EPYC, частота ядра CPU до 3.4 GHz. Максимальная конфигурация позволит оторваться на полную — 128 ядер CPU, 512 ГБ RAM, 4000 ГБ NVMe. Поспешите заказать!