Микросервисная архитектура и совместное использование общих данных приложений.
Сценарий: сегодня существует 17 микросервисов для некоторых онлайн-сервисов социальных сетей, и 9 из них должны знать, кто с кем связан, чтобы их функции работали , Чтобы каждая служба не запрашивала в списке микросервис «проверка подлинности» или «подключения», все службы регистрируются для получения копии подключений на пользователя и сохранения в кеше.
Предложение по механизму доставки данные или инструкция для извлечения данных могут быть rabbitmq.
Однако каждый микросервис представляет собой кластер из docker контейнеров, организованных k8s для масштабируемости.
Каждый контейнер регистрируется для прослушивания коллекции обменов, в которых они заинтересованы ... так что для службы "лента новостей", которая может быть, скажем, 5 соединений ...
Ниже приведена иллюстрация предлагаемой установки: 
- T1 - пользователь A принимает запрос на добавление в друзья
- T2 - Служба соединений (MS1) устанавливает соединение в своей первичной базе данных
- T3 - MS1, опубликованная для rabbitmq exchange указанное событие
- T4 - rabbitmq exchange отправляет все Q (ie все другие зарегистрированные микросервисы)
- T5 - All th Узлы в кластере MS2 получают событие и действуют ... их действие (в этом случае) будет заключаться в обновлении кэша друзей-друзей.
- T6 - пользователь A запрашивает данные для своей ленты новостей, MS2 теперь запрашивает свою базу данных с использованием локального кэша
Это все хорошо:
- Служба подключения не знала или не заботилась, кто получил данные, только что он должен выдавать 1 обмен через единственную точку входа rabbitmq
- Разработчик MS2 должен был знать только о местонахождении экземпляра rabbitmq
- Тот же разработчик всех других служб .. они обрабатывают данные по-своему блестяще.
Единственное исключение состоит в том, что ... было 3 экземпляра MS2, так что было бы 3 записи в базу данных ... если система масштабируется до 10, это будет 10 db пишет et c et c.
Вопрос Как обойти эту проблему ... как обеспечить работу только 1 экземпляра MS2?
Если новостная лента микро услуга будет предоставляться с собственной внутренней системой q для управления данными с биржи? Можно ли направить все сообщения через балансировщик нагрузки, чтобы только 1 экземпляр MS2 получал сообщение? Я не хочу начинать управлять множеством очередей вручную, так как это вызовет боль и лишит простоты дизайн обмена.