这个阶段的技术的名词优点多,我们一定要理清楚每一种的技术的名字以及对应的注解名字。如果记不住可以参考我说的以微服务要解决的四个问题为切入点进行记忆。还有就是这部分的学习和SpringBoot后半部分的学习一样,多看文档资料,多理解思想内涵
其实在SpringBoot阶段,我们就已经开始了对微服务的讲解,只不过那时候我们讲的是Dubbo+ZooKeeper+SpringBoot这一套方案。而这个阶段我们主要学习的是SpringCloud Netflix这一套方案。
对于微服务开发,我们学习的SpringBoot已经够用了,而SpringCloud部分也只是对微服务开发的一种生化,毕竟架构不同,相应的管理方式,处理方式也就不一样了。在Spring阶段我们说过一句话,SpringBoot构建一切,SpringCloud协调一切,SpringCloud Date Flow连接一切。对于SpringCloud前期的概念学习,还是那句话,一定要多去看文档资料,这个阶段的学习已经不能仅仅局限于技术的学习了。
SpringCloud抛弃了Dubbo的RPC通信,采用的是基于HTTP的REST方式
Dubbo | Spring | |
---|---|---|
服务注册中心 | ZooKeeper | Spring Cloud Netfilx Eureka |
服务调用方式 | RPC | REST API |
服务监控 | Dubbo-monitor | Spring Boot Admin |
熔断器 | 不完善 | Spring Cloud Netfilx Hystrix |
服务网关 | 无 | Spring Cloud Netfilx Zuul |
分布式配置 | 无 | Spring Cloud Config |
服务跟踪 | 无 | Spring Cloud Sleuth |
消息总线 | 无 | Spring Cloud Bus |
数据流 | 无 | Spring Cloud Stream |
批量任务 | 无 | Spring Cloud Task |
分布式架构会遇到的四个核心问题?
这四个问题一定要牢牢地理解并记住,这会贯穿我们整个SpringCloud阶段的学习。记住这几个问题后,对于我们后期出现的技术才不会乱。
大致步骤与SpringBoot阶段的学习相同,搭建步骤为:
搭建父项目:
搭建实体类项目springcloud-api:
搭建提供者项目springcloud-provider-dept-8001:
搭建消费者项目springcloud-consumer-dept-80:
我们有消费者、有提供者,并且数据都来自不同的项目,我们依然能够完成项目的基本搭建。最终的项目也就是在这个上面完成,只不过项目更多更复杂,但是模板就是这样的。
前面的环境搭建可以对标Dubbo,Eureka我们可以对标ZooKeeper。
我们现在讨论的技术都是建立在微服务的基础之上,微服务又有一个CAP理论,即我们的分布式系统是无法同时满足C(一致性)A(可用性)P(分区容忍性)。我们的ZooKeeper选择了CP,而我们的Eureka选择了AP。
其实对比着ZooKeeper,我们就能够很好的理解了。
Eureka包含两个组件:Eureka Server和Eureka Client,各个节点启动后,会在Eureka Server中注册,这样我们就能够在界面中值观的看到服务节点的信息。Eureka Client是一个java的客户端,应用启动后,会向Eureka Server发送心跳,如果长时间没有接受到心跳,那么我们就会在服务注册表中把这个服务节点进行移除。
Eureka的三大角色:
这三大角色应该不难想到,一个放资源的,一个拿资源的,一个管理资源的。
搭建注册中心项目springcloud-eureka-7001:
将8001项目服务注册进Eureka的步骤:
@EnableEurekaClient
我们在真实的业务开发中,为了知晓开发者到底是谁,就会进行相应的配置,使得我们在开发的时能显示对应的开发者信息。
配置步骤:
@EnableDiscoveryClient
前面我们说了Eureka就是一个注册中心,类似于ZooKeeper。当我们的系统访问压力过大时,Eureka会进行对应的调整,以此让我们的项目更加稳定的运行。
我们这里的配置集群,就相当于配置这个注册中心,让这个注册中心在三台服务器上共同合作,避免因为其中一个注册中心宕机,整个项目崩盘。(这里就体现出了Eureka的A属性,高可用,一部分节点发生故障,整个集群整体还能够相应客户端)
配置集群项目springcloud-eureka-7002
与springcloud-eureka-7003
的步骤:
就是将用户的请求平坦的分配到多个服务上,从而达到系统的HA(高可用)
负载均衡简单分类:
Spring Cloud Ribbon是一个基于Netflix Ribbon实现的一套客户端的负载均衡的工具。
前面我们说了,当我们的系统访问压力过大时,Eureka会进行对应的调整,以此让我们的项目更加稳定的运行。这里的调整就可以是负载均衡,而用到的技术就是Ribbon。
修改我们的springcloud-consumer-dept-80项目步骤:
为了我们能够看到具体实现负载均衡的效果,我们需要使用三个不同的后台提供者服务,这样我们就能够准确的观测到实现负载均衡算法以后的项目访问变化
操作步骤:
在我们的实际测试效果中,我们发现系统默认使用的是轮询算法。
但实际上,它还有很多的其他的算法,甚至是自定义算法
所以现在我们需要修改springcloud-consumer-dept-80项目中的Ribbon配置类
修改默认算法:我们可以将之前使用的默认的模板替换成随机查询算法
自定义算法:我们也可以继承AbstractLoadBalancerRule
类,重写里面的choose方法
我们可以将Feign与Ribbon放在一起理解。
Feign 和 Ribbon 是 Spring Cloud的 Netflix 中提供的两个实现软负载均衡的组件,Ribbon 和 Feign 都是用于调用其他服务的,只是方式不同。Feign则是在Ribbon的基础上进行了一次改进,采用接口的方式,将需要调用的其他服务的方法定义成抽象方法即可,不需要自己构建 http 请求。Feign就是一个Ribbon的改良版。
可以对比使用Mybatis时,我们是使用注解还是xml文件。
配置步骤:
用于处理分布式系统的延迟和容错的开源库,在分布式系统中,许多依赖不可避免地会调用失败,比如超时,异常等,Hystrix能够保证在一个依赖出问题地情况下,不会导致整体服务失败,避免级联过账,以提高分布式系统地弹性
作用:
在我们访问相应的资源时,如果突然出现资源无法获取的现象,那么一段时间以后,服务就会启动相应的熔断机制。用户能够看到到获取资源失败的现象
配置步骤:
与熔断不同,在我们访问相应的资源时,如果资源突然无法获取,我们就会跳转到之前编写的服务降级方法中。这个过程中用户不会感受到程序的出错。
修改方式类似于Ribbon和Feign,两种不同的方式修改的地方不一样。
同样我们的服务熔断是修改提供者项目的代码,我们的服务降级则是修改api项目的代码
配置步骤:
服务熔断:
服务降级:
这个流量监控的界面是在消费者端进行配置
配置springcloud-consumer-hystrix-dashboard项目步骤:
启动成功后,访问对应的9001端口,我们就能够观测到我们服务的相应的信息。dashboard界面更加的直观,方便我们服务进行相应的后期操作。
Zuul包含了对请求的路由和过滤两个主要的功能,Zuul服务最终还是会注册进Eureka
配置springcloud-zuul-9527项目步骤:
我们会发现使用Zuul的路径也可以进行访问,但是我们真实的业务开发中,一般都会使用Zuul过滤掉我们正常的开发业务时的访问路径,继而转向Zuul过滤以后的新的访问路径
具体的配置步骤:
由于我们的项目采用的是分布式架构,所以项目就会十分的多,与此同时我们的配置文件和配置信息也就会越来越多。
那有没有一种方法能够集中对我们的项目运行环境进行一个集中的管理?
当然有,那就是我们的此处的知识。
由于Spring Cloud Config默认使用Git来存储配置文件(也有其他的方式,比如支持SVN和本地文件),但更推荐使用Git,所以我们的项目也就需要上传到GIt,这样我们不仅可以集中进行环境的配置,还可以多人远程协同开发。
我一般是使用码云。
配置步骤:
配置步骤:
bootstrap.yml与application.yml都是能够被识别的配置文件,前者是属于系统级别的配置,后者属于用户级别的配置
这个阶段的核心大致就是,使用在Git技术的加持下,我们能够在远程进行环境的切换以及集中配置,个人觉得这个只多配置几次就熟练了!!!