Spring-Cloud-Eureka服务注册发现中心server+client案列模拟说明

Spring-Cloud概念理解

Eureka源码分析

Eureka简介及原理

上面三个博文链接大致扫一篇，在读一下下面我所阐述的，然后再回过头来细细翻看一下上面的三个博文，你会发现，原来如此

Eureka架构图

以下纯属个人理解，理解不当请各位手下留情，指出错误，我定感谢，！

Eureka分两部分，一个是服务端server，一个是客户端client，如果做Eureka集群的话，那么

eureka server的集群图如下：

什么是server呢？就是提供服务（service）注册和发现服务（get service）的，打个比方：

假如有块地，很大的那种，我们称作是鱼塘管理区，既然是管理区，肯定少不了鱼塘

我们把鱼塘管理区比作是 eureka服务中心server （服务注册发现中心）

我们把管理区中的鱼塘比作是 eureka服务中心server里面的service（服务）的客户端client部分（服务提供者）

有点绕啊，待说完了，最后我们在总结一下，继续哈

鱼塘肯定不是凭空就出来了，肯定要建造的，建造的时候其实就是在向鱼塘管理区server进行申请，比如，建造的面积多大啊，使用期限多久啊，里面放的有一些什么鱼啊...etc

有了鱼塘后，肯定是要用的，也就是要消费鱼塘，消费的人群就是垂钓爱好者（服务消费者）

垂钓者既然是消费者，那么就要有消费的场地，他们会从鱼塘管理区管理员那里拿到各个鱼塘的信息，比如，A鱼塘鱼比较多,于是大家就去A鱼塘垂钓，假如A鱼塘没鱼了，大家又从管理员那里得知，B鱼塘有鱼，于是，大家就转到B鱼塘垂钓

假如这个鱼塘管理区里面都没有鱼了，怎么办，大家没鱼可钓了，这可不行！

于是乎，管理员（实际中，相当于我们的运维人员）说了，再多来几个鱼塘管理区，一个鱼塘管理区挂掉了，另外的鱼塘管理区补上！

为了统一，每个鱼塘管理区统一规划，比如A鱼塘管理区里面有三个鱼塘1，2，3，那么B鱼塘管理区复制A鱼塘管理区（这里的复制模拟的是server集群中eureka server之间的服务信息同步么也就是复制replicate），里面也有三个规模、信息和1、2、3鱼塘一样的鱼塘

上述表达的就是分布式的概念，相同的服务，部署到不同的web服务器下，保证服务的高可用（服务集群）

这样的好处是什么呢？

保证消费者有鱼可钓！！！

在实际web应用中，就是保证服务的使用者也就是服务消费者能够正常的访问服务并使用。

而不是当某个服务挂掉了（假设服务消费者不知道），消费者傻眼了或者mmp了

而我们的eureka server，也就是服务注册中心，维护着这些服务，哪些服务心跳停止了，就把它剔除，比如说，某块鱼塘死活养不了鱼，那还要它干嘛，一个没有鱼的鱼塘与其闲置着不如去搞搞房地产，哈哈

换句话说，如果一个鱼塘管理区只有一个鱼塘，也就是只有一个服务的话，我们想一想，万一这个鱼塘歇菜了，怎么办？

这时候消费者（垂钓者）可能要说了：“没有鱼你搞个毛线的管理区哟，以后再也不来你们的这了！”

秉着顾客就是上帝的原则，管理区的各个领导一咬牙：“mmp，宁可赔钱，不能丢客户，给我建鱼塘（复用服务）！！！”

于是乎，就出现了下面的情形

红色标注：eureka client中的服务提供者，也就是向eureka server 注册（register）服务的

墨绿色标注：eureka client中的服务消费者，也就是要从eureka server获取（get）服务的，消费者根据服务的状态，进行选择性的服务调用（牵扯负载均衡）

注意，为了保证服务的高可用（我和它算是杠上了，），避免只存在一个服务带来的问题，这里我们开辟了两个Application Service甚至可能更多....总之，在服务注册中心注册的相同的服务越多，对于服务调用者或者说是服务消费者来说也就越有利，而服务注册中心不仅起着服务注册的作用，还起着维护服务的职责，对于那些长时间不给中心发http请求或者下线的服务实例，我们的eureka server会把它们给干掉，没错，就是从它的服务列表里面给移除掉！好处就是，服务消费者始终不会使用到坏掉的服务，总之很嗨皮！

至此，我们对什么是服务注册发现中心算是有了一个大概的了解了，接下来，就是通过demo实例演示了

下一篇：

 

Spring-Boot+Eureka服务注册发现中心案列demo