Как понять, что пора переходить на микросервисы, и сделать это вовремя

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

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

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

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

Монолитная архитектура: плюсы, минусы, основные компоненты

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

Основные преимущества использования монолитной архитектуры:

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

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

  Среди недостатков:

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

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

Основными логическими частями приложения на основе монолитной архитектуры являются:

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

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

  

 
Это обобщенное, но наглядное представление структуры монолитной архитектуры.

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

Микросервисная архитектура: плюсы, минусы, основные компоненты

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

При грамотной реализации этой архитектурной модели можно добиться весомых преимуществ:

• Надежность. Использование этой архитектуры потенциально позволяет повысить отказоустойчивость системы.

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

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

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

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

  Это касается практически всего, начиная от баз данных, заканчивая языками программирования. Процессы межсервисного взаимодействия универсальны и поэтому ничего не ограничивает нас в том, чтобы написать один сервис на Java, а другой на Go или Python. 

• Удобство разработки. С разделением на отдельные микросервисы появляется возможность сосредоточить внимание отдельных разработчиков или их команд на более узких частях предметной области.

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

Минусы при работе с микросервисной архитектуры следуют из преимуществ монолита:

• Сложность при разработке и развертывании — приходится поддерживать несколько репозиториев и строить процессы сборки и развертывания отдельно для каждого сервиса.
• Усложненная интеграция — несмотря на развитые технологии межсервисного взаимодействия, процессы интеграции бизнес процессов в разных серверах усложняются. Эти процессы всегда несут в себе дополнительные риски и накладные расходы.
• Потребности в ресурсах — разделение на сервисы, сервера, а также отдельные экземпляры баз данных требуют соответствующих ресурсов.

У каждой архитектуры есть свои достоинства и недостатки. Для выбора полезно провести анализ особенностей проекта, определить их особенности, какое влияние будут оказывать на разработку и поддержку системы.

3 признака того, что пора переходить на микросервисы

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

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

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

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

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

Едем в микросервисы: успешная стратегия переезда

Когда, взвесив все за и против, приняли решение о переходе на микросервисы, начинается самая непростая в техническом отношении часть — непосредственная смена архитектуры.

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

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

Тема реализации этого похода очень обширна и требует рассмотрения в отдельных статьях, поэтому выделим лишь основные принципы, лежащие в ее основе:

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

А может надо сразу выбирать микросервисы? Не всегда, зависит от проекта

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

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

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

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

Заключение

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

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