Создание быстрых и масштабируемых микросервисов с помощью Apache Cassandra и Pulsar

Автор: Джонатан Лейсфилд

Спросите любого разработчика микросервисов, что, по их мнению, является самой сложной частью микросервисов, и он скажет вам, что это данные. Мы верим, что есть лучший способ. Читайте дальше, чтобы узнать, насколько проще создавать микросервисы с помощью DataStax, используя Apache Cassandra для хранения данных, Apache Pulsar для обмена сообщениями, потоковой передачи и функций, а также API-интерфейсы Stargate.

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

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

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

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

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

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

Шаблон базы данных для каждой службы также позволяет каждой микрослужбе в системе использовать тип базы данных, наиболее подходящий для ее нужд. Apache Cassandra® — это проверенный выбор базы данных для шаблона проектирования базы данных для каждой службы, поскольку в случае с микрослужбами масштаб имеет значение. И когда масштаб имеет значение, Cassandra — логичный выбор.

Другой способ думать о базе данных для шаблона службы

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

Stargate — это шлюз с открытым исходным кодом, предоставляющий C* с поддержкой GraphQL. Используя Stargate с Cassandra, доступ к моделям данных может осуществляться с использованием протоколов для конкретных моделей, таких как REST, GraphQL и gRPC.

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

Распространенными шаблонами проектирования распределенных транзакций являются Saga, Разделение ответственности за команды и запросы (CQRS), Событие домена, Источник событий и Исходящие транзакции. Для извлечения данных между службами федерация является явным победителем благодаря GraphQL. Мы видим реализации шаблонов проектирования композиции, таких как события предметной области и агрегаты, которые используются поверх GraphQL.

Здесь, в DataStax, мы объединяем Pulsar и Cassandra в единую платформу данных в качестве нашего решения данных для всех шаблонов проектирования потока данных микросервисов. Это связано с тем, что атомарность является ключом к шаблонам проектирования, связанным с распределенной обработкой транзакций. Для нескольких различных шаблонов проектирования требуются атомарные гарантии в рамках одной службы, чтобы гарантировать, что изменения данных сохраняются в базе данных и публикуются в других службах как одна операция. Это особенно важно для шаблонов проектирования, основанных на Event Sourcing. Другие шаблоны проектирования требуют более сложных гарантий атомарности. Такие шаблоны проектирования, как Saga, CQRS, а также шаблоны управления транзакциями более высокого уровня требуют атомарности для комбинаций сервисов, рабочих процессов, агрегатов на уровне домена и/или между доменами.

Варианты добавления атомарности в архитектуру микросервисов

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

Подход CDC (то есть пошаговая обработка) — отличный вариант из-за его простоты. DataStax интегрировал Cassandra и Pulsar, чтобы предоставить решение без кода, которое автоматически раскрывает мутации Cassandra для тем Pulsar. Пользователю просто нужно настроить CDC для своей таблицы, и он будет получать поток событий изменений Pulsar по мере их сохранения.

Другой вариант — Pulsar Functions, бессерверная вычислительная среда, которая является частью Apache Pulsar. Функции Pulsar можно использовать для инкапсуляции атомарной логики, обертывающей мутацию базы данных с публикацией соответствующего события как части одной транзакции. На языке микросервисов это называется локальной транзакцией, которая гарантирует атомарность событий, поступающих в системы микросервисов. В отличие от CDC, Pulsar Functions требует, чтобы разработчики микросервисов кодировали логику для обеспечения гарантий атомарности. Функции Pulsar — отличный вариант, когда для поддержки локальных транзакций требуется сложная логика.

Когда требуется межсервисная атомарность, обмен сообщениями и бессерверные функции могут использоваться для управления атомарным потоком данных между сервисами. Отличным примером этого является шаблон проектирования Saga. Саги обеспечивают распределенную межсервисную атомарность посредством скоординированного набора «локальных транзакций». Pulsar Functions — отличный выбор для реализации саг. Они предоставляют разработчикам микросервисов возможность создавать сложные логические процедуры, гарантирующие, что поток «логических транзакций» завершится успешно или не удастся. Те же логические методы могут быть применены к другим шаблонам потока данных «более высокого порядка», таким как CQRS (где реплики чтения требуют атомарных гарантий) и транзакционный исходящий ящик.

Сочетание возможностей обмена сообщениями и потоковой передачи Pulsar с масштабируемостью и возможностями нескольких API Cassandra — это гигантский шаг вперед для групп микросервисов, стремящихся реализовать распределенные транзакции. Команде больше не нужно совмещать функциональность обмена сообщениями и функциональность базы данных. Им также не нужно поддерживать, защищать и управлять несколькими системами только для поддержки потока данных в системах микросервисов.

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

Доступ к данным — не единственное, что могут предоставить API

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

В прошлом году Apollo выпустила Apollo Federation, специально созданный инструмент с открытым исходным кодом, который оптимизирует использование GraphQL в архитектурах микросервисов. TL;DR здесь заключается в том, что предприятие теперь может работать с полной схемой, которая соединяет все источники данных в рамках распределенной архитектуры, где отдельные команды владеют своей частью графа. Другими словами, Apollo Federation сочетает в себе преимущества корпоративной модели данных с преимуществами двух пиццерий.

Чтобы предоставить пользователям Cassandra и GraphQL преимущества Apollo Federation, DataStax заключила партнерское соглашение с Apollo для интеграции инструмента Apollo Federation с проектом Stargate с открытым исходным кодом.

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

Подпишитесь на Технический блог DataStax, чтобы узнать больше историй разработчиков. Посетите наш канал YouTube для учебных пособий и здесь для разработчиков DataStax в Twitter, чтобы узнать последние новости о нашем сообществе разработчиков.