微服务当中的服务发现是什么？--《Spring微服务实战》系列 04

当我们有了很多的微服务之后，并不是就大功告吉了，因为更关键的还在后面。大家可以想几个问题，假设有好几个微服务，那么该把它们放到哪里统一管理呢？如果客户端想要使用其中的某个微服务，该去哪里找呢？如果新增了一个微服务该怎么让客户端知道呢？如果其中某个微服务出问题了，客户端该如何知晓呢？

以上问题的答案就是：服务发现机制。这是一个什么技术呢？先别急，我们先来一起看看它有哪些特点：

高可用——服务发现需要能够支持“热”集群环境，在服务发现集群中可以跨多个节点共享服务查找。如果一个节点变得不可用，集群中的其它节点应该能够接管工作。
点对点——服务发现集群中的每个节点共享服务实例的状态。
负载均衡——服务发现需要在所有服务实例之间动态地对请求进行负载均衡，以确保服务调用分步在由它管理的所有服务实例上。
有弹性——服务发现的客户端应该在本地“缓存”服务信息。本地缓存允许服务发现功能逐步降级，这样，如果服务发现服务变得不可用，应用程序仍然可以基于本地缓存中维护的信息来运行和定位服务。
容错——服务发现需要检测出服务实例什么时候是不健康的，并从可以接收客户端请求的可用服务列表中移除该实例。

因此，拥有以上特点的服务发现机制可以很好的解决文章开头的问题，那么这个机制的架构又是什么样呢？我们需要了解四个概念：

服务注册——服务如何使用服务发现进行注册？
服务地址的客户端查找——服务客户端查找服务信息的方法是什么？
信息共享——如何跨节点共享服务信息？
健康监测——服务如何将它的健康信息传回给服务发现代理？

下图可以很好的解释上面架构的逻辑，大家可以参考：

那么在Spring全家桶中，又有哪个技术是用来解决这个服务发现机制的呢？答案就是：Spring Eureka, 除此以外还有强大的 Ribbon来实现客户端负载均衡。

以前经常使用的都是服务端负载均衡策略，也就是当用户请求发过来之后，由服务端决定访问哪个服务器，而客户端负载均衡则是从客户端发起请求的时候，就已经做了负载均衡策略，Ribbon正是背后的神助攻。

简单的介绍一下Eureka的功能，它就相当于是一个注册中心，一个池子，所有的微服务都可以来这里注册，登记上自己的信息，那么其它的客户端想要使用其中某个微服务的时候，就来到这个注册中心里，看看这个池子里有什么微服务可以使用，这个池子负责所有微服务的增加修改和删除，统一调度和支配。

接下来，要做的就是构建Spring Eureka服务了，同样的新建一个Spring Boot项目，创建启动类，加上@EnableEurekaServer注解，表明这是一个Eureka服务器，其它的服务都可以过来注册。唯一不同的是需要在Pom.xml文件中加上Eureka库，标签为spring-cloud-starter-eureka-server，另外要在yml文件中加上端口以及和Eureka相关的信息。

通常情况下，创建一个Eureka注册中心是不够的，万一这个注册中心出问题的怎么办？所以，一般都会创建一个Eureka集群，以达到高可用的目的，这样就是其中一个挂掉了，那么其它的照常可以使用，不影响用户的使用体验。

那么注册中心建好了，接下来就可以创建微服务并把它们注册到这个池子里了，同样创建一个SpringBoot项目，这个时候需要在启动类里添加上@LoadBalanced注解，告诉Spring Cloud创建一个支持Ribbon的RestTemplate类，这样这个服务就可以使用带有Ribbon功能的Spring RestTemplate调用服务了。

其实，在读完这一章节后，自己感觉还是云里雾里的，因为之前在B站上面看过一些大神分享的微服务的视频，其中讲到的Eureka就非常的详细和全面，我把链接贴在这里，感兴趣的朋友可以看看：
https://www.bilibili.com/video/av22613028

以上就是今天的分享，我们知道了什么是服务发现机制，以及为什需要服务发现和如何创建服务发现的大致步骤。希望今天的文章能对你有所帮助，我们下期再会。