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