Подключение микросервисов и баз данных

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

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

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

Я прочитал книгу Сэма Ньюмана Microservices и в главе о разделении Монолита он приводит пример "Нарушения внешних ключей", где он признает, что совместное использование API будет медленнее - но он продолжает сказать, если ваше приложение достаточно быстро в любом случае, имеет ли значение, что он медленнее, чем раньше?

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

Ответ 1

Когда производительность или латентность не слишком важны (да, мы не всегда им нужны), это прекрасно, просто использовать простые API RESTful для запроса дополнительных данных. Если вам нужно сделать несколько звонки на различные микросервисы и возврат одного результата, который вы можете использовать API Gateway.
Совершенно нормально иметь избыточность в средах Полиглот. Например, вы можете использовать очередь сообщений для своих микросервисов и отправлять события "обновления" каждый раз, когда вы что-то меняете. Другие микросервисы будут прослушивать требуемые события и сохранять данные локально. Поэтому вместо запроса вы сохраняете все необходимые данные в соответствующем хранилище для конкретного микросервиса.
Кроме того, не забывайте о кешировании. Вы можете использовать такие инструменты, как Redis или Memcached, чтобы избежать слишком частого запроса к другим базам данных.

Ответ 2

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

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

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

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

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

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

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

Ответ 3

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

Ответ 4

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

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

Ответ 5

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

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

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