19 декабря 2017

Микросервисы: как определить, подойдут ли они вашему проекту

Микросервисы — популярный подход к разработке, который Netflix и Amazon успешно используют больше трех лет.

Мы заметили, что не всегда выбор микросервисов бывает осознанным. Чтобы микросервисы выбирались сознательно, мы решили разобрать наиболее частые вопросы:

В чем преимущества микросервисов?
Для каких решений лучше выбрать микросервисы?

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

Термин «микросервисы» раскрывает Сэм Ньюмен в книге “Building Microservices”: это небольшие и нацеленные на то, чтобы хорошо справляться только с одной работой, автономные, совместно работающие сервисы.

Сама идея разделять систему на независимые компоненты не нова. Предшественником микросервисной архитектуры является сервис-ориентированная архитектура (SOA), которая также разделяет бизнес-логику на компоненты. По сути, микросервисная архитектура — частный случай SOA c набором более строгих правил.

У микросервисов есть особые свойства, они же преимущества:

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

Микросервисы vs монолит

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

Microservices today and tomorrow_2.jpg

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

В таких условиях микросервисная архитектура выигрывает у монолита:

  1. Проще изменить один из микросервисов и сразу внедрить его, чем изменять весь монолит и перезапускать инфраструктуру целиком;
  2. Новые разработчики легче включаются в работу — для этого им не нужно изучать систему целиком, можно работать только над своей частью;
  3. Микросервисы не зависят от какой-либо платформы, поэтому внедрять новые технологии проще, чем в монолит.

Недостатки подхода

Не все так идеально. Микросервисы накладывают ограничения на разработку и поддержку продукта:

  1. Сложность начальной разработки и создания инфраструктуры. Распределенные системы сложнее разрабатывать, т.к. нужно предусмотреть независимость одного микросервиса от сбоя в другом компоненте;
  2. Разработка распределенных систем накладывает дополнительные расходы на обмен данными между микросервисами: нужно правильно выбрать протоколы общения между компонентами, чтобы взаимодействие было максимально эффективно;
  3. Для распределенной системы сложно поддерживать строгую согласованность: общие части системы нужно либо складывать в общую библиотеку, но тогда при изменении этой библиотеки нужно будет перезапускать и все зависимые микросервисы, либо хранить общий код в каждом из микросервисов, но такой код идет вразрез с принципом DRY (Don’t repeat yourself), и его сложнее поддерживать;
  4. Другая структура команды разработки. Команда разбивается на группы, каждая из которых полностью разрабатывает один микросервис. Глава Amazon Джефф Безос предлагает оптимальный размер команды: чтобы их можно было накормить двумя пиццами, т.е. 7-9 человек.


Microservices today and tomorrow_3.jpg

Празднование релиза проекта в IT.Place

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

Сначала — монолит

Мартин Фаулер, один из основоположников идеи микросервисов, предложил объединить оба подхода в один: «Сначала — монолит» (MonolithFirst). Основная идея: «не следует начинать новый проект с микросервисов даже при полной уверенности, что будущее приложение будет достаточно большим, чтобы оправдать такой подход». В монолитном проекте проще наблюдать связность модулей и добавлять новый функционал. Затем система разбивается на несколько частей, и они переделываются в обособленные микросервисы.

Microservices today and tomorrow_4.jpg

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


Главный недостаток такого подхода описан в статье Don’t start with a monolith: сложно разрабатывать монолитную структуру, которую впоследствии можно будет безболезненно разделить на компоненты. С переходом на микросервисы изменятся и команда, и процессы разработки. Например, независимая доставка изменений каждого микросервиса на боевой сервер, версионирование компонентов, дробление команды на группы, достаточные для обслуживания каждого микросервиса.

Для каких решений лучше выбрать микросервисы

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

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

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

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

Понравилась статья?
Подпишитесь на рассылку SimbirSoft! Пришлём письма о лайфхаках в разработке, поделимся опытом управления командами и компанией, а также расскажем о новых ивентах SimbirSoft.

Другие статьи

Вебинар «Красиво vs Качественно. Какие метрики вашего бизнеса зависят от Frontend-разработки?»
12 марта 2024
На форуме Seymartec Energy эксперты SimbirSoft поделятся опытом использовании ИИ в энергетике
07 марта 2024
WMS для управления складом: что такое и как выбрать
07 марта 2024
Написать нам
Оставьте контакты, чтобы обсудить проект и условия
сотрудничества, или позвоните: 8 800 200-99-24
Прикрепить файл до 10Мб
Файл выбран
Можно прикрепить один файл в формате: txt, doc, docx, odt, xls, xlsx, pdf, jpg, jpeg, png.

Размер файла до 10 Мб.
Оставьте свои контакты
SimbirSoft регулярно расширяет штат сотрудников.
Отправьте контакты, чтобы обсудить условия сотрудничества.
Прикрепить резюме, до 10 Мб
Файл выбран
Можно прикрепить один файл в формате: txt, doc, docx, odt, xls, xlsx, pdf, jpg, jpeg, png.

Размер файла до 10 Мб.
Написать нам
Расскажите, какие задачи сейчас на вашем проекте.
Проконсультируем и предложим подходящих специалистов, а также сориентируем по ставкам на аутстаф.
Направление
Количество специалистов
Middle
TeamLead
Senior
TechLead
Прикрепить файл до 10Мб
Файл выбран
Можно прикрепить один файл в формате: txt, doc, docx, odt, xls, xlsx, pdf, jpg, jpeg, png.

Размер файла до 10 Мб.
Экспресс-консультация
Заполните все поля формы.
Эксперт свяжется с вами в течение рабочего дня.
Тематика
Прикрепить файл до 10Мб
Файл выбран
Можно прикрепить один файл в формате: txt, doc, docx, odt, xls, xlsx, pdf, jpg, jpeg, png.

Размер файла до 10 Мб.
Порекомендуйте друга — получите вознаграждение!
  • Middle Fullstack QA Engineer (Mobile)
  • Python-paзработчик
  • Java-разработчик
  • Angular-разработчик
  • Аккаунт-менеджер IT-проектов
  • Системный аналитик
  • QA Engineer Fullstack (Python)
  • C#-разработчик
  • Инженер по нагрузочному тестированию
  • Golang-разработчик
  • DevOps-инженер
  • 1С-аналитик
  • 1C QA Engineer
  • Юрист
  • Разработчик на C++
  • 1С-разработчик
  • DWH-разработчик
  • Разработчик Bitrix24
  • Data Scientist
  • Маркетолог
  • Менеджер по продажам IT SaaS
  • QA Engineer Fullstack (Java/Kotlin)
  • C# /.NET-разработчик
  • Бизнес-аналитик
  • Аналитик DWH
  • Team Lead Java
  • Специалист по адаптации персонала
  • Менеджер проектов 1С
  • Vue-разработчик
  • Руководитель отдела Backend
  • SDET (Java)
  • Менеджер по продажам IT продуктов на иностранное направление
  • Менеджер по продажам IT продуктов
  • IT сорсер
  • Team Lead Python
  • SAP-аналитик
Прикрепить резюме, до 10Мб
Файл выбран
Можно прикрепить один файл в формате: txt, doc, docx, odt, xls, xlsx, pdf, jpg, jpeg, png.

Размер файла до 10 Мб.