Использует тот же экземпляр Redis для разных приложений в отношении принципа разделения идей?

Question

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

В настоящее время они взаимодействуют между собой посредством HTTP-вызовов. Когда приложение A нуждается в чем-то, оно отправляет HTTP API-вызов в приложение B. Но поскольку HTTP намного медленнее, чем вызовы Redis, я считаю, что изменить поток, используя Redis set/gets вместо HTTP-вызовов.

Никакие другие приложения не должны иметь такое же отношение, как A и B.

Итак, использует Redis для обмена данными между двумя приложениями вместо вызовов API с разделением принципа озабоченности или нет?

Answer 1

Таким образом, используется Redis для обмена данными между двумя приложениями вместо вызовов API с разделением принципа озабоченности или нет?

Разделение проблем касается того, что ваш код не тесно связан с некоторыми другими классами/системами. Если вы применяете приложение в Redis, вы уже нарушаете принцип SoC.

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

Главный вопрос: как вы собираетесь организовать свои компоненты.

Похоже, вы можете следовать один из approches ржали:

1. Redis работает на том же сервере, что и приложение А (или В) и приложение В (или А) обращается к нему через сеть, когда это необходимо.

2. Redis работает на обоих серверах A и B приложения, работающих как кластер.

3. Redis работает на отдельном сервере, а серверы приложений A и B будут обращаться к нему через сеть, когда это необходимо.

Кроме того, возможно, вам придется создать слой поверх реализации redis, чтобы отделить приложение от конкретной реализации хранилища.

Наличие только одной точки доступа к данным вместо двух ведет вас к принципу SoC, а не наоборот.