Сегодня разработчики любят использовать микросервисы для своих приложений. Но любят ли их приложения в равной степени создавать и хранить данные?

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

Микросервисам также помог рост контейнерных технологий программного обеспечения, таких как Docker, и быстрый рост Kubernetes для оркестровки контейнеров. Эти подходы упростили управление масштабированием приложений микросервисов вверх и вниз в облаке.

Тем не менее, важно помнить две вещи: во-первых, микросервисы не принимаются, потому что это отличная теория для разработки программного обеспечения. Вместо этого он доказывает свою ценность: предприятия, использующие микросервисы, могут выполнять новые требования и быстрее внедрять эти изменения. В том же опросе, проведенном О'Рейли, 86 процентов респондентов заявили, что переход на микросервисы был, по крайней мере, частично успешным. Во-вторых, эти приложения создают данные, и эти данные должны выходить за пределы самого приложения.

Итак, как базы данных вписываются в новый мир микросервисов?

Приложения и данные микросервисов - приложениям без сохранения состояния требуются данные с сохранением состояния

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

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

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

Где вы могли бы использовать микросервисы и базы данных вместе?

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

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

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

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

Микросервисы, базы данных и облачный дизайн

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

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

Альтернативой RDBMS является семейство баз данных NoSQL, которые были разработаны для лучшего соответствия потребностям облачных приложений. Для приложений, основанных на микросервисах, размещение экземпляров базы данных как можно ближе к программным компонентам может помочь уменьшить задержку и повысить производительность. Для баз данных, таких как Apache Cassandra, легче масштабировать и обрабатывать больший объем записей, которые могут создавать программные компоненты, поскольку узлы могут существовать в одном и том же облачном экземпляре или регионе.

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

Наряду с этим выбором базы данных для развертывания важно также учитывать, кто будет управлять вашей базой данных. Для разработчиков работа с кластером базы данных может быть дополнительной рабочей нагрузкой, которую они хотят избежать. Вместо этого лучше рассмотреть вариант «Database-as-a-Service ». Это может привести к накладным расходам на управление и обновление приложения, а также к улучшению настройки и производительности.

Содействие микросервисам с правильным подходом к базе данных

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

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

No Comments