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

Наша команда максимально коротко и просто расскажет о набирающем популярность способе разработки, а также продемонстрирует преимущества и недостатки микросервисов.

Популярность использования микросервисов не утихает до сих пор. Достаточно посмотреть, например, на «Netflix», которые активно продвигают данную технологию в массы, ну а такие гиганты как «Amazon», в свою очередь, с 2015 года регулярно выпускают в ведущих издательствах книги о микросервисной архитектуре и даже проводят несколько регулярных конференций, целиком посвящённых микросервисам.

Но почему тема микросервисов так популярна и в чем ее принципиальные польза и отличия от обычного, «монолитного» способа разработки?

Давайте вспомним историю

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

Главная проблема такого подхода была обнаружена множеством новых компаний, таких как «Facebook», «Uber» и «Spotify», которые пришли с инновационными идеями, агрессивной стратегией и решением быстро двигать иной способ разработки, который бы приводил к высокому росту их приложений.

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

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

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

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

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

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

Почему разработка микросервисов пользуется спросом?

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

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

В отличие от монолитных приложений, микросервисная архитектура имеет ряд преимуществ:

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

2. Распределение работы по созданию отдельных модулей можно распределить между разными командами.

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

4. Наиболее легкая и простая возможность проведения обновлений при микросервисной архитектуре – постепенный процесс не затормозит работу всей системы.

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

6. Учет очередности: сервисы можно разрабатывать и внедрять постепенно, в зависимости от очереди потребностей бизнес-подразделений.

7. Многоканальность: микросервисы могут работать на любом устройстве, а также в on-premise и облачных средах.

Но также существуют и недостатки:

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

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

3. Сложность соблюдения баланса нагрузки и отказоустойчивости.

Подробнее о недостатках можно почитать здесь.

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

В заключении

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

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

Если же у вас диаметрально-противоположная ситуация, например, в виде 8 команд, работающих над одним продуктом, то микросервисы будут вашим идеальным выбором.

Конечно, это далеко не единственные факторы, ведь стоит учитывать сложность разработки и скорость изменений: при высоким темпах и крайне высокой сложности монолитная разработка также станет серьезным “костылем”.