SpringCloud-服务注册/服务发现-Eureca

一.背景

1.1问题

上一篇文章中，在远程调用时，我们的URL是写死的

String url="http://127.0.0.1:8081/product/"+orderInfo.getProductId()；

当更换机器或者新增机器时，这个url就需要跟着变更，那么我们就需要同时去通知所有相关服务去修改，随之而来的就是各个项目的配置文件反复更新，各个项目的频繁部署。这些工作没有具体意义，但是又不得不反复去做。

1.2解决思路

生活中的场景：生活中避免不了和各个机构（医院，学校，政府）打交道，就需要保存各个机构的号码，但要是机构换了电话号码了，难道要一个一个通知使用方吗？不太现实，因为使用方群体是巨大的，没办法做到一个一个通知。那怎么做呢？

有114查号台，如果机构号码换了，就只需要报告给114查号台。用户需要联系机构时，就需要首先打114进行号码查询，然后再联系指定机构。

查号台的作用有两个：

1.号码注册：服务方将电话号码上报给114

2.号码查询：使用方通过114可以查到对应的机构的电话号码

同样，微服务的开放，也可以采用类似的方案：

服务启动/有所变更时，就像注册中心报道，注册中心记录应用和ip的对应关系

调用方调用时，先去注册中心获取服务方的ip，再去服务方进行调用

1.3什么是注册中心

注册中心主要有三个角色：

1.服务提供者（Server）：一次业务中，被其他微服务调用的服务，也就是提供接口给其他微服务

2.服务消费者（Client）：一次业务中，调用其他微服务的服务，也就是调用其他微服务提供的接口。

3.服务注册中心（Registry）：用于保存Server的注册信息，当Server节点发生变更时，Resgistry会同步变更。服务与注册中心使用一定的机制通信，如果注册中心与某服务长时间无法通信，就会注销该实例

注册中心的三个角色之间的关系以及工作的内容可以用下面量方面概述：

1.服务注册：服务提供者在启动时，向Registry注册自身服务，并向Registry定期发送心跳包汇报自身存活状态

2.服务发现：服务消费者从注册中心查询服务提供者的地址，并通过该地址调用服务提供者的接口。服务发现的一个重要作用是给服务消费者提供一个可用的服务列表

1.4CAP理论

CAP理论是分布式系统中最基础也最关键的理论。

C：一致性（consistency）CAP理论中的一致性，指的是强一致性，所有节点在同一时间具有相同的数据

我们知道数据库集群，有主库和从库之分。主库和从库都能够对外提供服务，客户端不一定从哪一个库中获取信息。通常来说，对数据的修改是主库，主库接收到该请求后，还会告诉从库进行同步。而数据的查询一般是从库。

那么数据库向客户端响应的实际应该是什么呢？有两种选择：

1.主库收到请求，并处理成功，但数据还未完全同步到从库中时（只是这时主从数据库数据不同，但是随着时间的推移，最终会达到一致性）

2.主库收到请求，并处理成功，而且所有数据都已同步

这里就体现了弱一致性和强一致性

弱一致性：对外及时响应，但是当时数据还未完全同步。随着时间的推移，主从库都达到一致

强一致性：主库从库，不论何时，对外提供的服务是一致的

A：可用性（Available）保证每一个请求都有响应，但是响应结果可能不对

P：分区容错性（Partition Tolerance）当出现网络分区后，系统仍然能够对外提供服务

网络分区：是指在分布式系统中，由于网络故障或者其他原因，导致系统中的节点无法互相通信，从而形成了多个独立的子系统。

用生活中的例子解释：

银行利率下调，这个通知要发到各个银行工作人员，这个通知下发需要一定时间。

一致性：所有银行工作人员对客户讲的是一样的（那么为了保证一致性，在任务下发期间就要停止对外服务了）

可用性：不论何时，银行工作人员对于顾客咨询利率的请求都是有答案的，但这个大拿可能是错误的。

分区容错性：如果其中一个工作人员请假了，银行依然可以对外提供服务

以上CAP三个要求，P是一定要达到的，然而对于CA，如果达到一致性要求，就不能满足可用性，达到可用性要求，就不能满足一致性

所以CA只能2选1，所以就是CP或AP架构

比如有一个场景，一共两个节点，节点间互相同步数据。客户端A向节点a发出请求要修改数据，之后客户端B向节点b发出请求要获取数据

但是节点a向节点b同步数据的请求发生了异常

CP架构：为了保证分布式系统对外的数据一致性，于是选择不返回任何数据

AP架构：为了保证分布式系统的可用性，节点b选择返回之前版本的数据，即使这个数据它不正确

1.5常见的注册中心

1.Zookeeper ：Zookeeper的官方并没有说它是一个注册中心，但是国内Java体系，大多数集群环境都是依赖Zookeeper来完成注中心的功能的

2.Eureka：Eureka是Netflix开发的基于REST的服务发现框架，主要用于服务注册，管理，负载均衡和服务故障转移。

官方声明在Eureka2.0版本停止维护，不建议使用，但是Eureka是SpringCloud服务注册/服务发现的默认实现，所以目前还有很多公司在使用

3.Nacos:是SpringCloud Alibaba架构中重要的组件，处理服务注册，服务发现功能之外，Nacos还支持配置管理，流量管理，DNS（域名解析协议），动态DNS等多种属性

CAP理论对比：

Zookeeper使用CP，Eureka使用AP,Nacos使用CP/AP

二.Eureka介绍

Eureka是Netflix OSS套件中关于服务注册和发现的解决方案SpringCloud对Eureka进行了集成，官方文档：Home · Netflix/eureka Wiki · GitHub

三.搭建Eureka Server

Eureka Server是一个独立的微服务

1.先将项目搞一个副本，改名为spring-cloud-eureka

父工程的配置文件进行如下修改，将artifactId改一下

子项目的配置文件也进行修改：

两个子项目都要修改

2.创建Eureka-server子模块

3.引入eureka-server的依赖

这个依赖是eureka-server即服务方使用的

4.项目构建插件

项目是用maven打包的，所以要有maven插件

5.完善启动类

在eureka包下面创建EurekaServerApplication

如上，在项目启动类上使用@EnableEurekaServer，可以将项目作为SpringCloud中的注册中心

@SpringBootApplication标识这是一个SpringBoot启动类

6.配置文件

# Eureka 服务
server:port: 10010
spring:application:name: eureka-server
eureka:instance:hostname: localhost #本机client:fetch-registry: false # 表示是否从Eureka Server获取注册信息,默认为true.因为这是一个单点的Eureka Server,不需要同步其他的Eureka Server节点的数据,这里设置为falseregister-with-eureka: false # 表示是否将自己注册到Eureka Server,默认为true.由于当前应用就是Eureka Server,故而设置为false.service-url:# 设置与Eureka Server的地址,查询服务和注册服务都需要依赖这个地址defaultZone: http://${eureka.instance.hostname}:${server.port}/eureka/

7.启动服务

http://127.0.0.1:10010/

四.服务注册

接下来将product-servoce注册到eureka-server中

4.1引入eureka-client的依赖

4.2完善配置文件

spring-application-name是给这个项目配置一个名称，在一个复杂的微服务架构中，每个服务都应有一个唯一的名称以便于识别和管理。

下面这段配置是在 Spring Cloud 应用中用于配置 Eureka 客户端的部分。它主要指定了 Eureka 服务端的地址，使得当前应用能够与 Eureka 服务进行交互，实现服务注册和发现的功能。

eureka.client表明是对 Eureka 客户端进行配置。Eureka 客户端通常运行在各个微服务实例中，负责将服务实例的信息注册到 Eureka 服务端，并从服务端获取其他服务的信息。

server-url.defaultZone:这个属性指定了 Eureka 服务端的 URL。http://127.0.0.1:10010/eureka表示 Eureka 服务端运行在本地，端口号为 10010，并且服务的上下文路径为 “/eureka”。

当微服务启动时，它会使用这个 URL 连接到 Eureka 服务端，将自身的信息（如服务名称、IP 地址、端口号等）注册到服务端。同时，它也会定期从服务端获取其他已注册服务的信息，以便在需要进行服务调用时能够准确地找到目标服务的地址。

4.3启动服务

先将product-service和eureka-server项目启动

刷新注册中心：http://127.0.0.1:10010/

发现product-service已经注册到eureka上面了

五.服务发现

接下来修改order-service，在远程调用时从eureka-server拉取product-service的服务信息，实现服务发现

5.1引入依赖

服务注册和服务发现都封装在eureka-client以来中，所以服务发现时，也是引入eureka-client的依赖

5.2完善配置文件

服务发现也需要直到eureka地址，所以配置内容依然与服务注册一致，都是配置eureka信息

5.3远程调用

首先根据应用名称获取服务实例，取出一个实例，然后进行url拼接。注意，URI（Uniform Resource Identifier，统一资源标识符）和 URL（Uniform Resource Locator，统一资源定位符），他们不太一样，uri主要是告诉你有这样一个资源，但没有具体指定位置在哪里，而url则给出了资源的定位

注意，DiscoveryClient是org.springframework.cloud.client.discovery.DiscoveryClient这个包里面的