我没有看到实施大使模式将如何帮助我们简化/模块化容器架构的设计。
假设我在主机A上有一个数据库容器db，并由位于主机B上的程序db-client使用，它们通过大使容器db-ambassador和{{连接1}}通过网络：
db-foreign-ambassador同一台机器中的容器之间的连接，例如[host A (db) --> (db-ambassador)] <- ... -> [host B (db-forgn-ambsdr) --> (db-client)]
到db，db-ambassador到db-foreign-ambassador通过Docker的db-client参数完成，--link和db-ambassador通过网络进行通话
但是，db-foreign-ambassador只是将IP地址，端口和其他信息从一个容器插入另一个容器的奇特方式。当容器发生故障时，与其链接的另一个容器不会得到通知，也不会在重新启动时知道崩溃容器的新IP地址。简而言之，如果与另一个连接的容器死了，那么这个链接也已经死了。
考虑我的例子，假设--link崩溃并重新启动，因此被分配到不同的IP。 db也必须重新启动，以便更新它们之间的链接......除非你不应该。如果db-ambassador重新启动，则IP也会发生变化，db-ambassador将无法知道在新IP地址的位置。
在Docker关于大使模式的文档中引用an article，
似乎这正是它试图解决的问题。就我的理解而言，它完全没有。如果您认为当您需要重新连接消费者与其他Redis交谈时 服务器，你可以重新启动redis-ambassador容器了 消费者与之相连。
此模式还允许您透明地将Redis服务器移动到 来自消费者的不同码头主机。
foreign-db-ambassador仅在链接容器不崩溃时才有用，则不会这样做。在其先前的IP上启动崩溃节点的选项将是一个很好的解决方法if supported，至少对于中小型架构而言。
我错过了一些明显的东西吗？
答案 0 :(得分：6)
Jérôme在他的slide deck on "Shipping Applications to Production in Containers with Docker"中有一些关于大使如何比其他服务发现方式（即DNS，键值存储，绑定装置配置文件等）更好的幻灯片（11-33）。他还就如何解决我认为你提到的问题提出了一些建议，特别是Docker Grand Ambassador看起来很有希望。