наборы с состоянием

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

Самый простой:

Q) Если A отправляет сообщение B, как B определяет местоположение A для отправки ответа.A) A должен указать B, куда его отправлять (обмен на AMQP, URL на http)

Сложнее:

Q) Как процесс мониторинга отправляет сообщение A (где что-то еще вызвало это желание - например, B говорит, что A отправил мне неверный запрос)

Q) Как процесс мониторинга убивает или перезапускает A.

Это может быть что-то вроде убить хост + pid или pod или pod + container

(см. напримерkubernetes перезапустить контейнер в капсуле)

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

Теперь вы можете назначить UUID самостоятельно, но вам нужна таблица для его отображения. Это может иметь несколько столбцов, но иногда один URI (или URI-подобная вещь) полезен, например, как адрес «возник из / ответить на».

Еще один способ просмотра этого вопроса. В старые времена было легко определить процесс.

Имя хоста (или IP-адрес) + PID было достаточно

Затем пришла виртуализация: IP-адрес идентифицирует виртуальный сетевой порт, назначенный виртуальной машине, а PID идентифицирует процесс внутри нее. Имя хоста и IP-адрес все еще достаточно. Иногда вам также нужен vhost (хотя мне никогда не было понятно, почему)

Теперь добавление контейнеров в смесь не обязательно имеет собственный IP-адрес.host + pid может идентифицировать контейнер Но вы можете не знать хост, если вы используете kubernetes или Docker Swarm.

Теперь мы больше не говорим о процессах больше, чем об услугах. Раньше этого было достаточно, чтобы идентифицировать сервис, используя имя хоста (или IP-адрес) и порт (YMMV -Могут ли IP-адрес и номер порта вместе однозначно идентифицировать идентификатор процесса?).

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

Услуга может быть предоставлена ​​контейнером или пакетом, содержащим несколько контейнеров, и в этом случае вы можете обратиться к контейнеру или контейнеру. Смотри напримерkubernetes перезапустить контейнер в капсуле Похоже, что имена контейнеров уникальны для каждого экземпляра докера, но не более того.

Так что есть несколько разных способов адресации сообщения. Есть ли хороший стандартный способ сделать это?

На мой взгляд, очевидная вещь для использования - это URI (но я могу ошибаться). Есть ли рекомендуемые формы URI для обработкивсе возможные случаи? (очевидно, у нас естьprocotocl: //хозяин:порт/ для легких случаев)

Ответы на вопрос(1)

Ваш ответ на вопрос