Проблема с координацией реплик Node Red в Kubernetes при доступе к IBM Watson Assistant

Question

У меня возникла проблема с IBM Watson Assistant.Я создал 1 контейнер красного узла с 2 репликами в Kubernetes (таким образом, у меня есть 2 контейнера красного узла).Внутри узла-красного потока я обращаюсь к Watson Assistant.

Существует балансировщик нагрузки, который обрабатывает нагрузку между двумя репликами, но есть проблема: для двух реплик разговор-разный, и у меня дваОткрытые чаты в одном (у меня есть 2 разных контекста).

Я не понимаю, как иметь только 1 толькоословие_ разговора только с 1 контекстом.Есть ли способ принудительно использовать параметр session_id с пользовательским идентификатором?

В моей логике узла-красного нет ничего, что могло бы контролировать начало разговора.Я позволил Watson Assistant обработать его и создать начальный идентификатор.

Answer 1

Когда приложение / клиент начинает разговор, связавшись со службой Watson Assistant, не используется message_id как часть вызова API сообщения .В ответе Watson Assistant в объект контекста включается Идентификатор разговора.Затем клиент передает объект контекста обратно в Watson Assistant при каждом вызове сообщения.Все коммуникации не сохраняют состояния и работают в приложениях высокой доступности, которые используют несколько реплик.Часто контекст диалога сохраняется приложением / клиентом и, таким образом, становится доступным для всех реплик.

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