1 提供者与消费者

服务提供者： 一次业务中，被其他微服务调用的服务。（提供接口给其他微服务）
服务消费者： 一次业务中，调用其他微服务的服务。（调用其他微服务提供的接口）

在上一节的示例中
在这里插入图片描述
思考：服务A调用服务B，服务B调用服务C，那么服务B是什么角色？

Answer：

如果相对于A调用B的业务，B是提供者；
如果相对于B调用C的业务，B是消费者；

所以，不能抛开业务来谈一个服务是什么角色。

一个服务既可以是提供者，又可以是消费者。
提供者与消费者角色其实是相对的。相对于具体的业务。不同的业务，角色是会变化的。

2 服务调用出现的问题

在这里插入图片描述
在之前的案例中，我们有一个订单服务，一个用户服务。订单服务需要远程调用用户服务；
它采用的方式是发起一次http请求（如图）
不过在我们的代码当中，我们是将user服务的ip和端口硬编码在代码当中的。

但这样的写法实际上会出现问题：
在公司里开发时，会有开发环境，测试环境，生产环境等等每次环境的变更服务的地址也会发生变化。
如果采用硬编码的方式，难道每次都修改代码，重新编译打包吗？

为了应对更多的并发，将来user服务可能会部署成多实例，形成集群
在这里插入图片描述
这个时候硬编码该写谁的地址呢？
所以一定不能采用硬编码。
如果不做硬编码，这三个服务的地址该怎样去获取呢？
如果以后又有第4台第5台呢？
所以：

1. 服务消费者该如何获取服务提供者的地址信息？
2. 如果有多个服务提供者，消费者该如何选择？
3. 消费者如何得知服务提供者的健康状态？

3 Eureka的作用

在Eureka的结构中，分成了两个概念/角色。第一个角色就是eureka-server，就是服务端，叫注册中心。它的作用就是记录和管理这些微服务。
在这里插入图片描述
第二个角色就是user-service服务提供者，和order-service服务消费者。不管是服务消费者还是服务提供者，都是微服务，所以统称为eureka-client（eureka-客户端）。

每一个服务在启动的时候会把自己的信息，注册给eureka。
Eureka会把对应信息记录下来，比如该服务的名称，ip端口号。
在这里插入图片描述
这个时候如果有一个服务想要消费，比如order-service，它不需要自己去记录信息，而是去找Eureka-server拉取服务提供者的信息。

现在order-service拿到了服务提供者的列表信息了，在上面的例子中有三个，那么需要挑一个。
怎么挑呢？
这个时候要运用负载均衡的知识。
比如说挑到了8081，接下来就是向8081远程调用。
在这里插入图片描述
可能这里有读者会有疑问，挑到的这个会不会是“挂了”的服务？
答案是–不会。
因为服务每隔30s都会向Eureka发一次“心跳”，来确认一下自己的状态。
如果某个服务长时间不向Eureka发送信息，例如8083，Eureka就会将它从列表中“踢掉”。这样下一次服务消费者再向Eureka进行拉取服务提供者的信息时，自然也就拉取不到“挂掉的”服务信息了。
在这里插入图片描述

3.1 消费者该如何获取服务提供者具体信息？

服务提供者启动时向Eureka注册自己的信息；
eureka保存这些信息；
消费者根据服务名称向eureka拉取提供者信息。

3.2 如果有多个服务提供者，消费者该如何选择？

服务消费者利用负载均衡算法，从服务列表中挑选一个。

3.3 消费者如何感知服务提供者健康状态？

服务提供者会每隔30秒向EurekaServer发送心跳请求，报告健康状态；
Eureka会更新记录服务列表信息，心跳不正常会被剔除；
消费者就可以拉取到最新的信息。

4 总结

在Eureka架构中，微服务角色有两类：

EurekaServer：服务端，注册中心：
记录服务信息；心跳监控。
EurekaClient：客户端：
– provider：服务提供者， 例如案例中的user-service：注册自己的信息到EurekaServer；每隔30秒向EurekaServer发送心跳。
– consumer：服务消费者 ，例如案例中的order-service：根据服务名称从EurekaServer拉取服务列表；基于服务列表做负载均衡，选中一个微服务后发起远程调用。