Блог

Применение микросервисной архитектуры: плюсы, минусы, подводные камни

Микросервисная архитектура – стиль разработки ПО, заключающийся в разбиении монолита системы на отдельные компоненты, которые представляют собой независимые сервисы. Каждый отдельный сервис призван выполнять относительно несложные функции, работа приложения тестируется в режиме реального времени с отслеживанием технических элементов и бизнес-характеристик. Сервисы имеют чёткие физические границы, что делает их масштабируемыми, даёт возможность использовать для написания разные языки программирования. Требуемые изменения вносятся, не затрагивая всё приложение целиком.

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

Монолитная и микросервисная архитектура

Монолитная и микросервисная архитектура

Коротко говоря, монолитные системы объединяют все сервисы приложения в один процесс, а потом дублируют эту систему на нескольких серверах. Микросервисная архитектура для каждого сервиса имеет отдельную упаковку, а на разных серверах они хранятся также – изолированно друг от друга, дублируясь, если есть необходимость. Что и позволяет отдельно работать с каждым функциональным элементом.

Управление ИТ услугами

Преимущества микросервисной архитектуры

Преимущества микросервисов оказались достаточно сильны, чтобы такие крупные корпоративные игроки как Amazon, Netflix или eBay внедрили их в свои системы.

  • Высокая отказоустойчивость: при падении одного из сервисов, все остальные остаются в строю. Таким образом, неполадки в отдельных сервисах не помешают всему рабочему процессу.
  • Гибкость: можно попробовать внедрить новую технологию малой кровью. Это будет значительно быстрее и, при неудаче, откатить изменения просто. Меняя локально один из сервисов, мы не рискуем всей системой и время, требующееся для изменений, меньше.
  • Простота: чем меньше кода (а каждый отдельный сервис представляет собой цельную систему, поэтому не нужно разбираться в огромном количестве деталей, не касающихся данной конкретной функции), тем проще программистам разобраться, что и как работает. К тому же, на это уйдет меньше времени.
  • Лёгкость выведения написанного кода в работу. Небольшое количество кода обеспечивает быстрый деплой.
  • Масштабируемость. Самые необходимые и нужные сервисы можно дополнить и расширить, когда появится такая необходимость. Вся система при этом остается прежней.

Недостатки микросервисной архитектуры

Несмотря на трендовость и большое количество плюсов микросервисной архитектуры, она обладает и минусами.

  • Сообщение между самими сервисами сложное. Так как каждый функциональный элемент изолирован, требуется особая тщательность при построении между ними грамотной коммуникации, ведь им в любом случае придётся обмениваться запросами и ответами друг с другом. Понятно, что с увеличением количества сервисов сложность в построении их сообщения будет расти.
  • Рост числа сервисов также влечет за собой и рост числа баз данных, с которыми эти сервисы соотносятся, так как, в отличие от монолитной архитектуры, микросервисы используют не одну общую базу данных.
  • Сложность тестирования выражается в том, что сначала нужно отдельно разбираться с каждым сервисом, а потом тестировать корректное взаимодействие его с другими микросервисами.
  • Микросервисы хуже подходят для использования внутри отдельных организаций, для них они могут оказаться неоправданно сложными в применении, в то время как для массовых интернет-сервисов они подходят отлично.

Особенности эксплуатации приложений с микросервисной архитектурой

Осуществление мониторинга

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

Реализация отказоустойчивости

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

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

Масштабирование

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

Выводы

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

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

Пользуясь настоящим сайтом, вы даете свое согласие на использование файлов cookies