Микросервисная архитектура: что это, кому подойдёт и какие инструменты использовать?
Каждый разработчик стремится к тому, чтобы разработка продукта шла быстрее, и одновременно можно было бы обеспечить достаточную гибкость и уверенное управление процессом. Решить эти задачи позволяет микросервисная архитектура приложений, которая за последние 7-10 лет стала активно конкурировать с традиционным монолитным подходом. И для начала рассмотрим разницу между ними.
Микросервисная архитектура и монолит
Различие между этими двумя подходами к разработке ПО нагляднее всего представить на конкретном примере. Допустим, у нас есть два интернет-магазина: один реализован в виде монолита, а другой — в виде микросервисов.
- Монолитный интернет-магазин — это единая и неделимая структура, в которой объединены все составляющие: базы данных (каталог, данные о покупателях), корзина, формы заказа и оплаты. И все эти элементы неразрывно связаны между собой и находятся на одном сервере.
- В системе микросервисов каждая из этих составляющих представляет собой независимый модуль, с которым разработчики могут работать отдельно. И конечно, никто не заставляет размещать эти модули на одном сервере.
Таким образом, микросервисная архитектура является своеобразным конструктором, куда вы можете безболезненно добавлять новые элементы, масштабируя приложение. А монолит можно сравнить со стеной, и масштабирование здесь возможно только добавлением еще одного такого же монолита.
Здесь стоит добавить, что структуру микросервисов порой ошибочно считают сочетанием мелких сервисов. Это не так: например, база данных крупного интернет-магазина может содержать миллионы записей и занимать десятки гигабайт. И при этом она является одним из модулей в составе микросервисной архитектуры всего приложения.
Сравниваем микросервисы и монолиты по основным критериям
Теперь посмотрим на основные особенности технологии микросервисов в сравнении с монолитом и выясним, как оба подхода решают одни и те же задачи разработчиков.
Выпуск релизов
Скорость разработки и частота выпуска обновлений на микросервисах повышается за счет модульности, так как какие-то изменения делаются не во всём коде, а в отдельных модулях. В то же время при использовании монолита сначала потребуется обновление всей платформы, что увеличивает время на тестирование и отладку. А значит скорость разработки снижается и выпуски обновлений будут не такими частыми.
Технологический стек
Принцип работы микросервисов предполагает значительно большую гибкость, потому что каждый сервис может быть написан на своем языке программирования, а также может использовать разные библиотеки и технологии хранения данных. В случае с монолитом ситуация иная, и изменить стек используемых технологий здесь практически нереально. В результате разработчикам приходится придерживаться изначальных инструментов.
Порог вхождения в разработку
Каждый модуль в микросервисах — это самостоятельная единица, поэтому появляется возможность приглашать программистов, хорошо знакомых с функционалом определенного сервиса. А значит, порог вхождения в разработку существенно снижается. В случае с монолитами ситуация иная: новым разработчикам придется погрузиться в код всего приложения, ознакомиться с функциями каждого блока и лишь затем они смогут приступить к работе полноценно. Таким образом, обслуживание монолита более зависимо от конкретных членов команды.
Особенности оптимизации
Модульность микросервисной архитектуры положительно сказывается и на оптимизации, поскольку разработчики имеют возможность оптимизировать каждый сервис по отдельности. Оптимизация монолитных структур сложнее, так как команде придется учитывать связь между неделимыми блоками, и обновление каждого из них неизменно скажется на состоянии всего приложения.
Масштабирование приложения
Распределенная структура микросервисов, их расположение на отдельных серверах делает масштабирование быстрым и легким. В случае с монолитами масштабирование одной составляющей неизменно влечет за собой аналогичную работу и для приложения в целом.
Отказоустойчивость
За счет размещения сервисов на разных серверах и модульной структуры микросервисная архитектура позволяет добиться независимости каждого модуля. Это существенно повышает отказоустойчивость приложения, ведь нарушение в работе одного сервиса не приведет к отказу всего приложения. С монолитом ситуация другая — все компоненты там тесно связаны между собой, а потому сбой одного из них может сделать неработоспособным и всё приложение.
Нужно ли мне переходить на микросервисы прямо сейчас?
Как видим, по многим ключевым пунктам преимущество у микросервисов. Но значит ли это, что нужно отказаться от монолитов, как от устаревшего подхода, и массово переходить на микросервисную архитектуру? Ответ на этот вопрос зависит от текущего состояния вашего проекта. И сразу скажем, что торопиться переходить на микросервисы стоит не всегда. Распределенная архитектура тоже не лишена недостатков.
- Во-первых, не очень хорошим свойством микросервисов является необходимость в обеспечении сетевой связности между модулями. И если какое-то сетевое соединение не слишком стабильно, это приводит к задержкам и к рассогласованности данных, что создает потенциальные проблемы в работе приложения.
- Во-вторых, каждый модуль микросервисной структуры потребует отдельных действий по тестированию, отслеживанию работоспособности. А кроме того, для них придется резервировать облачные мощности, что может приводить к увеличению затрат.
- В-третьих, при микросервисном подходе иногда возникают проблемы взаимодействия между командами, занимающимися обслуживанием отдельных модулей. А значит, придется задуматься о связующем звене в виде специалистов DevOps, которые помогут наладить взаимодействие между разработчиками и ускорят процесс разработки.
Все перечисленные выше факторы позволяют сделать вывод о том, что переход на микросервисы должен быть своевременным. И обычно на первых стадиях развития проекта это не требуется, особенно если разработчики располагают ограниченными людскими ресурсами и финансовыми возможностями.
Переход на микросервисную архитектуру уместен тогда, когда назрела потребность в серьезном масштабировании, а масштабирование монолита уже сопряжено с существенными трудностями. Вам подойдут микросервисы, если:
- у вас большая команда. В этом случае разумно разделить коллектив на отдельные независимые группы, каждая из которых будет заниматься развитием своего сервиса;
- у вас сложное разветвленное приложение. В этом случае гораздо удобнее организовать обновление и поддержку модулей по отдельности, чем каждый раз балансировать всю систему;
- трафик вашего приложения носит скачкообразный характер. Например, наблюдаются резкие всплески посещаемости в определенные периоды. В этом случае распределенная структура микросервисов поможет быстро выполнить масштабирование во время пиковых нагрузок, а затем вы без проблем сможете вернуться к привычным мощностям.
- ваше приложение часто обновляется. Работать с отдельными модулями в этом случае будет гораздо проще, и выпуск новых версий пойдет заметно быстрее.
Если ваш проект соответствует хотя бы одному из перечисленных выше критериев, это повод задуматься о том, чтобы разделить его на независимые элементы. Если же ваше приложение сравнительно небольшое и не требует частых обновлений, разумным решением будет не торопиться с уходом от монолитной архитектуры.
Полезные инструменты для организации микросервисов
Современный подход к разработке требует наличия платформы контейнеризации. В большинстве случаев разработчики используют для этих целей Docker. При помощи инструментов Docker они могут отделить приложение от инфраструктуры, то есть одинаково свободно работать с ним как локально, так и в облаке, что очень удобно для разработки.
Когда контейнеров становится слишком много, не обойтись без оркестратора — это решение для управления и организации групп контейнеров. В качестве оркестратора чаще всего используют Kubernetes, который имеет хорошую совместимость с Docker. Однако у Docker есть и собственное решение для этих целей: Docker Swarm. О различиях между Docker Swarm и Kubernetes вы можете почитать в отдельной статье.
Еще один необходимый инструмент — балансировщик нагрузки, который обеспечивает равномерное распределение сетевого трафика по всем облачным ресурсам. Это заметно повышает отказоустойчивость приложения. Подробнее об этом инструменте вы можете почитать здесь.