服务发现【浅谈当下】

前言

随着微服务和基于云的应用程序越来越多，诸如服务发现、服务路由等词汇也火热了起来。本篇文章接下来就基于服务发现做一个概述，后续文章将会以具体实例（Spring Cloud + Eureka的服务发现模式）描述服务发现的具体实现过程。

什么是服务发现

在任何分布式架构中，都需要找到机器所在的物理地址，这个过程我们就可以叫服务发现。每当应用程序叼用分布在多个服务器上的资源，这个应用程序就需要定位这些资源的物理位置。这是啥意思呢？比如说我（客户端）要去乌镇旅游，我早就听说乌镇有很多很美的地方我都要去（客户端请求），但是我不清楚那些地方都具体在乌镇的哪个方位，于是我问住在桐乡的小豪（服务代理），小豪于是就拿了一张乌镇的地图给我，上面有我想去地方的具体方位（IP和端口），然后我就根据这些具体方位找到了每一个目的地（服务）。

我的服务在哪里

我们已经知道服务发现无非就是要进行服务位置的解析，那么实现的方式肯定不止一种，针对不同的环境我们当然可以选择不同的方式。接下来就给大家介绍目前两种环境下的普遍服务发现方式：

非云环境下的服务发现

在非云的环境中，我们实现服务发现的方式通常是由DNS（Domain Name Serveice）和网络负载均衡器的组合来解决的。其工作原理如下图所示：

① 客户端通过使用通用的DNS名称以及唯一的服务路径来调用目标服务，DNS名称会被解析到一个负载均衡器。
②负载均衡器在接收到来自客户端的请求时，会根据服务消费者尝试访问的路径，在路由表中定位服务物理地址条目。
③路由表条目包含了托管了目标服务的一个或多个服务器列表，然后负载均衡器会选择列表中的一个服务器，将请求转发到该服务器上。
PING：辅助负载均衡器平时会处于空闲状态，主要负责ping主负载均衡器以查看它是否处于存活状态。如果主负载均衡器出现了状况，未处于存活状态，那么辅助负载均衡器将变为存活状态，接管主负载均衡器的IP地址并开始提供请求。实现高可用性。
这种模型适用于在启业数据中心内部运行的应用程序，以及服务较少的情况，但对基于云的微服务应用程序来说，就显得捉襟见肘了。那么在需要处理大量事务和冗余的云环境中，我们该如何为其实现一个合适且健壮的服务发现机制呢？

基于云的微服务环境下的服务发现

在目前的大环境下，基于云的微服务环境的解决方案是使用服务发现机制。至于为什么，接下来我本文将继续介绍服务发现架构，然后根据它的特点来总结它之所以成为云的微服务环境趋势的原因：

服务发现架构

开始讨论服务发现架构之前，有4个概念我们是必须要了解的，这些概念在所有服务发现实现中是共通的：
1.服务注册——服务如何使用服务发现代理进行注册？
2.服务地址的客户端查找——服务客户端查找服务信息的方法是什么?
3.信息共享——如何跨节点共享服务信息？
4.健康监测——服务如何将它的健康信息传回给服务发现代理？
下图展示了这四个概念的流程，以及在服务发现模式中通常会发生的情况。
当服务实例启动的时候，服务A中的服务实例将通过一个或多个服务发现实例（也就是服务发现层的服务发现节点）来注册它们可以访问的物理位置路径和端口。每个服务实例都具有唯一的IP和端口，但是每个服务实例都将以相同的服务ID进行注册。服务ID是唯一标识一组相同服务实例的键。
服务通常只在一个服务发现实例中进行注册。但每个服务实例的数据都被会被传递到服务发现集群中的所有其他节点。每个服务实例将通过服务发现服务去推送服务实例的状态，或者服务发现服务从服务实例去拉取状态。如果检查到服务处于非健康状态将从可用的服务实例池中删除（上图标×）。
服务在向服务发现服务进行注册之后，这个服务就可以被需要使用这项服务功能的应用程序或者其它服务使用。客户端每次调用服务，就只依赖于服务发现引擎来解析服务位置。

客户端负载均衡

正如上面所说的这种服务发现方式，客户端完全依赖于服务发现引擎来查找和调用服务，每次调用注册的微服务实例时，服务发现引擎就会被调用。这种方法就显得较为脆弱了，所以有了接下来要介绍的客户端负载均衡模式来实现服务发现过程。模式如下图：
在这个模型中，当服务消费者需要调用一个服务时：
1.它将联系服务发现服务，获取它请求的所有服务实例，然后在服务消费者的机器上本地缓存数据。
2.每当客户端需要调用该服务时，服务消费者将从缓存中查找该服务的位置信息。
3.然后，客户端将顶起与服务发现服务进行联系，并刷新服务实例的缓存。客户端缓存最终是一致的，但这样始终会存在这样的风险：在客户端联系服务发现实例以进行刷新和调用时，调用可能会被定向到不健康的服务实例上。
如果在调用服务的过程中，服务调用失败，那么本地的服务发现缓存失效，服务发现客户端将尝试从服务发现代理刷新数据。

总结

上面我们介绍了在非云环境下的服务发现方式（DNS+网络负载均衡器），以及基于云的微服务环境下的服务发现机制（服务发现架构，客户端负载均衡），通过了解我们可以总结出在基于云的微服务环境下使用服务发现机制有以下特点：
1.高可用——服务发现支持集群环境，在服务发现集群中可以跨多个节点共享服务查找。如果一个节点变得不可用，集群中的其他节点应该能够接管工作。
2.点对点——服务发现集群中的每个节点共享服务实例状态。
3.负载均衡——服务发现需要在所有服务实例之间动态的请求进行负载均衡，以确保服务调用分布在由它管理的所有服务实例上。
4.有弹性——服务发现的客户端在本地“缓存”服务信息。这样，如果服务发现服务变得不可用，应用程序仍然可以基于本地缓存中维护的信息来运行和定位服务。
5.容错——服务发现需要检测出服务实例什么时候时不健康的，并从可以接收客户端请求的可用服务列表中移除该实例。服务发现应该在没有人为干预的情况下，对这些故障进行检测，并采取行动。
在下篇文章中，将详细介绍Spring Cloud + Eureka的服务发现模式，敬请期待！