变态详细版_从零搭建SpringCloud服务

简书：https://www.jianshu.com/p/2d5ee730551a

一.微服务基础

1.什么是SpringCloud？

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

image.png

 

个人理解：

以前的服务器就好像，一个会语数外全能的老师，为学生提供服务，这个老师生病了，那全校停课。

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

让一个超大的服务逻辑，解耦合为一个个小服务，均匀的分布在各自的服务器中。微服务就微在这。

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

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

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

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

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

二.微服务的搭建

1.基于Maven+idea搭建。

SpringCloud需要基于springboot搭建。

2.引入Spring Boot相关依赖。

这里的springboot用的是版本

引入Spring Cloud相关依赖 这里为

（版本名称的命名方式采用了伦敦地铁站的名称，同时根据字母表的顺序来对应版本时间顺序，比如：最早的Release版本：Angel，第二个Release版本：Brixton，然后是Camden、Dalston、Edgware、Finchley版本。

当一个版本的Spring Cloud项目的发布内容积累到临界点或者解决了一个严重bug后，就会发布一个“service releases”版本，简称SRX版本，其中X是一个递增数字。）

2.1 工程初始化配置

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

0.png

2.点击 Spring Initializr->Next

1.png

3.项目命名 -> 项目位置->Next

2.png

 

4.选择Eureka Server->Next

 

3.png

5.配置项目空间，项目名称，服务端-->Finish

4.png

 

6.项目结构如图

5.png

 

7.等待导入dependencies

6.png

 

8.配置pom.xml

 

微信图片_20200306145033.png

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

image.png

知识补充：

 

image.png

 

2.配置启动类注解：@EnableEurekaServer ，运行项目

 

7.png

1. 运行成功console画面

    

   

   8.png

    

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

    

   

   9.png

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

23.png

 

 

1.Next

1.png

2.Next

 

24.png

 

3.Next

 

25.png

4.Next

15.png

16.png

 

5.项目目录，成功后为并列状态，如不为并列或报错请重新配置

 

17.png

6. application.yml

image.png

7.pom.xml:

26.png

1. 因为是服务提供者，这里还需编写服务类controller转存失败重新上传取消转存失败重新上传取消

2. 

   27.png

9.配置support的启动类，添加注解以及扫描包

 

28.png

10.运行测试

 1.先运行第一个项目springcloud-eureka-server

2.再运行第二个项目springcloud-eureka-servicesupport

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

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

29.png

 

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

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

 

20.png

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

2.4 服务的调用方式

image.png

2.4.1 restTemplate+ribbon

ribbon是一种负载均衡的客户端，它是什么呢？请详读https://www.jianshu.com/p/1bd66db5dc46
可以看见其中的一段如下：

image.png

 

接下来我们来搭建基于ribbon的客户端，他用于消费服务。
同理先搭建springboot的环境

1. 新建Module

23.png

1. 选择如图，Next

    

   

   1.png

2. 起名字—Next

    

   

   30.png

3. 选择Ribbon-->Next

    

   

   31.png

5.配置目录，注意仍然要与前两个项目平级

 

32.png

6.Finish目录结构如图

33.png

7.配置消费方application.yml

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

 

 

image.png

8.配置消费方 pom.xml

34.png

注意：

这个对于每个不是注册中心的微服务都要添加

35.png

 

9.配置启动类，添加注解

 

36.png

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

   

   37.png

   
   我们常用第三种调用方式。
   第一种是直接调用：不经过注册中心那服务列表，直接访问的servicesupport
   第二种：是根据服务名选择调用，如上图需要做如下注入

   

   image.png

如上图代码中第二种调用方法的代码所示。
用服务名去注册中心获取服务列表，当前客户端底层会做随机算法的选取获得服务并访问。
第三种需要一个@Bean的注解自动注入并直接调用restTemplate对象调用服务。底层调用模式与第二种调用方式一样。如下：

image.png

 

@Bean注解告诉工厂，这个方法需要自动注入。
@LoadBalanced，表示需要做负载匀衡。
然后如controller中一样注入一下restTemplate，并且使用他，区别是可以直接使用服务名访问了

 

image.png

2.4.2服务调试

1.  

    

   运行注册中心服务server启动类

   

   38.png

2. 运行servicesupport的启动类

    

   

   39.png

3.  

    

   运行serviceconsume的启动类

   

   40.png

    

   

   41.png

8072为服务消费方的端口

访问方法解析：

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

 

42.png

2.5 Eureka server的高可用配置
1.点击下图配置

 

43.png

2.选中server-->点击复制

24.png

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

 

25.png

02:8698

26.png

03:8697

27.png

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

28.png

接下来分别改注册端口号，defaultZone分别启动三个启动项
打开server的yml配置，注释两行端口号配置，与nstance 和hostname

 

29.png

30.png

 

配置好yml后点击启动server01

 

31.png

 

同理，我们再次改动端口号为8699和8697后，把启动项改为02，之后启动

 

32.png

33.png

 

同理把yml端口改为8699 和 8698后，把启动项改为03，之后启动

 

34.png

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

35.png

36.png

37.png

 

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

 

38.png

 

启动服务提供方之后，再次访问三个01，02，03我们会发现
重点：即使服务提供方只注册了一个端口号8699，但是另外两个端口号，也能感知到服务提供方8701的存在了。如下图：

 

39.png

40.png

41.png

 

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

 

42.png

 

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

 

43.png

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

44.png

 

45.png

再次访问消费服务

46.png

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

44.png

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

image.png

 

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

47.png

感谢Anakki
https://blog.csdn.net/qq_29519041/article/details/85238270?depth_1-utm_source=distribute.pc_relevant.none-task&utm_source=distribute.pc_relevant.none-task

 

技术之路，永无止境