在mesos环境中执行发现服务有十几种解决方案。
根据客户如何找到服务，我们可以将他们分为3组：
基于代理的
当客户端和服务之间存在代理时，例如haproxy（marathon lb基于它）、fabio、traefik、nixy），它负责基于http路径、报头、域e.t.c.的服务负载平衡。此解决方案易于开发，并提供了根据请求调整负载平衡的机会。另一方面，我们添加额外的跃点，作为代理，我们有mitm的情况。

dnslike（向特定的已知端点询问服务的位置）
软件定义的网络-我们可以将每个容器的ip与sdn一起使用，这样每个容器都会暴露出唯一的ip，并使用默认端口80表示http，443表示https，等等。这是最先进和相对较新的技术，尽管它使用普通的旧dns来查找服务ip。引入代理可能会更难，但可以处理任何类型的流量。
服务记录-每个容器在全局dns中注册，客户端使用dns srv查询获取其ip和端口。consul mesos dns提供这种类型的dns服务器。其他一些协议也是基于这个想法（看看bonjure）。它试图充分利用sdn和proxy。它相对容易设置，而且不受协议限制。

其他
任何不适合其他类型的产品，例如内部开发的解决方案、etcd或eureka。它可能与提供一些优化的基础设施和应用程序紧密相连。值得一提的是，有人尝试使用基于dht的发现服务—元服务发现
您可以在此处找到有关可用于创建发现服务的工具的更多详细信息
我们可以按照使用服务条目填充发现服务的方式来划分发现服务：
联营
mesos/marathon定期查询状态。这就是mesos dns的工作原理。这是最简单的方法，但会在服务启动/停止和更改进入服务发现之间造成巨大的延迟。这可以通过使用healthchecking最小化。
基于事件
marathon有能力用状态变化的信息推送事件（也有包含事件总线int mesos-design doc的倡议）。这就是马拉松的工作方式。类似的工作由marathon consul完成，但数据会传递给consul。
应用程序/容器内
上面的解决方案是异步的，因此当您的服务发现状态过时时，可能会有一个时间跨度，例如服务已启动但尚未准备好为请求提供服务，或者服务刚刚终止。即使使用healtcheck，我们也不能假设所有事情都是在0停机时间内发生的。最小化停机时间的解决方案是让应用程序在准备好为请求提供服务时注册自己，并在停止前取消注册（也称为正常关机）。

例如，可以使用marathonlb，它将抽象出 ip:port 查找。此外，您还可以使用mesos dns将服务名称解析为 ip:port Map。