springcloud eureka集群_从零搭建SpringCloud服务（史上最详细）

一.微服务基础

这里会介绍很多基础知识，直接想开始搭建微服务的可以看第二章，微服务的搭建。直接看第二章不会有什么影响，可以先学会开车再学习车的构造的，看个人习惯来。

1.什么是SpringCloud？

SpringCloud官网：https://spring.io/projects/spring-cloud（个人建议是用谷歌浏览器访问官网打开中文翻译粗略把官网读一遍）

个人理解：

以前的服务器就好像，一个会语数外全能的老师，为学生提供服务，这个老师生病了，那全校停课。现在微服务流行后，学校有了数学教研组，语文教研组，外语教研组，每个教研组有一群老师具体负责某科的教学，缺了谁，学校都照样运转。而这个变化中，那些改变历史的程序员就是把一个服务器中的众多服务，或好几台服务器中的众多服务，分类出来，解耦合出来，把他们类似的功能交给同一个集群来做，把互相耦合在一起的功能剥离出来，按业务，按功能来把他们作为一个个微服务放在服务器上，而这个服务器就只提供一个服务，或较少的服务。让一个超大的服务逻辑，解耦合为一个个小服务，均匀的分布在各自的服务器中。微服务就微在这。

每个教研组就是一个微服务集群。他们提供同样的服务，而注册中心Eureka就是这个存放这个教研组老师名单的地方，学生们想先访问这个注册中心获取教师名单，然后根据相应的负载方法去访问各自老师。不至于让集群中某一老师累死也不至于让某一老师闲死。

而Zuul网关呢，就是学校的门卫，某些学生来学校找谁，它负责指引（路由），并且通过一些非常简单的配置，达到阻拦一些人进入（身份验证），或者控制想学数学的人只能去数学教研组，不能去核能教研组学怎么造原子弹（权限验证）。

那Hystrix熔断器呢，可以把它当成学校的志愿者，当一个教研组集体罢课后，学生找不到老师了，这些志愿者及时的告诉来访问的学生，相应的结果，异常信息等，免得大量的学生在学校等待，这些志愿者赶快把这些等待的学生梳理出去，学生一直在学校等待，那其他需要学生的学校，也会等待学生，最后造成大面积的学校瘫痪。这里学生我们看成一个个请求。熔断器就是把某事故的蔓延即使熔断了。

当然这些组件也是微服务需要注册到Eureka注册中心

那SpringCloud就可以看成是这个学校了。众多上面提到的组件相当于都是这个学校的各职能部门。

二.微服务的搭建

ps: 博主基于Maven+idea搭建。

另外SpringCloud需要基于springboot搭建。

2.1 引入Spring Boot相关依赖 这里的springboot用的是1.5.7版本

引入Spring Cloud相关依赖 这里为 Edgware.SR5

2.1 工程初始化配置

在Idea中创建工程：File -> New ->Project

点击 Empty Project -> Next

项目命名 -> 项目位置

选择模组 modules ->next

进入新的窗口后，开始配置Maven，打开设置 setting

因为我之前做过配置，因此只需要改变框1的路径，如第一次配置需要自己找到你maven放置的位置，以及settings.xml，repository的位置，实在不会的百度 maven集成idea

3个框选择完毕后点击 ok

接下来新建module

这里可能会出现加载不出archetype list的问题

用了网上的所有解决办法花了3个小时解决都没用，重启之后竟然可以了····你敢信？？？？？小时候网吧网管的至理名言都忘了！！重启一下嘛！！

出来之后 选择quickstart ->下一步

名字自己想 想好后，复制一下你想好的 ArtifactId点击Next，groupId为组织名 也是自己想一个，一般为公司网址反写。

粘贴后下一步

提供注册服务的服务器pom.xml配置如下：

<?

点击Import Changes

等待右下角加载springcloud的依赖

2.2 Springboot的搭建 以及提供注册服务 的 服务配置

创建resources文件夹

并设置作为资源根目录，之后文件变成这样

之后文件夹变成有黄色的横杠

在resources下新建文件，文件名为application.yml （对是yml 不是xml ，博主第一次学习时，还以为是其他博主打错了，踩了一个小坑）

配置yml，注意：如果只配置前两行端口号信息会报错

server:

知识补充：

开发springboot的入口类 EurekaServerApplication.java

EurekaServerApplication.java

package 

右键运行当前类：

运行成功console画面

尝试进入eureka管理界面 端口号为 yml里配置的（端口号自己设置 需要大于公用和保留的端口号）1024~65535

一般我喜欢设置为 8700到8800之间

如下 管理界面已经可以登录了

2.3 客户端client 提供真正服务的角色的配置， 它提供服务 在 服务注册方server （注册中心）进行注册

同样新建module，选择quickstart点击下一步

两个位置 置空

取名 下一步

注意这里要在根目录springcloud 下创建模组，content root 会默认在之前的模组之下创建模组 这样创建模组会出现问题并报错

推荐这种配置方法 在content root下springcloud后改名字 如下图配置点下一步，红框处一般默认为上一个模组的文件目录名，需要改为你的模组名

成功后为并列状态，如不为并列或报错请重新配置

配置servicesupport的pom，与server的pom配置相同，只需要把第一个pom的1的方框处server改为client

和第一个微服务同理 我们需要配置入口类 pom.xml application.yml，因为是服务提供者，这里还需编写服务类controller

application.yml

server:

pom.xml:

编写所提供的 服务controller：

package 

入口类 并运行此微服务：

package 

右键入口类名点击 run（当然开启此服务时需要先开启server服务 就是我们第一个编写的微服务）

此时再进入服务注册的页面 http://localhost:8700/

可以看见服务提供者已被注册进 服务注册者

在直接访问一下服务提供者的 网络位置http://localhost:8701/Hello/World?s=小沛

我们已经看见 可以访问了，证明此微服务可用。

但是我们一般不直接调用所需的微服务，而是经过提供注册服务的服务器server，获取所需的服务提供者列表（为一个列表，此列表包含了能提供相应服务的服务器），他们也许是个集群，因此server会返回一个 ip+端口号的表，服务消费者通过相应算法访问这表上的不同服务器，这些服务器提供的是相同的服务，这种在服务消费者一方挑选服务器为自己服务的方式是一种客户端的负载均衡。目前博主所知的有 轮询和随机两种方式 访问这些服务器，轮询就是循环的意思，假如有3台服务器，访问方式就是1,2,3,1,2,3,1,2,3····，随机就是随机，回想一下random方法，一种无规律的方式。这两种方式都是为了，访问每个服务器的可能性尽量的相同。还有权重负载这种算法，意思就是 根据服务器负载能力的分配相应的服务。能力大的干得多。能力小的干得少。

2.4 服务的调用方式

第一种调用方式：restTemplate+ribbon

第二种调用方式：feign

2.4.1 restTemplate+ribbon

ribbon是一种负载均衡的客户端，它是什么呢？请详读https://www.jianshu.com/p/1bd66db5dc46

可以看见其中的一段如下：

而 客户端负载均衡和 服务端负载均衡最大的不同点在于上面所提到 服务清单所存储的位置。在客户端负载均衡中，所有客户端节点都维护着自己要访问的服务端清单，而这些服务端端清单 来自于服务注册中心，比如上一章我们介绍的Eureka服务端。同服务端负载均衡的架构类似，在客户端负载均衡中也 需要心跳去维护服务端清单的健康性，默认会创建针对各个服务治理框架的Ribbon自动化整合配置，比如Eureka中的org.springframework.cloud.netflix.ribbon.eureka.RibbonEurekaAutoConfiguration，Consul中的org.springframework.cloud.consul.discovery.RibbonConsulAutoConfiguration。在实际使用的时候，我们可以通过查看这两个类的实现，以找到它们的配置详情来帮助我们更好地使用它。

接下来我们来搭建基于ribbon的客户端，他用于消费服务。

同理先搭建springboot的环境

与之前搭建servicesupport不同的是：

第一步：现在pom中需要在dependencies中添加ribbon依赖

 <dependency>

 <groupId>org.springframework.cloud</groupId>

 <artifactId>spring-cloud-starter-ribbon</artifactId>

 </dependency>

第二步：yml如下配置：

server:

服务的消费方依旧需要在注册方8700端口去注册。配置当前服务消费方的端口8072，名字为eureka-consumer

第三步：依旧需要启动类，因为它是一个springboot的架构：

package 

如上图：

我们需要一个controller类来编写ribbon的代码。

package 

我们常用第三种调用方式。

第一种是直接调用：不经过注册中心那服务列表，直接访问的servicesupport

第二种：是根据服务名选择调用，如上图需要做如下注入

@Autowired
private LoadBalancerClient loadBalancerClient;

如上图代码中第二种调用方法的代码所示。

用服务名去注册中心获取服务列表，当前客户端底层会做随机算法的选取获得服务并访问。

第三种需要一个@Bean的注解自动注入并直接调用restTemplate对象调用服务。底层调用模式与第二种调用方式一样。如下：

package 

@Bean注解告诉工厂，这个方法需要自动注入。

@LoadBalanced，表示需要做负载匀衡。

然后如controller中一样注入一下restTemplate，并且使用他，区别是可以直接使用服务名访问了

String forObject = restTemplate.getForObject("http://EUREKA-SERVICE/Hello/World?s=" + s, String.class);

开始测试：

1.运行server的启动类：

2.运行servicesupport的启动类：

3.运行serviceconsume的启动类：

浏览器访问：

8072为服务消费方的端口

访问方法解析：

• 访问服务消费方@RequestMapping指定的路径及消费方的端口来访问消费方的controller
• controller根据服务名去server方获取获取服务列表，获取服务列表后根据随机的模式负载匀衡后去选择服务地址去访问servicesupport：如下图

2.5 Eureka server的高可用配置

点击下图配置

接下来配置三台01,02,03的虚拟机参数

01:8699

02:8698

03:8697

之后点ok保存，可看见多出三个启动项

接下来分别改注册端口号，defaultZone分别启动三个启动项

打开server的yml配置，删掉前两行端口号配置（图中有错，请把instance 和hostname那两行删掉）

配置好yml后点击启动

同理，我们再次改动端口号为8699和8697后，把启动项改为02，之后启动（图中有错，请把instance 和hostname那两行删掉）

同理把yml端口改为8699 和 8698后，把启动项改为03，之后启动（图中有错，请把instance 和hostname那两行删掉）

启动后分别访问三个01，02，03端口，已经可以看见可以访问了。

打开服务提供方的yml配置如下，把端口号改为三个中其中的一个。

启动服务提供方之后，再次访问三个01，02，03我们会发现

重点：即使服务提供方只注册了一个端口号8699，但是另外两个端口号，也能感知到服务提供方8701的存在了。如下图：

接下来像服务消费方中添加服务注册者的端口号，这样在server挂掉任何一个的时候，都能有其他的server也能获取服务列表

访问以下服务消费方，发现可以通过消费方调用server服务列表并且访问service了

我么随便关闭其中两个server的副本，重启serviceconsume，再进行访问。必须重启serviceconsume才能清空缓存，清掉consume里面有的服务列表。

上图发现即使关闭两台server后依旧可以访问，如下图，依旧从server中获取了服务列表，从中也能看见之后不用再获取服务列表了。

但是当我们关掉所有server后。访问还是没问题，因为缓存了服务列表。

但是让我们来重启一下serviceconsume，再访问就不行了。

综上我们就完成了springcloud中server的高可用配置

搭好了别忘点赞呀~

---

原作者：Anakki
原文链接：从零搭建SpringCloud服务（史上最详细）_Anakki的博客-CSDN博客
原出处：CSDN博客
侵删