Поддержка  •  Дневник  •  Без рекламы  •  О сайте  •  Реклама  •  Поставить баннер  •  Fleshlight  •  Прислать  •  Хроника  •  Translate Гости: 7    Участники: 0 Авторизация Авторизация   Регистрация 
Метод Научного Тыка
RULVEN
Поиск  
Blackball iMag | интернет-журнал
Каталог


Начало » Разработка ПО » Микросервисы: как определить, подойдут ли они вашему проекту
Мне повезёт!

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


Добавлено: Пн 02.12.2019 • Sergeant
Источник: источник
Просмотров: 603
Комментарии: 0


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


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

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

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

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

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

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

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

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

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

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

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



Мне нравится 0   Мне не нравится 0



Комментарии

Чтобы добавить видео с YouTube, нужно написать [@youtube=xxxxx] , где xxxxx – ID видео.


Комментарии: 0
Нет ни одного комментария.
RSS-лента
Поделиться ссылкой:
Запеченные роллы – 10 рецептов в домашних условиях Запеченные роллы – 10 рецептов в домашних условиях
Коктейль виски со Швепсом – оригинальные и согревающие рецепты Коктейль виски со Швепсом – оригинальные и согревающие рецепты
Освежающие алкогольные коктейли со «Швепсом» – популярные рецепты Освежающие алкогольные коктейли со «Швепсом» – популярные рецепты
Пастила из желатина: как приготовить нежную пастилу с желатином в домашних условиях Пастила из желатина: как приготовить нежную пастилу с желатином в домашних условиях
Какого черта мы нанимаем, или осмысленность собеседований в IT
Гридирон (Решетка для пытки огнем)
Вкусные бутерброды на праздничный стол Вкусные бутерброды на праздничный стол
Запускаем приложения Android на компьютере с Windows Запускаем приложения Android на компьютере с Windows
25 самых дорогих видов шоколада в мире 25 самых дорогих видов шоколада в мире
20 отличных рецептов куриных сердечек на мангале 20 отличных рецептов куриных сердечек на мангале

Новое
20 отличных рецептов куриных сердечек на мангале 09:06
20 отличных рецептов куриных сердечек на мангале
Какие полочные акустические системы стоит выбрать в 2023-2024 годах? 3 дня назад, 09:01
Какие полочные акустические системы стоит выбрать в 2023-2024 годах?
Архитектуры разработки ПО Пн 13.05.2024
Архитектуры разработки ПО
Сб 11.05.2024
Технический долг. Как не обанкротиться
Что такое технический долг и как им управлять Сб 11.05.2024
Что такое технический долг и как им управлять
20 рецептов из горбуши, которые станут вашими любимыми Сб 11.05.2024
20 рецептов из горбуши, которые станут вашими любимыми
Как работает спидометр в машине: вы всегда хотели это знать, но никто не мог объяснить на пальцах Ср 08.05.2024
Как работает спидометр в машине: вы всегда хотели это знать, но никто не мог объяснить на пальцах
5 ошибок при разработке высоконагруженных сервисов Пн 06.05.2024
5 ошибок при разработке высоконагруженных сервисов
20 способов приготовить куриные голени в духовке Вс 05.05.2024
20 способов приготовить куриные голени в духовке
Жаркое из курицы: 20 лёгких и вкусных рецептов Сб 04.05.2024
Жаркое из курицы: 20 лёгких и вкусных рецептов
Книги
Designing Data-Intensive Applications Вт 14.05.2024
Designing Data-Intensive Applications
Год: 2017
Fundamentals of Software Architecture Вт 07.05.2024
Fundamentals of Software Architecture
Год: 2020
Refactoring with C# Вт 23.04.2024
Refactoring with C#
Год: 2023

Разработано на основе BlackNight CMS
Release v.2024-05-18
© 2000–2024 Blackball
Дизайн & программирование:
О сайтеРеклама
Visitors
Web-site performed by Sergey Drozdov
BlackballРекламаСтатистикаПоддержка | МузыкаПлейлистыКиноВидеоИгрыАудиоПрограммыСтатьиКартинкиЮморФорумДневник сайтаПрислать контент