слишком много остальных API-вызовов в Microservices

Question

Допустим, есть две службы: служба A и служба B.

Службе A требуются данные от службы B для обработки запроса.Чтобы избежать тесной связи, мы делаем API-вызов rest к сервису B вместо непосредственного запроса к базе данных сервиса B.Разве выполнение HTTP-запроса к службе B для каждого запроса не уменьшает время ответа?Я видел другое решение для кэширования данных в службе А. У меня есть следующие вопросы.

1. Что если данные быстро меняются?
2. что делать, если данные критически важны, такие как данные об остатках на счетах пользователей, и должна быть строгая согласованность.
3. А как насчет дублирования данных и их согласованности?
4. Вводя вызов rest, не вводим ли мы точку отказа?Что делать, если служба B не работает?
5. Кроме того, из-за растущих запросов к службе A для этого конкретного API нагрузка на службу B также увеличивается.

Пожалуйста, помогите мне с этим.

Answer 1

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

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

Если эти два компонента действительно являются разными службами, вы также можетерассмотрите возможность перехода к модели, в которой служба B активно публикует данные.Таким образом, служба A может кэшировать соответствующие части данных B.B по-прежнему является источником правды, а A отделен от доступности B (в зависимости от срока действия данных)

Answer 2

Это много вопросов одновременно, позвольте мне дать несколько комментариев в случайном порядке:

• Если службе A нужны данные из службы B, то B ужеединственная точка отказа, поэтому вопрос надежности просто перемещается из базы данных B в конечную точку API B.Маловероятно, что это имеет большое значение.
• Аналогичный аргумент относится к задержке: хороший уровень API, включающий в себя кэширование, может даже уменьшить среднюю задержку.
• Еще раз то же самое с нагрузкой:Зависимость данных A от B уже включает нагрузку на базу данных B.И снова хороший уровень API с кэшированием может даже помочь с нагрузкой.

Таким образом, хотя разделение (от плотного до свободного) приносит много преимуществ, нагрузка и надежность не обязательно находятся в списке недостатков..

Несколько слов о кэшировании:

Чтение кэширования может сильно помочь с нагрузкой. Обычно запрос от A до B должен указывать версию запрошенного объекта, которая доступна в кэше.(возможно, нет), конечная точка B затем может просто проверить, изменился ли объект, а если нет, остановить всю обработку и просто вернуть «неизмененное» сообщение.B может хранить информацию о том, какие сущности изменились в ближайшем прошлом, в гораздо меньшем хранилище данных, чем сами сущности, и, скорее всего, хранит их в ОЗУ или даже в процессе, что заметно ускоряет процесс.

ТакойМеханизм гораздо проще внедрить в конечную точку API для B, чем в саму базу данных, поэтому запросы к API могут масштабироваться гораздо лучше, чем запросы к БД.