Эта архитектура µService работает как серверная часть, а экземпляр консула управляет всеми службами. Есть конкретный сервер A, созданный с помощью Sails, и с некоторой соответствующей логикой сокетов, которую я хотел бы использовать из другого сервиса B с помощью Sailes.io.
Каждый сервис работает в своем контейнере Docker, но все они подключены к одной сети.
Итак, при разработке я запускаю контейнер A локально и моделирую службу B с помощью сценария узла, с показанной логикой здесь. URL-адрес службы довольно прост, учитывая, что я просто запускаю контейнер с открытым портом, поэтому URL-адрес, который Sailes.io использует для подключения, — localhost:PORT. Здесь все хорошо.
Проблема возникает, когда служба A запускается в архитектуре µService. Каждая служба работает в своем собственном URL-адресе, например backend.com/api/SERVICE_NAME, действующем как пространство имен, при этом каждый маршрут в пространстве имен фактически попадает в службу SERVICE_NAME. Итак, теперь у Sais.io есть проблемы с подключением к сервису A, я полагаю, из-за изменения маршрута.
Это все варианты, которые я пробовал, учитывая const io = sailsIOClient(socketIOClient);
io.sails.url = 'http://backend.com/api/SERVICE_NAME';
тогда
io.sails.url = 'http://backend.com';
io.sails.path = '/api/SERVICE_NAME'
тогда
io.sails.url = 'http://backend.com';
io.sails.path = '/api/SERVICE_NAME/socket.io/'
Затем я наткнулся на this, который ссылается на аргумент path функции подключения socket.io (вот конкретика). Я попытался сделать это, установив для io.sails.autoConnect значение false и вызвав io.sails.connect(), но я не могу подключиться к приложению Sails.
Socket is trying to reconnect to Sails...
_-|>_- (attempt #293)
Я совершенно уверен, что проблема в том, что клиентский io не может найти правильный маршрут для поиска приложения Sails из-за настройки архитектуры.
Кто-то имел дело с подобным сценарием? Предложения приветствуются.
