最近随着 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 来实现， 节省了很多时间， 而且这也是主流。
