Я подумываю о переносе монолитного REST API на микросервисную архитектуру, и меня немного смущает хранение данных. На мой взгляд, некоторые из преимуществ микросервисов:
- Горизонтально масштабируемый - я могу запустить несколько избыточных копий микросервиса, чтобы справиться с нагрузкой и / или отключением сервера.
- Слабосвязанное - я могу изменять внутренние реализации микросервисов, не меняя другие, и я могу самостоятельно развертывать и изменять их и т. Д.
Моя проблема с хранением данных. На мой взгляд, есть несколько вариантов:
- Единая служба базы данных, совместно используемая всеми микросервисами, - это, казалось бы, полностью исключает любые преимущества слабой связи.
- Локально установленный экземпляр базы данных на каждом микросервисе - я не вижу способа горизонтального масштабирования этого, поэтому я не думаю, что это будет вариант.
- Каждый микросервис имеет свою собственную службу базы данных - это кажется наиболее многообещающим, так как он сохраняет преимущества слабой связи и горизонтального масштабирования (с использованием избыточных копий базы данных и / или шардинга между несколькими)
Мне кажется, что третий вариант - единственный вариант, но он кажется мне невероятно тяжелым, и это очень сложное решение. Если я правильно понимаю, то для простого приложения с 4-5 микросервисами мне потребуется запустить 16-20 серверов - два фактических экземпляра микросервиса на микросервис (в случае сбоя сервера и для развертывания без простоя), и два экземпляра службы базы данных на микросервис (в случае сбоя сервера и т. д.).
Это, откровенно говоря, кажется немного смешным. 16-20 серверов для запуска простого API, учитывая, что реалистичный проект, вероятно, будет иметь более 4-5 сервисов? Есть ли какая-то фундаментальная концепция, которая мне не хватает, которая объяснит это?
Некоторые вещи, которые могут помочь при ответе:
- Я единственный разработчик в этом проекте, и буду в обозримом будущем.
- Я использую Node.js и MongoDB, но меня могут заинтересовать независимые от языка ответы - возможно, даже ответом будет то, что я использую не те технологии!
источник
Ответы:
Из ваших трех вариантов наиболее распространенными являются первый (единая общая база данных) и третий («служба базы данных»).
Первая называется интеграционной базой данных . Обычно это не рассматривается как хорошее решение в микросервисной архитектуре. Это добавляет сцепление с вашими услугами. Это также позволяет очень просто обойтись одним сервисом и напрямую запросить базу данных. Вы можете потерять любой вид целостности или проверки данных, обеспечиваемый уровнем приложения, который не применяется на уровне базы данных.
Ваша третья идея называется базой данных приложений . И вы правы - это позволяет вам обеспечить слабую связь на уровне API между сервисами и позволяет более легко масштабировать сервисы на уровне базы данных. Это также облегчает замену базовой технологии базы данных на что-то подходящее для каждой службы, так же как вы можете изменить технологию или другие детали реализации каждой службы. Очень гибкий
Однако я бы предложил промежуточное решение.
Вместо того, чтобы поддерживать службу базы данных для каждого микросервиса, создайте схему для каждого сервиса. Если вы используете несколько технологий баз данных, вам может потребоваться разделить их немного по-разному, но идея состоит в том, чтобы минимизировать количество работающих серверов баз данных, но при этом очень легко разделить службу на собственный сервер базы данных, если и когда это становится необходимым. Пока вы разрешаете базе данных только доступ к своей собственной схеме, у вас есть преимущества базы данных приложения, но без дополнительных затрат на серверы баз данных, существующие для каждого приложения или службы.
Однако, как сольный разработчик, я бы бросил вызов всему понятию микросервисов на данный момент - Мартин Фаулер пишет о Monolith First и Microservice Premium , Саймон Браун рассказывает о модульных монолитах , а DHH рассказывает о Majestic Monolith., Я не уверен, насколько хорошо организован ваш монолит, но реорганизуйте и организуйте его. Определите компоненты и сделайте чистое разделение между ними для простого извлечения деталей в сервис. То же самое относится и к вашей структуре базы данных. Сосредоточьтесь на хорошей, чистой, основанной на компонентах архитектуре, которая может поддерживать рефакторинг в сервисы. Микросервисы увеличивают нагрузку на одного разработчика при создании и поддержке операций. Однако, когда вам действительно понадобится масштабировать часть системы, используйте свои системы мониторинга и отчетности для выявления узких мест, извлечения для обслуживания и масштабирования по мере необходимости.
источник
Согласен. Третий вариант является естественным выбором для микро - услуг. Если микросервис предназначен для того, чтобы быть действительно независимым (а не частью распределенного монолита ), то обычно у них есть база данных.
Вы правы относительно количества запущенных микроуслуг, если хотите иметь баланс нагрузки. Если вы планируете иметь 4 микроуслуги, вам нужно подготовить как минимум 2 экземпляра каждой микроуслуги (всего 8), как вы уже объяснили.
Но две базы данных на микро сервис? Это действительно сомнительно. Я не знаю подробностей о бизнес-проблеме, с которой будут сталкиваться ваши микроуслуги, но избыточность базы данных - это довольно много для большинства продуктов / проектов. Я рекомендую начать с одной единственной базы данных с хорошим резервным копированием и минимизировать (по крайней мере, на начальном этапе) сложность вашей инфраструктуры.
Для простого API эти цифры не совпадают. Обратите внимание, если вы не попадаете в одну из ловушек «Microservice First» .
источник
Микросервисы являются формой сервис-ориентированной архитектуры, возможно, в крайнем случае. Их общая цель состоит в том, чтобы уменьшить связь и обеспечить независимую разработку и развертывание.
Грубо говоря, с точки зрения архитектуры, микросервисы - это термин, который применяется, скажем, на логическом уровне. Микросервисы логически отделены друг от друга. С этой точки зрения каждый микросервис должен иметь свое собственное хранилище, которое должно быть отделено от хранилища других микросервисов. Для микросервисов эта независимость хранения является ключом к их цели модульности и слабой связи.
С архитектурной точки зрения горизонтальное масштабирование применяется на более низком уровне, ближе к реализации, скажем, на физическом уровне. На этом уровне мы внедряем микросервис и можем разложить этот единый микросервис внутри, на компонент без учета состояния, который можно масштабировать по горизонтали, и компонент с состоянием, который используется всеми компонентами без учета состояния. Но давайте не будем путать только часть без гражданства с самим микросервисом.
Итак, когда мы говорим об отдельных микросервисах, мы на логическом уровне говорим об API и разделенных обязанностях и отдельных циклах разработки / развертывания. И когда мы говорим о горизонтальном масштабировании, мы на физическом уровне говорим о реализации (одного) микросервиса и его разложении на компоненты без состояния и с состоянием.
При реализации нескольких микросервисов у нас есть выбор для повторного использования технологии базы данных для компонентов с состоянием:
Подробнее здесь .
Согласитесь, если вы имеете в виду совместное использование строк и столбцов таблиц, это на самом деле не будет микросервисом.
Если мы сможем отделить - в наших мыслительных процессах - логическое понятие микросервисов от более физического представления о компонентах микросервиса с сохранением состояния и без него, нам может оказаться легче добиться слабой связи, предлагаемой микросервисами, при сохранении эффективности общего базы данных.
Как правило, о микросервисах и сохранении состояния написано довольно много, см. Также здесь .
источник
Ну, я прочитал все посты в этой теме и могу сказать, что меня смущает вопрос: он смешивает микросервис (MS) со службами со службой доступа к данным (служба БД) с базами данных и серверами ...
Если MS является независимым (развертываемым) компонентом, решающим одну простую задачу без сохранения состояния, то КАКАЯ база данных ему нужна? Если требуется решить более сложную задачу, для которой требуется решить более одной простой подзадачи (MS?), Это все еще MS? В SOA это называется Orchestrating Service. Он реализует «процесс» и координирует вызов MS, таким образом, он должен сохранять свое состояние (все оркестровки / организаторы / композиторы / и т. Д. С состоянием) и нуждается в личном хранилище данных: никто другой не может изменять состояние оркестратора.
Однако мы говорим не о базе данных, а о MS / Service Database Access, и это совершенно другой вопрос. MS может потребоваться некоторая информация, собранная в компании (не в приложении, в котором она работает), и она не может запросить данные у другой MS через свой API / интерфейс. Это самый распространенный и реалистичный сценарий. И другой MS из того же или другого Приложения может нуждаться в этих данных или даже изменять их. Да, они борются за данные, как это было всегда до появления MS.
Почему мы ломаем «дверь», которая хорошо известна и открыта? В чем разница между РС и обычным самосохраняющимся объектом? Зачем нам нужна отдельная база данных для MS, если она должна (в целях гибкости и возможности компоновки) в любом случае задействовать свою службу доступа к данным (DAS)? Не забывайте, что DAS защищает MS с бизнес-задачей от осведомленности о физическом подключении к базе данных. Эта слабая связь и гибкость, которую MS должна сохранить для свободного участия в нескольких Приложениях без привязки к базе данных.
источник