Микросервисная Государственная Синхронизация - PullRequest
1 голос
/ 09 февраля 2020

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

Чтобы дать вам некоторые характеристики:

  • Мы используем docker роя
  • Это NodeJS Backend и Angular 9 Frontend

Мы рассмотрели несколько идей, например:

  • Redis Cache (состояние не будет удалено если сбой экземпляра.)
  • Очереди / Темы (Это будет означать, что каждый экземпляр должен отслеживать текущее состояние всех клиентов.)
  • WebSockets между экземплярами (Это выглядит многообещающим, но это не так действительно масштабируемый.)

Как лучше синхронизировать c состояние микросервиса между несколькими экземплярами, при этом следя за тем, чтобы не было несоответствий? Как вы решаете эту проблему? Мы что-то упускаем из виду? Любые советы и рекомендации?

Мы ценим любые предложения.

1 Ответ

1 голос
/ 09 февраля 2020

Это может быть не на 100% то, что вы хотите услышать, но обычно люди советуют, чтобы все микросервисы не имели состояния .

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

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

...