Микросервисная архитектура: что это, кому подойдёт и какие инструменты использовать?

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

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

Различие между этими двумя подходами к разработке ПО нагляднее всего представить на конкретном примере. Допустим, у нас есть два интернет-магазина: один реализован в виде монолита, а другой — в виде микросервисов.

• Монолитный интернет-магазин — это единая и неделимая структура, в которой объединены все составляющие: базы данных (каталог, данные о покупателях), корзина, формы заказа и оплаты. И все эти элементы неразрывно связаны между собой и находятся на одном сервере.
• В системе микросервисов каждая из этих составляющих представляет собой независимый модуль, с которым разработчики могут работать отдельно. И конечно, никто не заставляет размещать эти модули на одном сервере.

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

Здесь стоит добавить, что структуру микросервисов порой ошибочно считают сочетанием мелких сервисов. Это не так: например, база данных крупного интернет-магазина может содержать миллионы записей и занимать десятки гигабайт. И при этом она является одним из модулей в составе микросервисной архитектуры всего приложения.

Сравниваем микросервисы и монолиты по основным критериям

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

Выпуск релизов

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

Технологический стек

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

Порог вхождения в разработку

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

Особенности оптимизации

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

Масштабирование приложения

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

Отказоустойчивость

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

Нужно ли мне переходить на микросервисы прямо сейчас?

Как видим, по многим ключевым пунктам преимущество у микросервисов. Но значит ли это, что нужно отказаться от монолитов, как от устаревшего подхода, и массово переходить на микросервисную архитектуру? Ответ на этот вопрос зависит от текущего состояния вашего проекта. И сразу скажем, что торопиться переходить на микросервисы стоит не всегда. Распределенная архитектура тоже не лишена недостатков.

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

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

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

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

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

Полезные инструменты для организации микросервисов

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

Когда контейнеров становится слишком много, не обойтись без оркестратора — это решение для управления и организации групп контейнеров. В качестве оркестратора чаще всего используют Kubernetes, который имеет хорошую совместимость с Docker. Однако у Docker есть и собственное решение для этих целей: Docker Swarm. О различиях между Docker Swarm и Kubernetes вы можете почитать в отдельной статье.

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