地址硬编码问题——电影微服务中将用户微服务的地址写死，如果用户微服务地址发生变化，难道要重新上线电影微服务吗？

本节来解决该问题。

不妨先思考一下，怎样才能让服务消费者总能找到服务提供者呢？或者说，怎样才能让服务消费者感知到服务提供者地址的变化呢？

TIPS

目前市面上把服务消费者找到服务提供者的这种机制称为服务发现，又或者服务注册。下面来探索服务发现究竟是怎么回事。

服务发现原理初探

其实，服务发现机制非常简单，不妨用大家熟悉的MySQL来类比——只需一张表（图中的registry表）即可实现服务发现！

如图，如果我们能在：

• 应用启动时，自动往registry表中插入一条数据，数据包括服务名称、IP、端口等信息。
• 应用停止时，自动把自己在registry表中的数据的status设为 DOWN 。
  
  

这样，服务消费者不就永远都能找到服务提供者了嘛！当服务消费者想调用服务提供者接口时，只需向数据库发送SQL语句 SELECT*FROM registrywhereservice_name='user'andstatus='UP' 即可找到服务提供者的所有实例！IP、端口啥的都有了，自己拼接一下，再去调用就行了！

TIPS

看，服务发现机制是不是很简单？程序猿给图中的”MySQL“的组件起了一个牛叉的名字叫：”注册中心“，也有的书将其称为”服务发现组件“。

但，这毕竟只是一个最简陋的服务发现原理。完整的服务发现要考虑的问题有很多，例如：

• 当服务抑或所在主机突然崩溃或者进入某种不正常的情况无法提供服务（例如应用的数据库挂了）时，对应的数据理应标记DOWN，或者索性删除；
• 如果每次调用之前，都得向服务发现组件发送类似 SELECT*FROM registrywhereservice_name='user'andstatus='UP' 的语句，那么服务发现组件的压力得有多大？更重要的，这与当下流行的去中心化设计的思想相悖；
• 服务发现组件即使挂掉，也不应该影响微服务之间的调用。
  
  

那么，一个完善的服务发现组件应该具备哪些能力呢？

服务发现原理深入

不妨来看一下使用服务发现组件后的架构图，如图所示。

服务提供者、服务消费者、服务发现组件这三者之间的关系大致如下：

• 各个微服务在启动时，将自己的网络地址等信息注册到服务发现组件中，服务发现组件会存储这些信息；
• 服务消费者可从服务发现组件查询服务提供者的网络地址，并使用该地址调用服务提供者的接口；
• 各个微服务与服务发现组件使用一定机制（例如心跳）通信。服务发现组件如长时间无法与某微服务实例通信，就会自动注销（即：删除）该实例；
• 当微服务网络地址发生变更（例如实例增减或者IP端口发生变化等）时，会重新注册到服务发现组件；
• 客户端缓存：各个微服务将需要调用服务的地址缓存在本地，并使用一定机制更新（例如定时任务更新、事件推送更新等）。这样既能降低服务发现组件的压力，同时，即使服务发现组件出问题，也不会影响到服务之间的调用。
  
  

综上，服务发现组件应具备以下功能。

• 服务注册表：服务注册表是服务发现组件的核心（其实就是类似于上面的registry表），它用来记录各个微服务的信息，例如微服务的名称、IP、端口等。服务注册表提供查询API和管理API，查询API用于查询可用的微服务实例，管理API用于服务的注册和注销；
• 服务注册与服务发现：服务注册是指微服务在启动时，将自己的信息注册到服务发现组件上的过程。服务发现是指查询可用微服务列表及其网络地址的机制；
• 服务检查：服务发现组件使用一定机制定时检测已注册的服务，如发现某实例长时间无法访问，就会从服务注册表中移除该实例。
  
  

综上，使用服务发现的好处是显而易见的。Spring Cloud为我们提供多种服务发现组件的支持，例如Eureka、Consul（spring-cloud-consul）、Zookeeper（spring-cloud-zookeeper）、Aliaba Nacos（孵化中：spring-cloud-alibaba）、Etcd（孵化中：spring-cloud-etcd）等。

地址硬编码问题——电影微服务中将用户微服务的地址写死，如果用户微服务地址发生变化，难道要重新上线电影微服务吗？

本节来解决该问题。

不妨先思考一下，怎样才能让服务消费者总能找到服务提供者呢？或者说，怎样才能让服务消费者感知到服务提供者地址的变化呢？

TIPS

目前市面上把服务消费者找到服务提供者的这种机制称为服务发现，又或者服务注册。下面来探索服务发现究竟是怎么回事。

服务发现原理初探

其实，服务发现机制非常简单，不妨用大家熟悉的MySQL来类比——只需一张表（图中的registry表）即可实现服务发现！

如图，如果我们能在：

• 应用启动时，自动往registry表中插入一条数据，数据包括服务名称、IP、端口等信息。
• 应用停止时，自动把自己在registry表中的数据的status设为 DOWN 。
  
  

这样，服务消费者不就永远都能找到服务提供者了嘛！当服务消费者想调用服务提供者接口时，只需向数据库发送SQL语句 SELECT*FROM registrywhereservice_name='user'andstatus='UP' 即可找到服务提供者的所有实例！IP、端口啥的都有了，自己拼接一下，再去调用就行了！

TIPS

看，服务发现机制是不是很简单？程序猿给图中的”MySQL“的组件起了一个牛叉的名字叫：”注册中心“，也有的书将其称为”服务发现组件“。

但，这毕竟只是一个最简陋的服务发现原理。完整的服务发现要考虑的问题有很多，例如：

• 当服务抑或所在主机突然崩溃或者进入某种不正常的情况无法提供服务（例如应用的数据库挂了）时，对应的数据理应标记DOWN，或者索性删除；
• 如果每次调用之前，都得向服务发现组件发送类似 SELECT*FROM registrywhereservice_name='user'andstatus='UP' 的语句，那么服务发现组件的压力得有多大？更重要的，这与当下流行的去中心化设计的思想相悖；
• 服务发现组件即使挂掉，也不应该影响微服务之间的调用。
  
  

那么，一个完善的服务发现组件应该具备哪些能力呢？

服务发现原理深入

不妨来看一下使用服务发现组件后的架构图，如图所示。

服务提供者、服务消费者、服务发现组件这三者之间的关系大致如下：

• 各个微服务在启动时，将自己的网络地址等信息注册到服务发现组件中，服务发现组件会存储这些信息；
• 服务消费者可从服务发现组件查询服务提供者的网络地址，并使用该地址调用服务提供者的接口；
• 各个微服务与服务发现组件使用一定机制（例如心跳）通信。服务发现组件如长时间无法与某微服务实例通信，就会自动注销（即：删除）该实例；
• 当微服务网络地址发生变更（例如实例增减或者IP端口发生变化等）时，会重新注册到服务发现组件；
• 客户端缓存：各个微服务将需要调用服务的地址缓存在本地，并使用一定机制更新（例如定时任务更新、事件推送更新等）。这样既能降低服务发现组件的压力，同时，即使服务发现组件出问题，也不会影响到服务之间的调用。
  
  

综上，服务发现组件应具备以下功能。

• 服务注册表：服务注册表是服务发现组件的核心（其实就是类似于上面的registry表），它用来记录各个微服务的信息，例如微服务的名称、IP、端口等。服务注册表提供查询API和管理API，查询API用于查询可用的微服务实例，管理API用于服务的注册和注销；
• 服务注册与服务发现：服务注册是指微服务在启动时，将自己的信息注册到服务发现组件上的过程。服务发现是指查询可用微服务列表及其网络地址的机制；
• 服务检查：服务发现组件使用一定机制定时检测已注册的服务，如发现某实例长时间无法访问，就会从服务注册表中移除该实例。
  
  

综上，使用服务发现的好处是显而易见的。Spring Cloud为我们提供多种服务发现组件的支持，例如Eureka、Consul（spring-cloud-consul）、Zookeeper（spring-cloud-zookeeper）、Aliaba Nacos（孵化中：spring-cloud-alibaba）、Etcd（孵化中：spring-cloud-etcd）等。