Микросервисы завоёвывают всё большую популярность среди разработчиков, они хороши для крупных интернет-сервисов, обслуживающих большое количество пользователей. Если случится сбой в одном сервисе, то остальные спокойно продолжат свою работу: это очень важно для больших и сложных систем. При нововведениях можно просто написать новый сервис, он легко впишется во всю систему, не придётся заниматься проблемами совместимости. Более того, в работу можно включать несколько независимых друг от друга команд, использующих разные языки программирования: микросервисы позволяют это сделать.
Микросервисный подход имеет как достоинства, так и недостатки. В данной статье мы подробно рассмотрим сущность микросервисной архитектуры, её отличия от монолитной архитектуры, преимущества и недостатки, а также особенности эксплуатации приложений, построенных по принципу микросервисов.
Что такое микросервисная архитектура
Микросервисная архитектура — стиль разработки ПО, заключающийся в разбиении монолита системы на отдельные компоненты, которые представляют собой независимые сервисы. Каждый отдельный сервис призван выполнять относительно несложные функции, работа приложения тестируется в режиме реального времени с отслеживанием технических элементов и бизнес-характеристик. Сервисы имеют чёткие физические границы, что делает их масштабируемыми, даёт возможность использовать для написания разные языки программирования. Требуемые изменения вносятся, не затрагивая всё приложение целиком.
Микросервисная архитектура и монолит
Монолитные системы объединяют все сервисы приложения в один процесс, а потом дублируют эту систему на нескольких серверах. Микросервисная архитектура для каждого сервиса имеет отдельную упаковку, а на разных серверах они хранятся также — изолированно друг от друга, дублируясь, если есть необходимость. Что и позволяет отдельно работать с каждым функциональным элементом.
Монолитная и микросервисная архитектура
Преимущества микросервисной архитектуры
Преимущества микросервисов оказались достаточно сильны, чтобы такие крупные корпоративные игроки как Amazon, Netflix или eBay внедрили их в свои системы.
- Высокая отказоустойчивость: при падении одного из сервисов, все остальные остаются в строю. Таким образом, неполадки в отдельных сервисах не помешают всему рабочему процессу;
- Гибкость: можно попробовать внедрить новую технологию малой кровью. Это будет значительно быстрее и, при неудаче, откатить изменения просто. Меняя локально один из сервисов, мы не рискуем всей системой и время, требующееся для изменений, меньше;
- Простота: чем меньше кода (а каждый отдельный сервис представляет собой цельную систему, поэтому не нужно разбираться в огромном количестве деталей, не касающихся данной конкретной функции), тем проще программистам разобраться, что и как работает. К тому же, на это уйдет меньше времени;
- Лёгкость выведения написанного кода в работу: небольшое количество кода обеспечивает быстрый деплой;
- Масштабируемость: самые необходимые и нужные сервисы можно дополнить и расширить, когда появится такая необходимость. Вся система при этом остается прежней.
По сравнению с монолитной, микросервисная архитектура обладают большей гибкостью и возможностью независимого масштабирования отдельных сервисов. Проще вносить локальные изменения в код без риска для всей системы, но взамен этого возрастает сложность взаимодействия между сервисами.
Недостатки микросервисной архитектуры
Несмотря на трендовость и большое количество плюсов микросервисной архитектуры, она обладает и минусами.
- Сообщение между самими сервисами сложное. Так как каждый функциональный элемент изолирован, требуется особая тщательность при построении между ними грамотной коммуникации, ведь им в любом случае придётся обмениваться запросами и ответами друг с другом. Понятно, что с увеличением количества сервисов сложность в построении их сообщения будет расти.
- Рост числа сервисов также влечет за собой и рост числа баз данных, с которыми эти сервисы соотносятся, так как, в отличие от монолитной архитектуры, микросервисы используют не одну общую базу данных.
- Сложность тестирования выражается в том, что сначала нужно отдельно разбираться с каждым сервисом, а потом тестировать корректное взаимодействие его с другими микросервисами.
- Микросервисы хуже подходят для использования внутри отдельных организаций, для них они могут оказаться неоправданно сложными в применении, в то время как для массовых интернет-сервисов они подходят отлично.
Особенности эксплуатации приложений с микросервисной архитектурой
- Осуществление мониторинга
Со временем небольшие проблемы могут привести к серьёзным. Поэтому своевременный, а в случае микросервисов, непрерывный, мониторинг — необходим. Мониторинг микросервисной архитектуры гораздо более сложен в настройке и требует больших затрат на свою поддержку, нежели мониторинг монолитного приложения. - Реализация отказоустойчивости
Как монолитная, так и микросервисная архитектура, не могут избежать отказов при работе приложения. Важным принципом при создании приложения на микросервисах является установка на то, что отказы системы рано или поздно произойдут. И с таким изначальным предположением и создаётся приложение.
Перед выпуском в продакшн код должен быть тщательно протестирован. Тем не менее, всегда есть вероятность, что какая-то ошибка будет упущена. Именно для таких случаев придумана система хаос-тестирования. Ошибки и проблемы создаются автоматически и намеренно — чтобы заранее изучить их и придумать быстрое решение или способ их предотвратить. - Масштабирование
Облачная природа микросервисов и виртуализация, лежащая в их основе, главным преимуществом имеют масштабирование. Каждый сервис выполняет определённую функцию, все сервисы относительно небольшие — все эти характеристики архитектуры и делают масштабирование более простым и безболезненным.
В каком случае уместно использование микросервисной архитектуры
Микросервисная архитектура особенно актуальна для компаний, предоставляющих онлайн-сервисы большому количеству пользователей одновременно. К таким сервисам можно отнести крупные интернет-магазины, стриминговые платформы, социальные сети.
Для них важна возможность независимого масштабирования разных компонентов системы. Например, в дни распродаж нагрузка на сервис оформления заказов сильно возрастает, а остальные сервисы работают в штатном режиме. Микросервисы позволяют гибко наращивать вычислительные мощности и пропускную способность именно для сервиса оформления заказов, не затрагивая другие подсистемы.
Для онлайн-сервисов с большой аудиторией также критична отказоустойчивость — при выходе из строя какого-то сервиса, остальная часть приложения должна продолжать работать в штатном режиме. Разделение на независимые микросервисы как раз и обеспечивает такую изоляцию сбоев.
Кроме того, микросервисы удобны для больших распределённых команд разработчиков — каждая команда может заниматься своим сервисом, что упрощает координацию и ускоряет процесс выпуска релизов.
В то же время микросервисы могут быть избыточным решением для небольших проектов или внутренних систем компаний. В таких случаях предпочтительнее использовать монолитную архитектуру за счёт её большей простоты и дешевизны в разработке и поддержке.
Примеры использования микросервисной архитектуры
Amazon
Одна из первых компаний, начавших применять микросервисы. Вся инфраструктура Amazon построена из сотен независимых сервисов — для каталога товаров, пользовательских аккаунтов, поиска, рекомендаций и так далее. Это позволяет Amazon легко масштабировать ресурсы под возрастающие нагрузки и быстро выводить новые продукты за счёт микросервисной разработки.
Netflix
Стриминговый сервис Netflix разбит более чем на 800 микросервисов. Они отвечают за видео-транскодирование, рекомендации, A/B тестирование интерфейсов и прочие задачи. Гибкость микросервисов позволяет Netflix быстро расширять парк серверов при наплывах трафика и экспериментировать с UI/UX без риска для системы.
Uber
Компания использует сотни микросервисов — для геолокации, картографии, обработки платежей, логистики и многого другого. Это обеспечивает надёжность и отказоустойчивость системы при огромных нагрузках, а также позволяет Uber быстро масштабироваться и выходить на новые рынки.
Выводы
Микросервисы хуже подходят для использования в качестве архитектуры для разработки корпоративных информационных систем. В таком варианте мы получим излишне сложную с точки зрения эксплуатации и сопровождении систему. А увеличение эксплуатационных затрат не окупится за счет преимуществ использования микросервисной архитектуры, поскольку они не проявятся в полной мере внутри одной, даже крупной организации.
Основная область эффективного применения микросервисов — крупные интернет-сервисы, работающие в режиме реального времени для большого количества пользователей.
