最近随着 DC/OS 和 k8s 的流行，很多基础服务都不需要我们开发管理了 （例如服务发现），这样大家可以把更多精力放在业务上。下面我们列举一下常用的服务发现方案

• k8s 自带的 Kube-DNS

  Kube-DNS 可以用 CoreDNS 替代

• mesos-DNS

  Service iscovery through DNS, however, has some limitations that include:

  • DNS does not identify service ports, unless you use an SRV query; most apps are not able to use SRV records “out of the box.”
  • DNS does not have fast failover.
  • DNS records have a TTL (time to live) and Mesos-DNS uses polling to create the DNS records; this can result in stale records.
  • DNS records do not provide any service health data.
  • Some applications and libraries do not correctly handle multiple A records; in some cases the query might be cached and not correctly reloaded as required.

• marathon-lb

  To address mesos-dns's known problem, mesosphere provide a tool for Marathon called Marathon Load Balancer, or marathon-lb. 可以参考 https://mesosphere.com/blog/dcos-marathon-lb/ 和 https://mesosphere.com/blog/service-discovery-and-load-balancing-with-dcos-and-marathon-lb-part-2/。

• 基于 nginx-proxy 实现的服务发现

  https://github.com/jwilder/nginx-proxy， 这个方案和 marathon-lb 的想法非常类似。

• 基于zk/consul/etcd 开发的服务发现

  这种方式需要开发人员自己实现服务发现的功能，目前大多数公司使用 consul 作为服务发现的比较多，以为它使用简单，功能齐全。

现在开发一套系统不需要自己写服务发现的代码了， 可以直接使用 k8s or mesos/marathon 和 marathon-lb 来实现， 节省了很多时间， 而且这也是主流。