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

Микросервисы — это способ создания приложений на основе небольших компонентов, которые применяются для конкретных задач. По прогнозам IDC, в 2020 г. 90% программ будут задействовать архитектуры микросервисов. На них либо переходят, либо уже перешли многие из крупнейших мировых брендов, включая Google, Netflix и Uber. В отличие от крупных монолитных или традиционных трехуровневых приложений, приложения на основе микросервисов проще обновлять и добавлять в них новые функциональные возможности.

CIO рассчитывают, что внедрение микросервисов вызовет воодушевление в среде разработчиков и будет способствовать ускоренному развертыванию приложений. В то же время директора по работе с данными (chief data officer, CDO) могут оказаться не в восторге от перехода на микросервисы. Причина этого заключается в том, что новые архитектуры будут стремительно генерировать поток данных, с которым будет сложнее работать в масштабе. Разработка приложений без правильного подхода к управлению и моделированию данными может привести к проблемам для предприятий. Так как же CIO и CDO правильно организовать работу, чтобы выжать максимум из приложений на базе микросервисов, но при этом не нарушить процессы управления данными?

Приложения без сохранения состояния и их данные

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

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

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

Для достижения этой цели существует несколько способов: создание для каждой службы приватных таблиц (private-tables-per-service), схем (schema-per-service) или БД с выделенными серверами (database-server-per-service). Несмотря на то, что накладные расходы на содержание приватных таблиц и схем, которые представляют из себя отдельные логические структуры, самые низкие, некоторые высокопроизводительные сервисы отдают предпочтение собственным, приватным БД. В целом использование приватной схемы или БД для каждой службы является наиболее выгодным решением, поскольку оно четко определяет границы собственности и обеспечивает инкапсуляцию.

Запускайте свою БД тем же образом, что и приложение

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

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

Как правило, традиционные БД могут масштабироваться только по вертикали — это касается как операций чтения, так и записи, поэтому для наращивания их дальнейшей производительности к хост-компьютеру следует добавить CPU, память и хранилище. Достигнуть горизонтального масштабирования можно при помощи сегментирования и архитектуры master-slave, но это создает дополнительные сложности и увеличивает потенциальную вероятность сбоя. Управление усложняется за счет синхронизации реплик (копий), ожидаемого времени простоя при отключении главного узла и наличия копий, доступных только для чтения.

Исходя из этого, при выборе оптимального компонента лучше всего отдать предпочтение распределенным БД, таким как Apache Cassandra. Ее применение рассчитано на поддержку распределенной природы приложений на базе микросервисов путем централизации БД в единый экземпляр, чтобы упростить хранение данных во время транзакций. Например, британский банк Monzo располагает набором из 1500 сервисов на базе технологии микросервисов, позволяющих обслуживать более 3 млн. клиентов. Все они связаны в один экземпляр БД, который работает под управлением Cassandra.

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

Совместное развертывание микросервисов и данных в масштабе

Чтобы удовлетворить потребности клиентов, для CIO и CDO жизненно важным является возможность масштабирования приложений на базе микросервисов. Одновременно с этим важен прицел на дальнейшее расширение данных. Масштабирование достигается путем размещения приложений сразу в нескольких ЦОДах по всему миру или в гибридных облачных средах, что позволяет обеспечить клиентам мгновенный доступ к данным, например об обработке заказов или совершенных транзакций. Оно также способствует выполнению прикладных требований, таких как высокая доступность сервисов с одновременным соблюдением норм законодательства, которые характерны для того или иного географического региона.

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