Микросервисная архитектура пример — Мир ПК

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Микросервисы: как управлять данными в архитектуре будущего?

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

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

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

С точки зрения бизнеса, микросервисы привлекательны тем, что более разнообразную функциональность удается предоставить быстрее.

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

Идеальный микросервис должен полностью изолировать свои данные (инкапсуляция) от внешнего мира и предоставлять их только с помощью API. Цель состоит в том, чтобы избежать «привязки к данным» (data coupling), при котором изменение в представлении данных одним микросервисом необходимо координировать с разработчиками других микросервисов.

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

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

Проблемы инкапсуляции данных

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

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

Простое приложение, реализованное с использованием микросервисов

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

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

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

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

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

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

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

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

Более простой путь

В идеале, хорошо было бы иметь более простой способ получить преимущества высокой скорости и производительности, присущие модели микросервисов, но избежать сложности управления данными. Знакомая многим база данных Oracle Database предлагает для этого уникальные возможности.

При использовании Oracle Database каждая группа разработчиков может свободно создавать подключаемые базы данных (Pluggable DataBase, PDB), применяя любую модель данных по своему усмотрению: JSON/XML, ключ/значение, пространственную/графовую, объектную, реляционную или другую. PDB — это небольшие, легкие, изолированные логические базы данных, которые находятся в более крупной базе данных — контейнере (Container DataBase, CDB).

PDB можно по мере необходимости независимо масштабировать, используя такие методы, как операции в оперативной памяти (in-memory) и шардинг (Sharding — разновидность секционирования базы данных). Если требуется, их можно легко копировать и перемещать. PDB также получают полный, расширенный набор возможностей базы данных Oracle. Таким образом, разработчики могут делать со своим микросервисом все, что необходимо, но потребность в координации действий с другими разработчиками значительно меньше.

База данных Oracle давно поддерживает мощную функцию, минимизирующую влияние привязки к данным: переопределение в зависимости от редакции (Edition-Based Redefinition, EBR). Благодаря EBR разработчики могут изменять представления (views) и логику по мере необходимости, сохраняя унаследованные представления БД (database view) и логику для тех, кто в этом нуждается. Обновления в старых или новых редакциях можно легко распространять с помощью триггеров.

Как этот подход помогает в решении общих проблем управления данными при работе с микросервисами?

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

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

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

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

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

Кроме того, с помощью механизмов Oracle Advanced Queuing (AQ) можно реализовать очередь сообщений. Она обеспечивает надежную доставку сообщений — ничего никогда не потеряется.

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

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

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

Эта эффективность относится и к навыкам. Ведь в большинстве организаций есть люди, уже знакомые с Oracle Database.

Лучшее из обоих миров?

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

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

Избежать привязки к данным можно несколькими способами. Но только используя проверенные расширенные функции базы данных Oracle — подключаемые базы данных, переопределение структуры данных в зависимости от редакции (Edition-Based Redefinition), Advanced Queuing, in-memory, шардинг и т. д. — организации могут реализовать преимущества приложений на основе микросервисов без лишних усложнений и роста стоимости разработки.