Микросервисная архитектура недостатки - IT Новости из мира ПК
Remkomplekty.ru

IT Новости из мира ПК
11 просмотров
Рейтинг статьи
1 звезда2 звезды3 звезды4 звезды5 звезд
Загрузка...

Микросервисная архитектура недостатки

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

Микросервисы — популярный подход к разработке, который 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: сложно разрабатывать монолитную структуру, которую впоследствии можно будет безболезненно разделить на компоненты. С переходом на микросервисы изменятся и команда, и процессы разработки. Например, независимая доставка изменений каждого микросервиса на боевой сервер, версионирование компонентов, дробление команды на группы, достаточные для обслуживания каждого микросервиса.

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

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

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

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

Когда оправдано использование микросервисной архитектуры

Микросервисы – это разновидность сервис-ориентированной архитектуры (SOA), применяемая для формирования распределенных программных систем. Модули в микросервисной архитектуре взаимодействуют по сети, при этом выполняя единую цель. На данный момент микросервисы постепенно вытесняют монолитные приложения и превращаются в стандарт развития программных систем.

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

Микросервисная архитектура – это несколько функциональных модулей, взаимодействующих через сеть

Принципиальное отличие микросервисной архитектуры от монолитной

Микросервисная архитектура приложения родилась из монолитной архитектуры, когда та стала сложной и неудобной в работе. Главное отличие микросервисов от монолита – в использовании специализированных более простых программ (модулей) при выполнении сценария приложения. Тогда как в монолитной архитектуре использовались внутрипроцессные взаимодействия. И, что самое удобное, модули могут находиться на разных серверах и их взаимодействие происходит через сеть по протоколонезависимой технологии.

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

  • симметричная архитектура (в монолитных приложениях – иерархическая);
  • взаимозаменяемость микросервисов;
  • независимость микросервисов друг от друга;
  • организация модулей вокруг отдельных функций;
  • написание микросервисов с помощью любых программных средств, оптимальных для каждого конкретного модуля, при этом они хорошо «понимают» друг друга благодаря интерфейсу. Создание интерфейса является наиболее сложной задачей;
  • микросервисы вызываются только потребителем, но не друг другом.

Различие микросервисной и монолитной архитектуры

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

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

Читать еще:  Концептуальная архитектура это

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

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

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

Причины возникновения микросервисной архитектуры

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

Уже тогда микросервисы назвали новой ступенью развития архитектуры, которая обеспечит приложениям необходимую гибкость и легкость. Термин «микросервисы» закрепился в 2011 г. при разработке программного обеспечения, содержащего модули, – но это больше относится к SOA. В 2012 г. термин был принят окончательно, но значение, которое мы используем сегодня, приобрел недавно.

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

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

Микросервисная архитектура устранила недостатки монолитного ПО, обеспечив:

  • изоляцию и минимизацию изменений;
  • ускорение разработки;
  • возможность легко подстраивать ПО под структуру бизнеса.

Необходимость ускорения работы

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

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

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

Разделяя «монолит» на микросервисы, девелопер получает возможность распараллеливания разработки, что значительно сокращает сроки выполнения.

Компоненты микросервисной архитектуры разрабатываются и работают параллельно

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

Быстрый ввод в эксплуатацию

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

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

Микросервисы обеспечивают эффективный подход к разработке, который дает возможность:

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

Необходимость подстраивать сервис под структуру бизнеса

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

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

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

Перспективы использования микросервисов в бизнесе

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

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

Микросервисная архитектура позволяет легко переконфигурировать и усовершенствовать ПО

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

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

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

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

Наша компания исследует ваш бизнес и предложит оптимальный вариант разработки программного обеспечения. Специалисты HHI быстро и качественно проведут тестирование и внедрение.

Записки программиста

Преимущества и недостатки микросервисной архитектуры

Если вкратце, микросервисная архитектура (Micro Service Architecture, MSA), это когда ваше приложение представляет собой много-много небольших (буквально несколько сотен строк кода) сервисов, взаимодействующих между собой путем обмена сообщениями. Это могут быть сообщения Erlang‘а, Cloud Haskell‘я, Akka, или же REST API, Protobuf, Thrift, MessagePack и так далее. Давайте же попытаемся понять, в каких задачах может быть целесообразно использовать такой подход, чем он хорош, и, конечно же, чем он плох.

Но сначала остановимся немного поподробнее на вопросе «что такое MSA».

В действительности, идея не особо нова. Есть такая штука, как SOA (Service-oriented architecture). По всей видимости, все отличие SOA от MSA заключается в размере сервисов. В случае с MSA исходный код каждого отдельного сервиса не должен превышать нескольких сотен строк кода. SOA же такого ограничения вроде бы не накладывает, поэтому в каждом сервисе могут быть десятки или сотни тысяч строк кода. Видимо, MSA — это частный случай SOA.

Идеи, заложенные в MSA, давно знакомы программистам на Erlang. И вправду, редкий gen_server содержит в себе более нескольких сотен строк кода. И общение с внешним миром действительно производится путем обмена сообщениями. Erlang даже позволяет нам обновить код gen_server’а, не повлияв при этом на другие процессы в системе. Однако MSA предполагает, что каждый сервис представляет собой совершенно независимое приложение. Сервисы в системе могут быть написаны на различных языках программирования и общаться между собой, используя различные протоколы. С высокой степенью точности можно сказать, что процессы и сообщения, предлагаемые Erlang’ом — это частный случай MSA.

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

Чтобы не возникало каши в голове, отметим, что Erlang — это такой прикольный язык программирования, Akka и Cloud Haskell — библиотеки, модель акторов — это математическая модель, MSA — это архитектура. Идея примерно одна и та же, но слова и кое-какие детали меняются, в зависимости от того, с кем и на каком уровне абстракции вы общаетесь.

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

  • Писать и поддерживать небольшие сервисы всегда проще, чем большие. Чем меньше кода, тем легче уместить его в голове;
  • Если вы решили использовать REST API, то получаете все присущие ему преимущества. Подробности можно найти в этой и этой заметках;
  • Поскольку каждый микросервис представляет собой отдельный проект, вы можете практически как угодно распределить их между командами разработчиков. Вы можете строить иерархии из сервисов. То есть, некие сервисы будут использованы только парой сервисов, предоставляющих внешний API для других сервисов. Это масштабируемый подход, то есть, над системой могут одновременно трудиться многие десятки программистов. И никаких проблем с разрешением конфликтов или поиском сложных логических ошибок, появляющихся в результате двух коммитов, сделанных разными программистами;
  • Если вы что-то помните о бизнес-моделировании и EPC-диаграммах, то можете к своему удивлению обнаружить, что бизнес-процессы хорошо ложатся на MSA;
  • Для каждого сервиса можно выбрать язык и библиотеки, подходящие конкретно для решаемой этим сервисом задачи. Если нужна скорость, берем C++, если просто гоняем туда-сюда данные, берем Erlang, если нужна какая-то необычная библиотека, берем Clojure;
  • Практически из коробки получаем горизонтально масштабируемый и отказоустойчивый код, да и к тому же с конвейерным параллелизмом. Даже если вы пишите на Python или OCaml. При «монолитном» же подходе часто в целях оптимизации хочется по-быстрому впилить тут кэшик, там кэшек, и в итоге система становится не масштабируемой. Потому что кэши так просто выпилить нельзя, а поддерживать их в актуальном состоянии, когда в системе N копий одного сервиса, не так-то просто. Горизонтальное масштабирование, как известно, приводит к экономии денег, так как система может работать на множестве сравнительно недорогих машин. Более того, под каждый конкретный микросервис можно подобрать железо подходящей конфигурации;
  • Если в программе всего лишь несколько сотен строк кода, в ней не так-то просто сделать ошибку. Необходимость юниттестов становится сомнительной, а использовать языки с динамической типизацией уже вроде как и не страшно. Упрощается тестирование, ибо полностью покрыть тестами API одного сервиса не представляет большого труда. Можно с легкостью замокать внешние сервисы. Понятно, что один мок-сервис можно повторно использовать при тестировании других зависящих от него сервисов. Не требуется специальное тестовое окружение, сервис можно разрабатывать прямо у себя на макбуке;
  • Никто не говорил, что абсолютно все сервисы нужно обязательно писать самому. Всякие там Graphite, RabbitMQ, Riak, PostgreSQL и MySQL, или даже Nginx, отдающий статику с JavaScript, который ходит в наш REST API, также можно рассматривать, как сервисы, являющиеся частью системы. Хотя, конечно же, в них далеко не пара сотен строк кода;
  • Модульность. Захотел сделать апдейт — катишь сервис. Если по метрикам видишь, что что-то не так, откатываешь. В какой-то момент заметили, что в сервис больше никто не ходит — просто выключаем его. Вместо рефакторинга проще выбросить сервис и написать его с нуля. Если где-то в системе крутится ужасный легаси-код, но при этом он работает, пускай себе работает, глаза при этом он никому не мозолит;
  • Нетрудно отследить зависимости между сервисами. Если все сервисы зависят друг от друга, наверное, что-то в архитектуре вашей системы не так. Если количество связей не намного превышает количество узлов, значит вы на верном пути. Также нетрудно найти критические пути, единые точки отказа и так далее;
  • Не страшно экспериментировать с новыми технологиями. Захотел попробовать новый веб-фреймворк, ORM или, например, протащить в проект Haskell — переписываешь существующий сервис и смотришь, насколько это будет работать. Если не работает, откатываешь к старой версии. Попробуйте так просто взять и перейти с Django на другой фреймворк в «монолитном» проекте;
  • Сравнительно нетрудно переписать легаси систему в соответствии с MSA. Ставим перед системой зонтик/прокси. Затем потихоньку выносим компоненты системы в сервисы, а прокси следит за тем, чтобы клиенты ходили туда, куда нужно;
  • Даже если ты пилишь тупо сайтик, с MSA чувствуешь себя крутым разработчиком распределенной системы 🙂
Читать еще:  Архитектура мобильного клиент серверного приложения

Очевидный недостаток всего этого хозяйства заключается в необходимости гонять данные между микросервисами. Если накладные расходы на обмен сообщениями, а также их сериализацию и десериализацию, слишком велики, нужно либо оптимизировать протокол, либо подвинуть взаимодействующие сервисы друг к другу поближе, либо объединить их в один микросервис. Не так-то просто все это админить, хотя, если ваши админы осилили Chef или Ansible, то, скорее всего, особых проблем быть не должно. Очевидно, при использовании MSA следует серьезно отнестись к логированию (вероятно, в отдельный пул сервисов) и мониторингу. Притом те, кто используют MSA, рекомендуют в первую очередь собирать бизнес метрики — количество продаж, результаты А/Б тестирования и так далее. Все это, впрочем, справедливо в отношении любой серьезной системы.

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

  • Пост Micro Service Architecture в блоге James Hughes;
  • Длинный, но преинтереснейший пост о платформах, SOA, Amazon, Microsoft, Facebook и Google;
  • Micro Service Architecture, презентация Eduards Sizovs;
  • Fred George рассказывает о MSA, Clojure, Kafka и утверждает, что можно катить микросервисы в продакшн каждые 10 минут (каждый прогер — дважды в день). Слабо верится, но звучит интересно. Также из этого доклада вы узнаете о хороших практиках MSA, например, что каждый сервис должен отдавать информацию о своем текущем состоянии;
  • Доклад James Lewis под названием Micro Services: Java, the Unix Way. Субъективно послабее, чем у Fred George, но также заслуживает внимания. Вся суть начинается где-то с 21-ой минуты;

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

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

ПРИМЕНЕНИЕ МИКРОСЕРВИСНОЙ АРХИТЕКТУРЫ ПРИ РАЗРАБОТКЕ КОРПОРАТИВНЫХ ВЕБ-ПРИЛОЖЕНИЙ

магистрант, кафедра ПИКС БГУИР,

Беларусь, г. Минск

магистрант, кафедра ПИКС БГУИР,

Беларусь, г. Минск

АННОТАЦИЯ

Данная статья посвящена вопросам целесообразности применения микросервисной архитектуры при разработке корпоративных веб-приложений. Рассмотрены причины возникновения, актуальность применения и основные особенности микросервисной архитектуры.

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

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

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

Уровень представления — уровень, с которым взаимодействует пользователь, включает компоненты пользовательского интерфейса, такие как CSS- стили, статически html — страницы, JavaScript код. Главная функция уровня представления — это отображение информации и интерпритация вводимых пользователем команд с преобразованием их в соответствующие операции в контексте бизнес-логики.

Уровень бизнес-логики — уровень набор компонентов, которые отвечают за обработку данных, полученных от уровня представления, непосредственно взаимодействует с уровнем доступа к данным, может быть реализован с помощью технологий Java EE, ASP.NET.

Уровень доступа к данным — хранит модели данных, используемых сущностей в рамках бизнес-логики приложения, отвечает за мониторинг транзакций и поддерживает консистентное состояние данных. Для большинства корпоративных веб-приложений основная часть логики уровня доступа к данным сосредоточена в СУБД (Система управления базами данных) таких, как MySQL, Oracle и PostgreSQL.

Между тем, корпоративные веб-приложения стремительно эволюционируют, становятся распрелёнными, могут предоставлять определенную функциональность и использоваться в составе другого веб-приложения с помощью веб-сервисов, основанных на протоколах REST, SOAP и XML-RPC. Это приводит к тому, что корпоративные веб- приложения с монолитной архитектурой испытывают сложности с наличием уязвимостей в безопастности из-за участия в процесах множества систем, испытвают сложности с реализацией асинхронной связи между приложениями, испытывают потребность в сложных механизмах управления транзакциями при взаимодействиях между логически раздельными системами и их уровнями.

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

Основные недостатки монолитной архитектуры:

– сложно или практически невозможно изменить технологический стек веб-приложения во время разработки.

– необходимость полного обновления системы при изменении незначительных деталей приложения;

– если веб-приложение аварийно завершает работу, то весь функционал недоступен для пользователей;

– сложности при масштабировании;

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

Структурная схема монолитной архитектуры веб-приложения представлена на рисунке 1.

Рисунок 1. Структурная схема монолитной архитектуры веб-приложения

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

Структурная схема микросервисной архитектуры веб-приложения представлена на рисунке 2.

Рисунок 2. Структурная схема микросервисной архитектуры веб-приложения

Концепция декомпозиции сложной системы корпоративного веб-приложения на микросервисы — это способ создания веб-приложения в виде набора небольших сервисов, каждый из которых исполняется как отдельный процесс, который обменивается данными, используя либо синхронные протоколы, такие как HTTPs(HTTP) или асинхронные протоколы, такие как AMQP.

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

Читать еще:  Среди архитектур эвм выделяют

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

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

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

– использование различных языков программирования и программных средств, оптимальных для реализации каждого микросервиса;

– независимость микросервисов друг от друга, каждый микросервис может быть развернут независимо от других служб;

– упрощение процесса масштабирования разрабатываемого веб- приложения;

– организация микросервисов как модулей вокруг отдельных функций;

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

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

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

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

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

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

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

– понимание принципов работы с событийными приложениями без централизованного хранения рабочих данных;

– убедиться, что логика приложения не зависит от сохранения состояния — это необходимо для того, чтобы реализовать ощутимые преимущества быстрого масштабирования;

– учесть возможные побочные эффекты при работе с асинхронной связью;

– учесть ограничения на обработку ошибок при использовании HTTPs(HTTPs) протоколов, в отличие от внутреннего взаимодействия.

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

Нужны ли вашему проекту микросервисы? Вопросы, которые помогут разобраться

Нужны ли вашему проекту микросервисы? Вопросы, которые помогут разобраться

    Переводы, 16 марта 2020 в 21:59

Автор Алексей Морозов

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

У вас действительно огромный монолит?

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

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

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

Вам действительно нужно масштабировать отдельные компоненты?

Допустим, нужно разработать систему кадрового учёта для организации на 10 000 человек. Поскольку микросервисы — это круто, архитектура будет примерно такой:

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

«ООО «СТМ»», Санкт-Петербург

Одно из достоинств микросервисов — в возможности масштабировать отдельные компоненты по мере необходимости. В принципе это полезно, но есть ли такая необходимость конкретно в вашем проекте?

Возникают ли транзакции, в которых участвует несколько сервисов?

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

REST-сервисы по определению не должны иметь внутреннего состояния, так что им лучше не вступать в сложные операции на несколько сервисов. В мире высокой нагрузки двухфазные коммиты ( 2PC ) — ненужное зло, а паттерн SAGA только добавит сложности.

Часто ли данные передаются между сервисами?

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

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

Что ещё нужно учитывать?

  • Дополнительная сложность . Да, вся идея микросервисов в том, что каждый из них в отдельности становится проще и понятнее. Но систему в целом сложнее деплоить и поддерживать.
  • Дополнительная стоимость . Монолитная система может хоститься на единственной виртуальной машине или в контейнере, а микросервисы (в идеале) хостятся по отдельности. Да, виртуалки будут не такими большими, но их будет много, и скорее всего это будет дороже.
  • DevOps . Это можно считать и за достоинство, и за недостаток, но с микросервисами вам однозначно понадобится DevOps-команда. С одной стороны — её в любом случае неплохо иметь, а с другой — она вам прямо сейчас по карману?
  • Неизбежная связность . Некоторые задачи в вашем проекте наверняка плотно связаны друг с другом по своей природе (тот же учёт сотрудников и учёт зарплат, например). Любая попытка их разделить ради соответствия архитектуре скорее всего закончится печально.
  • Неопытная команда . Это, конечно, проблема для любого проекта. Но в погоне за абстрактным идеалом «микросервисов» можно получить чудовищно плохую архитектуру. Когда сервисы перестанут работать, если их деплоить в неправильном порядке, или когда падение одного сервиса обрушит все остальные, будет уже слишком поздно.
  • Сложность тестирования . Для монолита тесты обычно запускаются одной командой, а для тестирования набора взаимосвязанных сервисов нужна отдельная система.
  • Совместимость данных . Согласование форматов данных в пределах одной команды — это совсем не то же самое, что согласование между несколькими командами, которые к тому же могут находиться на разных концах планеты и/или программировать на разных языках. На обсуждение спецификаций неизбежно потребуются дополнительные время и силы.
  • Поддержка старого кода. Давайте честно: большинство систем не создаётся с нуля. Новая архитектура — это хорошо, но она усложняет взаимодействие с уже имеющимся кодом, и неплохо бы убедиться, что ваш новенький микросервисный фреймворк будет нормально работать с приложением, которое уже 20 лет как крутится на IBM AIX .
  • Отладка и мониторинг . Отдельные системы — это в том числе и отдельные логи. Найти ошибку где-то в пяти раздельных лог-файлах сложнее, чем в одном.

Значит ли это, что не стоит пользоваться микросервисами? Нет. История Netflix вдохновила многих, и вполне заслуженно. Uber , SoundCloud и Amazon используют микросервисы и делают с их помощью вещи, которые раньше казались невозможными. Но это не означает, что микросервисы — идеальная архитектура, подходящая для всех проектов.

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

Ссылка на основную публикацию
ВсеИнструменты
Adblock
detector
×
×