Микросервисы: преимущества и недостатки

Микросервисы — это независимо выпускаемые сервисы, которые моделируются вокруг предметной области бизнеса. Они характеризуются четкими и стабильными границами, которые не меняются при изменении внутренней реализации. Такой подход приводит к созданию систем с более слабой связанностью (coupling) и более сильной связностью (cohesion).

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

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

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

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

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

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

Микросервисы должны рассматриваться как сквозные срезы бизнес-функциональности, которые, по возможности, инкапсулируют пользовательский интерфейс (UI), бизнес-логику и данные. Это связано с желанием минимизировать усилия, необходимые для изменения бизнес-функциональности. Инкапсуляция данных и подобное поведение обеспечивают сильную связность бизнес-функций. Сокрытие поддерживающей базы данных также способствует снижению связанности.

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

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

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

Технологическая неоднородность
В системе, состоящей из нескольких взаимодействующих микросервисов, могут быть использованы разные технологии для каждого отдельного микросервиса. Для повышения производительности одной части системы можно использовать другой технологический стек, более подходящий для достижения требуемого уровня эффективности.
Надежность
Главная идея для повышения надежности вашего приложения - это принцип переборки (bulkhead). Если обнаруживается компонент системы, который вышел из строя, мы можем изолировать его, чтобы остальная часть системы продолжала функционировать. Границы сервисов становятся потенциальными переборки. В случае монолитной системы полный сбой одного сервиса приводит к прекращению работы всей системы. Однако, используя микросервисную архитектуру, мы можем работать на нескольких машинах, чтобы снизить вероятность сбоя. А также создавать системы, которые способны справиться с полным отказом определенных сервисов, снижая общую производительность.
Масштабирование
С массивным монолитным сервисом масштабировать придется все целиком. С помощью сервисов поменьше можно масштабировать только ту часть программы, для которой это необходимо. Это позволяет запускать другие части системы на меньшем и менее мощном железе.
Простота развертывания
Микросервисы позволяют внести изменения в один сервис и развернуть его независимо от остальной части системы. Если проблема все же возникает, ее можно за короткое время изолировать и откатиться к предыдущему состоянию. Такие возможности помогают быстрее внедрить новые функции в действующее приложение.
Согласованность рабочих процессов в организации
Микросервисы помогают оптимизировать количество людей, работающих над какой-либо одной кодовой базой, чтобы достичь оптимального соотношения размера команды и эффективности разработки. Это дает возможность переопределять ответственность за сервисы по мере изменения организации.
Повторное использование
Микросервисы и распределенные системы имеют важное преимущество - возможность повторного использования функциональности. Мы можем использовать разные функциональные возможности микросервисов для разных целей. Это особенно важно, когда мы рассматриваем использование нашего программного обеспечения со стороны пользователей.

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

Опыт разработчика
Чем больше у вас микросервисов, тем сложнее их запустить на одной машине для отладки и тестирования. И тем сложнее разработчику разобраться в межсервисном взаимодействии.
Наилучшим решением здесь будет ограничить объем фрагментов, над которыми будет трудиться разработчик. Однако это может быть проблематично, если появится желание использовать модель «коллективного владения». Она подразумевает, что любой разработчик может работать над любой частью системы.
Технологическая перегрузка
Архитектура микросервисов вполне может предоставить возможность написать каждый микросервис на отдельном языке программирования, выполнять его в своей среде или использовать отдельную базу данных. Но это возможности, а не требования. Необходимо найти баланс масштабности и сложности используемой вами технологии с издержками, которые она может повлечь.
Старайтесь внедрять новые сервисы в свою микросервисную архитектуру по мере необходимости. Нет нужды в кластере Kubernetes, когда у вас в системе всего три сервиса. Не перегружая себя сложностью инструментов, вы получаете больше вариантов решения своих задач.
Стоимость
Микросервисы - плохой выбор для организации, ориентированной на снижение расходов в ИТ. Когда сфера ИТ рассматривается как центр расходов, а не доходов, максимальную отдачу от микросервисной архитектуры получить не удастся. С другой стороны, микросервисы могут принести больше прибыли, если вы сможете использовать их для привлечения новых клиентов или для параллельной разработки дополнительных функциональных возможностей. Итак, помогут ли микросервисы разбогатеть? Возможно. Способны ли микросервисы снизить затраты? Не уверен.
Отчетность
С отказом от использования общих баз данных формирование отчетности значительно усложняется, ведь теперь данные разбросаны по нескольким логически изолированным схемам.
В качестве альтернативы можно публиковать нужные для отчетности данные из микросервисов в централизованных хранилищах. Более современным подходом к построению отчетности является потоковая передача данных в режиме реального времени.
Мониторинг и устранение неполадок
В стандартном монолитном приложении мониторинг может быть довольно простым. У нас небольшое количество машин, за которыми нужно следить. Кроме того, состояние приложения в основном является бинарным: оно либо работает, либо нет. Но как это влияет на архитектуру микросервисов, если один из сервисов выходит из строя?
В монолите, если процессор находится под нагрузкой и долго работает на 100%, это является явным признаком серьезной проблемы в системе. Однако, можно ли сказать то же самое о микросервисной архитектуре с десятками или сотнями процессов? Стоит ли будить кого-то в 3 часа ночи, если один процесс подвис на 100% загрузке?
Безопасность
В монолитных системах, основанных на одном процессе, большая часть информации обрабатывается в пределах этого процесса. Однако, в микросервисных архитектурах большая часть данных передается по сети между нашими сервисами. Это может привести к риску утечки данных в процессе передачи, а также открыть возможности для кибератак, таких как "человек посередине".
В связи с этим, необходимо уделить большее внимание защите передаваемых данных, чтобы только авторизованные пользователи имели доступ к ним. Возможно, потребуется принять дополнительные меры для обеспечения безопасности, чтобы предотвратить утечки и несанкционированный доступ к данным.
Тестирование
Написание и поддержка сквозных тестов для любых систем является более сложным заданием по сравнению с модульными тестами меньшего объема. Однако, их цель оправдывает затраты, так как эти тесты максимально приближены к пользовательскому опыту.
В микросервисной архитектуре объем сквозных тестов становится значительным. Теперь требуется запускать тесты в нескольких процессах, а каждый из них должен быть развернут и настроен соответствующим образом для тестовых сценариев. Кроме того, необходимо быть готовыми к ложным срабатываниям. Они возникают, когда проблемы в окружающей среде, такие как сбои экземпляров сервисов или сетевые тайм-ауты неудачных развертываний, могут привести к сбою тестовых сценариев.
Время ожидания
Ранее, вычисления, которые могли быть выполнены только локально на одном процессоре, теперь можно распределить между отдельными микросервисами. Вместо того, чтобы передавать информацию только в пределах одного процесса, теперь необходимо сериализовать данные, передавать их по сети и затем десериализовать на другой стороне. В результате этого процесса может возникнуть увеличение времени ожидания в вашей системе.
Согласованность данных
В распределенных системах, где разные процессы управляют состоянием в разных базах данных, возникают потенциальные проблемы с согласованностью данных. В монолитной архитектуре мы могли полагаться на транзакции в базе данных для обеспечения согласованности изменений состояния. Однако, в микросервисной архитектуре необходимо понимать, что использование распределенных транзакций часто становится проблематичным.

Подведем итоги:

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

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

Надеюсь, данная статья была полезна для вас. Буду признателен, если поделитесь своим мнением в комментариях! Если контент понравился – ставьте лайки и подписывайтесь на мой телеграм-канал. И до скорых встреч, друзья!

3 комментария

NetSleeper

11.06.2023

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

Ответить