这是一个普遍的问题，但是出于论证的缘故，您可以并假设我们有一个通过AMQP和HTTP组合进行通信的进程集合。有两种情况需要考虑。

简单的一个：

• 问）如果A向B发送消息，B如何识别A的位置以发送答复。
• A）A必须告诉B以某种方式将其发送到哪里（交换AMQP，URL URL）

较难的：

• 问）监视过程如何向A发送消息（其他原因促使了这种愿望-例如B说A向我发送了错误的请求）
• 问）监视过程如何终止或重新启动A。

这可能像杀死主机+ pid或pod或pod + container

您可能希望重新启动整个服务或提供该服务的过程的某些子集。

现在，您可以自己分配一个UUID，但是需要一个表来映射它。它可能有多个列，但有时单个URI（或类似URI的东西）很有用，例如，作为“起源于/回复到”地址。

查看此问题的另一种方法。在过去，很容易确定一个过程。

主机名（或IP地址）+ PID

然后进行虚拟化，IP地址标识分配给VM的虚拟网络端口，而PID标识其中的进程。主机名和IP地址仍然足够。有时您也需要虚拟主机（尽管我从来不知道为什么）

现在，将容器添加到混合物中，容器不一定具有自己的IP地址。一个主机+PID可识别的容器
，但你可能不知道的主机，如果你正在运行kubernetes或码头群。

现在，我们不再谈论流程，而是谈论服务。过去足以使用主机名（或IP地址）和端口来标识服务（YMMV-
IP地址和端口号可以一起唯一地标识进程ID吗？。

现在，我们有了负载平衡器和其他技巧（例如，缓存代理），可以将消息重定向到实际提供服务的其他内容。

包含多个容器的容器或容器可能会提供服务，在这种情况下，您可能需要处理容器或容器。例如查看kubernetes在pod中重新启动容器看起来每个docker实例的容器名称都是唯一的，但除此之外没有。

因此，您可能想通过几种不同的方式来处理消息。有一个好的标准方法吗？

在我看来，要使用的显而易见的东西是URI（但是我可能错了）。是否有推荐的URI形式来处理 所有 可能的情况？（显然，对于简单的情况，我们有
procotocl ：// host ： port /）