Разработка микросервисной архитектуры — Мир ПК

Макро-польза микро-сервисов: мост от legacy-архитектур к современному IT

Блоги, 17 марта 2019 в 1:32

Рассказывает Антон Херувимов, Technology Delivery Lead в компании Accenture Russia.

Цифровая трансформация, новые возможности digital-инструментов и архитектуры современных ИТ-систем создают парадигму современных технологий (New IT — так называет её компания Accenture). Она включает в себя самые продвинутые технологии (облака, ИИ, аналитику данных, машинное обучение и т. д.) и процессы (Agile, DevOps и Design Thinking), а также подразумевает несколько стадий трансформации сложной ИТ-инфраструктуры крупных компаний. Одним из первых шагов к её реализации становится адаптация слоя ИТ-микросервисов на базе существующих legacy-платформ.

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

Микросервисы для большого ИТ-будущего

Термин «микросервисная архитектура» (Microservice Architecture) обрёл популярность в последние несколько лет. Это способ разработки приложений через объединение независимо развёртываемых ИТ-сервисов. Такой подход позволяет построить вокруг сложившихся бизнес-процессов и потребностей автономный сервис. Благодаря использованию стандартных протоколов взаимодействия, например HTTP-вызовов через API и брокеров сообщений, микросервисы могут быть написаны на разных языках программирования и использовать различные технологии хранения БД.

При традиционном подходе к созданию ИТ-системы по принципу «монолита» управление больше фокусируется на технологиях. Команды формируются по технологическому принципу — разработчики, администраторы БД, аналитики данных и т. д. Такой подход вызывает серьёзные трудности при реализации бизнес-функциональности в ИТ-систему, поскольку их нужно производить через кросс-командное взаимодействие.

Микросервисы позволяют формировать независимые (agile) кросс-функциональные команды с фокусом на определённой бизнес-задаче вместо технологии. Такие команды самодостаточны, хорошо сфокусированы, используют те подходы и технологии, которые максимально эффективны в конкретном случае и позволяют переключиться с «проектного управления» на «продуктовое».

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

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

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

По сути, микросервисы — это слой между существующей ИТ-инфраструктурой и клиентской частью интерфейса. Его можно с успехом применять практически в любой области и для решения самых разнообразных задач. Также при выборе стратегии ИТ-развития компании в пользу полного отказа от «коробочного» подхода, микросервисы могут стать надёжным и эффективным ядром новой digital-платформы для успешного роста бизнеса в 21 веке.

6 главных преимуществ микросервисной архитектуры

1. Новое качество масштабируемости. При возникновении соответствующей потребности не нужно масштабировать всю систему, разбирая её до основания, — достаточно внести необходимые изменения только на определённом участке.
2. Повышение стабильности. Поскольку микросервисы независимы друг от друга, сбои и дефекты в одном из них никак не влияют на работу остальных, система функционирует с минимальными сбоями и простоями.
3. Упрощение. Вместо единого и сверхсложного массива ИТ, компании работают с более управляемой архитектурой, где каждый компонент отвечает за свою функцию.
4. Мультиплатформенность. Микросервисы могут работать на любом устройстве, а также в on-premise и облачных средах.
5. Повторное использование. Микросервисы могут перепрофилироваться для других целей и задач после начального запуска.
6. Возможность использовать разные технологии. Agile-команды в компаниях могут работать как небольшие стартапы, не ограничиваясь одной определённой платформой или технологией благодаря микросервисам. Через микросервисы организации могут объединять различные технологии для создания действительно лучшего из всех возможных решений на настоящий момент, что значительно ускоряет внедрение инноваций.

Трудности внедрения микросервисов

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

Однако существует ряд подводных камней при реализации такого перехода.

Сохранение целостности компании

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

Большое количество микросервисов

Когда компании необходимо 10–20 микросервисов, их адаптацией и развитием управлять не так сложно. Но если организация требует для своих задач внедрения 100+ микросервисов, появляется ранее не существовавший класс задач. Как избежать дублирования функциональности, сохранить масштабируемость и управляемость, а также не допустить превращения новой архитектуры в такой же монолит, от которого изначально пытались уйти?

Для организаций эти вызовы и их различные формы и складываются в современное IT, когда от подхода «строим то, что позволяет система» делается качественный скачок к «развиваем систему таким образом, чтобы у нас появлялись новые возможности для перестройки бизнеса». Компания, которая осознаёт необходимость адаптации микросервисов, нацеливается не на рост прибыли, трафика и других количественных KPI, а на глубинные изменения, при которых рост KPI — органическое следствие общей трансформации.

Баланс гибкости и хаоса

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

Переход к микросервисам в рамках концепции enterprise agility — это также вопрос корпоративной культуры, которая помогает сохранять необходимый баланс свободы и контроля.

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

Время и результаты

Перевод ИТ-ландшафта организаций на новую архитектуру не происходит за одну ночь. Как раз наоборот, иногда для этого требуется довольно длительное время, в каких-то случаях — целые годы. Мало какие вещи в современном мире настолько же сложны, как современные ИТ-системы, адаптированные к бизнес-моделям компаний, а также конкретные способы их привязки друг к другу. Тем не менее, несмотря на общую трудоёмкость демонтажа legacy-систем, полагаться на «олдскульные» ИТ в эпоху, когда парадигма New IT развивается семимильными шагами, — значит обрекать бизнес на медленную агонию. Отсюда и вытекает потребность в микросервисной архитектуре.

Продвинутые микросервисные архитектуры в их образцовом исполнения представлены сегодня в таких компаниях, как Google, Amazon и Netflix. Так, Amazon вносит изменения в свои продукты каждые 11,6 секунд, а Netflix постоянно проводит выборочные отключения вычислительных узлов для проверки влияния подобных аварий на общее качество продукта, получаемого абонентами.

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

Между тем, в последующие 10–20 лет legacy-модели должны быть полностью заменены на новейшие решения компаниями, которые хотят сохранить свою конкурентоспособность. В этой перспективе микросервисы и монолитные системы могут сосуществовать как привитая ветвь и ствол дерева, на котором ей предстоит прорасти и в будущем заменить собой отмирающую основу. Такой подход позволяет гарантировать, что корневая система останется незатронутой и медленно, но верно, перейдёт от старого владельца (legacy-систем) к новому (микросервисы и парадигма New IT).

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Однако первые пользователи столкнулись с серьезной проблемой — управлением данными. Типичные корпоративные приложения обмениваются информацией посредством совместно используемых баз данных. В мире микросервисов это против правил: в идеале должно быть достаточно интерфейсов прикладного программирования (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, шардинг и т. д. — организации могут реализовать преимущества приложений на основе микросервисов без лишних усложнений и роста стоимости разработки.