Развязка монолита без проблем с производительностью

Question

В настоящее время я пытаюсь разделить монолит на микросервисы и сталкиваюсь с проблемами производительности. В настоящее время у меня есть ServiceX, который требует список параметров для запуска, называть их p1, p2 и p3. Однако последние 2 параметра являются структурами данных, которые загружаются из других служб, таких как ServiceY и ServiceZ. Поэтому мне нужно вызвать 2 службы для сбора p2 и p3, прежде чем я смогу вызвать ServiceX. Кроме того, ServiceY и ServiceZ могут иметь свои зависимости от других сервисов. Моя первоначальная стратегия заключалась в том, чтобы вместо этого мой ServiceX попадал в БД напрямую, чтобы получить данные, необходимые мне для p2 и p3. Поэтому мой ServiceX больше не будет зависеть от ServiceY и ServiceZ.

Однако теперь ServiceX сильно страдает от производительности, выполняя эти дополнительные вызовы БД. Кроме того, у меня теперь есть дублирующий код для загрузки p2 в ServiceX и ServiceY и дублирующий код для загрузки p3 в ServiceX и ServiceZ.

Есть ли лучший шаблон, который я должен использовать, чтобы обойти эти проблемы? Данные, предоставляемые ServiceX, ServiceY и ServiceZ, отличаются и принадлежат разным службам.

Answer 1

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

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

Чрезвычайно сложно дать вам разумный ответ, кроме чрезвычайно общих c архитектурных указателей; но, возможно, это поможет.