使用micro创建微服务（四） -- 基于etcd实现服务发现中心

概述

go-micro的目标是简化非服务的开发工作，及分布式系统的建立过程。所以它把一些开发和系统建设过程中的一些常见的工作抽象成了接口，以便开发人员可以不必关心底层的实现细节，只关心具体的业务逻辑开发即可。这样就减少了学习和开发的成本，可以更快速的创建一个灵活、健壮的系统。

服务发现中心实现途径

微服务的服务发现中心有三种实现途径：

1. 使用现有的DNS基础设施，这种方式的优势是每个组织都已经部署了DNS。基于DNS的服务发现系统包括Mesos-DNS；
2. 使用现有的key/value数据存储，如：Apache Zookeeper、Consul或etcd。这些是非常成熟的分布式系统。虽然这些系统的设计初衷远远不止只是一个服务发现中心，但它们健壮、简单的接口使它们可以非常好的应用于服务发现领域；
3. 采用特定的服务发现策略，如Netflix Eureka。这种方式可以使服务发现中心针对服务发现的特定目标进行优化。如Eureka就把可用性置于一致性之上。使用这种解决方案带来的不利就是开发者为了使用这种解决方案带来的所有好处，就要开发基于各种语言的客户端，这样就会总成额外的开发和学习成本；

服务发现客户端

因为服务发现中心是一个中心化的机制，所以每个开发的微服务都需要一个客户端用于与服务发现中心的通信。

服务发现客户端的核心任务是：服务注册及服务解析。当服务启动时，服务发现中心使用服务注册信息来通知其他服务此服务已经可用。当服务可用时，其他的服务使用服务解析进行服务的寻址。

服务注册

除了在服务启动、关闭时对服务进行注册和注销外，客户端还要初始化一个心跳系统。心跳就是一个周期性发送给其他服务，证明自身还在正常运行的消息。心跳信息应该是异步发送，以免影响服务的性能。服务注册还要负责设置服务的元数据，如服务名称、服务版本等。

服务解析

获取服务的物理网络地址的过程就是服务解析。一个服务解析的过程，包括了几个核心的功能：缓存、容错和负载均衡。

为了防止在每次进行服务解析时的网络开销，对服务的地址进行缓存是一个必不可少的能力；缓存主要是在服务注册中心发生变化时，进行刷新，以保证和服务中心的信息保持一致。

服务解析客户端还需要实现容错和负载均衡算法。一个服务基于可用性和性能的要求，会部署多个服务实例。服务解析客户端必须要在综合考虑负载、可用性和其他因素的基础上，确认应该返回哪个服务实例的地址。例如服务解析客户端会使用round robin算法在一个特定的服务的多个服务实例中进行轮询。

micro中的服务发现

服务发现是一个分布式系统必须要解决的问题，go-micro把这个问题抽象为接口，github.com/micro/go-micro/v2/registry/Registry：

type Registry interface {
   
	Init