it-swarm.com.ru

Микросервисы и базы данных

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

Если у вас есть две таблицы, которые логически различны (если хотите, с ограниченным контекстом), но вы часто выполняете агрегированную обработку больших объемов этих данных, то в монолите вы, скорее всего, не будете обращать внимание на ориентацию объекта и вместо этого будете использовать стандарт вашей базы данных. Функция JOIN для обработки данных в базе данных перед возвратом агрегированного представления обратно на уровень вашего приложения.

Как вы оправдываете разделение таких данных на микросервисы, когда, по-видимому, вам потребуется «объединять» данные через API, а не в базе данных.

Я прочитал книгу Сэма Ньюмана «Микросервисы» и в главе о расщеплении монолита он приводит пример «разрыва отношений с внешними ключами», где он признает, что объединение через API будет медленнее - но он продолжает говорить, что если Ваше приложение в любом случае достаточно быстрое, имеет ли значение, что оно медленнее, чем раньше?

Это кажется немного бойким? Каков опыт людей? Какие методы вы использовали, чтобы соединения API выполнялись приемлемо?

71
Martin Bayly
  • Когда производительность или задержка не имеют большого значения (да, они нам не нужны Они всегда нужны), совершенно нормально просто использовать простые API-интерфейсы RESTful Для запроса дополнительных данных, которые вам нужны. Если вам нужно выполнить несколько вызовов Для разных микросервисов и вернуть один результат, вы можете использовать API Gateway pattern.

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

  • Также не забывайте о кешировании :) Вы можете использовать такие инструменты, как Redis или Memcached , чтобы избежать слишком частых запросов к другим базам данных. 

16
sap1ens

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

Учитывая, что при попытке реорганизовать монолитную базу данных в микросервисы (в отличие от перезаписи) я бы 

  • создать схему БД для сервиса
  • создать версионные * представления ** в этой схеме для предоставления данных из этой схемы другим сервисам
  • присоединяется против этих представлений только для чтения

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

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

* мнения могут быть расширены. Если требуется срочное изменение, создайте v2 того же представления и удалите старую версию, когда она больше не требуется . ** или Table-Valued-Functions, или Sprocs.

5
mcintyre321

CQRS --- Шаблон агрегации командных запросов - это ответ на этот вопрос, согласно Крису Ричардсону. Пусть каждый микросервис обновляет свою собственную модель данных и генерирует события, которые обновят материализованное представление, имеющее необходимые данные соединения из более ранних микросервисов. Это MV может быть любой NoSql DB или Redis или эластичным поиском, который оптимизирован по запросу. Эта техника приводит к возможной согласованности, которая определенно неплоха и позволяет избежать присоединений на стороне приложения в реальном времени . Надеюсь, что это ответы.

3
Praful

Я бы отделил решения для области использования, скажем, от операционной и отчетной.

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

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

1
Jaro64

В Microservices вы создаете diff. читать модели, например, если у вас есть две разности. ограниченный контекст, и кто-то хочет выполнить поиск по обоим данным, тогда кто-то должен прослушать события из обоих ограниченных контекстов и создать представление, специфичное для приложения.

В этом случае потребуется больше места, но соединения не понадобятся и соединения не будут.

0
techagrammer