服务发现

最近又重新补充学习了一下服务发现的相关的理论，以帮助下周给同学们培训微服务带来点灵感

微服务定义

简单来说，微服务就是用一组小服务的方式来构建一个应用，服务独立运行在不同的进程中，
服务之间通过轻量的通讯机制（如 RESTful 接口、RPC接口）来交互，并且服务可以通过自动化部署方式独立部署。

微服务架构其实也就意味着更多的独立服务，并且这些服务之间需要频繁交互和通信

服务发现的必要性

在微服务架构中，微服务实例的网络位置发生变化是一种常态，
所以必须提供一种机制，使得服务消费者在服务提供者的网络位置发生变化时，
能够及时获得最新的位置信息，一般是提供一个网络位置稳定的服务注册中心，服务提供者的网络位置被注册到注册中心，
并在网络位置发生变化的时候及时更新，而服务消费者定期向注册中心获取服务提供者的最新位置信息，这就是最基本的服务发现机制。

较为复杂的服务发现实现除了服务提供者的位置信息外，
还可以向服务消费者提供服务提供者的描述信息、状态信息和资源使用信息，以供服务消费者实现更为复杂的服务选择逻辑。

客户端发现

• 服务提供者的实例在启动时或者位置信息发生变化时会向服务注册表注册自身，
  在停止时会向服务注册表注销自身，如果服务提供者的实例发生故障，在一段时间内不发送心跳之后，也会被服务注册表注销。

• 服务消费者的实例会向服务注册表查询服务提供者的位置信息，然后通过这些位置信息直接向服务提供者发起请求。

服务端发现

• 第一步与客户端发现相同：服务提供者的实例在启动时或者位置信息发生变化时会向服务注册表注册自身，
  在停止时会向服务注册表注销自身，如果服务提供者的实例发生故障，在一段时间内不发送心跳之后，也会被服务注册表注销。

• 服务消费者不直接向服务注册表查询，也不直接向服务提供者发起请求，
  而是将对服务提供者的请求发往一个中央路由器或者负载均衡器，
  中央路由器或者负载均衡器查询服务注册表获取服务提供者的位置信息，并将请求转发给服务提供者。

利弊对比

• 客户端发现模式的优势：
  服务消费者向服务提供者发起请求时比服务端发现模式少了一次网络跳转，劣势是服务消费者需要内置特定的服务发现客户端和服务发现逻辑；

• 服务端发现模式的优势：
  服务消费者无需内置特定的服务发现客户端和服务发现逻辑，劣势是多了一次网络跳转，并且需要基础设施环境提供中央路由机制或者负载均衡机制；

目前客户端发现模式应用的多一些，因为这种模式的对基础设施环境没有特殊的要求，和基础设施环境也没有过多的耦合性。

市面解决方案对比

• DNS 算是最为原始的服务发现系统：
  在服务变更较为频繁，即服务的动态性很强的时候，
  DNS 记录的传播速度可能会跟不上服务的变更速度，这将导致在一定的时间窗口内无法提供正确的服务位置信息，
  所以这种方案只适合在比较静态的环境中使用，不适用于微服务。

• 基于 ZooKeeper、Etcd 等分布式键值对存储服务来建立服务发现系统：
  只能提供基本的数据存储功能，需要在外围做大量的开发才能形成完整的服务发现方案。
  都是强一致性系统，在集群发生分区时会优先保证一致性、放弃可用性。

• Eureka 是个专门为服务发现从零开始开发的项目，Eureka 以可用性为先，可以在多种故障期间保持服务发现和服务注册功能可用，
  Eureka 的设计原则是“存在少量的错误数据，总比完全不可用要好”，
  会存在一些数据错误，在故障恢复之后按最终一致性进行状态合并，清理掉错误数据。
  服务端和客户端都是 Java 编写的，针对微服务场景，
  并且和 Netflix 的其他开源项目以及 Spring Cloud 都有着非常好的整合，具备良好的生态。

• Consul 是 HashiCorp 公司的商业产品，它有一个开源的基础版本，
  这个版本在基本的服务发现功能之外，还提供了多数据中心部署能力，包括内存、存储使用情况在内的细粒度服务状态检测能力，
  和用于服务配置的键值对存储能力（这是一把双刃剑，使用它可以带来便捷，但是也意味着和 Consul 的较强耦合性），
  Go语言编写，Consul 的商业版本功能更为强大。

• SkyDNS，这是一个结合古老的 DNS 技术和时髦的 Go 语言、Raft 算法的项目，
  提供了HTTP和DNS两种客户端API，依赖于etcd作为数据存储
  在 Kubernetes 里使用，有一层较为稳定的 Service 抽象，
  采用描服务端服务发现方式，唯一的一款服务端发现方式。