我看不出实现大使模式将如何帮助我们简化/模块化容器体系结构的设计。
假设我在主机a上有一个数据库容器db，由位于主机B上的程序db-client使用，该程序通过大使容器db-ambassador和db-foreign-ambassador通过网络连接：
[host A (db) --> (db-ambassador)] <- ... -> [host B (db-forgn-ambsdr) --> (db-client)]
同一机器中的容器（例如db到db-ambassador和db-foreign-ambassador到db-client）之间的连接是通过Docker的--link参数完成的，而db-ambassador和db-foreign-ambassador通过网络进行通信。
但是，--link只是一种将ip地址、端口和其他信息从一个容器插入到另一个容器的奇特方式。当一个容器发生故障时，链接到它的另一个容器不会得到通知，也不会在重新启动时知道崩溃容器的新IP地址。简而言之，如果链接到另一个容器的容器失效，则该链接也失效。
考虑我的例子，假设db崩溃并重新启动，因此被分配到不同的IP。db-ambassador也必须重新启动，以便更新它们之间的链接。。。但你不应该。如果db-ambassador重新启动，IP也会发生变化，foreign-db-ambassador将不知道在新的IP地址上可以到达哪里。
引用Docker文档中关于大使模式的一篇文章，
当你需要重新连接你的消费者以与不同的Redis通话时服务器，您只需重新启动消费者已连接到。
此模式还允许您透明地将Redis服务器移动到与消费者不同的docker主机。
这似乎正是它试图解决的问题。就我的理解而言，它完全没有。如果您认为--link只有在链接容器不崩溃的情况下才有用，则不会。如果支持的话，在其以前的IP上启动崩溃节点的选项将是一个很好的解决方案，至少对于中小型架构来说是这样。
我是不是错过了一些显而易见的东西？
Jérôme在他的幻灯片组"使用Docker将应用程序运送到集装箱中的生产"中有一些很好的幻灯片（11-33），介绍大使如何比其他服务发现方式（即DNS、密钥值存储、绑定装载配置文件等）更好。他还对如何解决我想你提到的问题提出了一些建议，尤其是Docker Grand Ambassador看起来很有希望。