《小吴同学的SpringCloud学习之路》
1.微服务概述
1.1到底是啥子
注：没有明确定义，提倡将单一的应用程序划分成一组小的服务。
- 传统的开发 All in one 单机系统 可以看作eclipse里一个大工程
- 同一工作空间只有一个工程
- 分布式系统
- 拆分
- 各自独立的进程
- 微服务（类似医院的各个科室，每个科室做专门的治疗）
- 看似eclipse里maven开发的一个个小module
2.SpringCloud（微服务全家桶）
2.1 这又是啥黑人问号？？？
基于SpringBoot提供了一套解决方案，包括服务注册与发现、配置中心、全链路监控、服务网关、负载均衡、熔断器等组件，除了基于NetFlix的开源组件做高度抽象封装之外，还有一些选型中立的开源组件。
包括：配置管理、服务发现、断路器、路由、微代理、事件总线、全局锁、决策竞选、分布式会话等等。
SpringBoot：提供了一套简单易懂、易部署和易维护的分布式系统开发工具包。
SpringCloud：简而言之，分布式微服务架构下的一站式解决方案，是各个微服务架构落地技术的集合体，俗称微服务全家桶。
2.2 SpringBoot VS SpringCloud
SpringBoot相当于医院里的科室，SpringCloud相当于组合成的医院。
SpringCloud一定依赖SpringBoot，但反之SpringBoot可以离开SpringCloud独立使用开发项目。（水里可以没有鱼，但鱼离不开水。哇好虐有木有==.==）
- SpringBoot
- 专注快速方便的开发单个个体微服务
- SpringCloud
- 关注全局的微服务协调整理治理框架，它将SpringBoot开发的单个个体微服务整合并管理起来，为各个微服务之间提供一整套的服务。
2.2 Dubbo VS SpringCloud
社区支持与更新力度： Github项目活跃度SpringCloud比前者活跃多了。
Dubbo的定位始终是一款RPC框架。
SpringCloud抛弃了Dubbo的Rpc通信，采用的是基于HTTP的REST方式。
图2.2.1 Dubbo与SpringCloud对比
图2.2.2 品牌机与组装机的区别
3.项目走起来
3.1 总父工程项目
- microservicecloud
3.2 通用模块
- microservicecloud-api
3.3 子工程-----部门服务提供者
- microservicecloud-provider-dept-8001
3.4 子工程-----部门服务消费者
- microservicecloud-consumer-dept-80
4.门神Eureka（服务注册与发现）
-
4.1 是什么东东（C/S结构）
图4.1 Eureka是什么 -
4.2 三大角色作用
图4.2 三大角色 - 4.3 子工程-Eureka服务注册中心
-
4.3.1.新建子工程microservicecloud-eureka-7001
图4.3.1 Eureka跑起来 - 4.3.2.将部门提供者服务注册到Eureka中
-
(1)修改Pom.xml文件
添加 spring-cloud-starter-eureka、spring-cloud-starter-config两个Maven坐标
(2)修改application.yml文件
将客户端注册进eureka服务列表内
(3)修改主启动类
添加@EnableEurekaClient注解
(4)修改暴露的部门服务的别名，显示ip及info构建instance: instance-id: microservicecloud-dept8001 prefer-ip-address: true #访问路径可以显示IP地址 ,鼠标点上去左下角有ip图4.3.2 修改服务别名
info构建：修改主工程Pom.xml添加build信息，使其识别src/main/resources下带，在部门的yml配置文件中添加Info构建信息，在部门服务提供者的pom文件添加actuator监控信息完善Maven坐标。
图4.3.3 info内容构建
- 4.4 Eureka自我保护
某时刻某一个服务不可用了，eureka不会立刻清理，依旧会对该服务的信息进行保存。（好死不如赖活着！！！）
图4.4.1 Eureka故障现象超时
图4.4.2 Eureka故障现象宕机
关闭自我保护:在EurekaServer中设置（墙裂不建议）
server:
enable-self-preservation: false
- 4.5 Eureka服务发现
主启动类＠EnableDiscoveryClient
@Autowired private DiscoveryClient client;
-
4.6 Eureka集群配置
- 三个microservicecloud-eureka-7001、microservicecloud-eureka-7002、microservicecloud-eureka-7003yml中配置，部门服务提供者的yml配置文件加上三个eureka-server的地址。
-
C:\Windows\System32\drivers\etc 添加域名映射。验证ping eureka7001.com能ping通代表配置无误。（注：代理添加这三个不走代理）
图4.6.1 集群配置测试7001
-
4.7 Eureka VS Zookeeper
- Eureka保证A(可用性)P，Zookeeper保证C(一致性)P。
- Eureka可以很好应对网络故障导致部分节点失去联系的情况，而不会像Zookeeper那样使整个注册服务瘫痪。
5.Ribbon负载均衡
-
客户端 负载均衡的工具。
图5.1 Ribbon工作图解 如何理解：你去超市收银处 你一定会选择人少的那排吧。就是你作为消费者为考虑去哪消费。
5.1 配置
因为是客户端负载均衡，所以需要修改消费者microservicecloud-consumer-dept-80项目的相关配置信息。
（1）pom添加相应的ribbon相关Maven坐标。
（2）将消费者注册进Eureka中，当然 不向注册中心注册自己。
（3）ConfigBean中添加负载均衡注解。
（4）主启动类添加作为@EnableEurekaClient
（5）修改Controller要找的服务信息直接为部门服务者对外暴露的服务名称。5.2 Ribbon负载均衡体验升级
（1）拷贝多个部门服务提供者分别为microservicecloud-provider-dept-8001、microservicecloud-provider-dept-8002、microservicecloud-provider-dept-8003，修改相应的主启动类名称（没别的意义仅作视觉区分）;
（2）修改相应的yml配置文件，端口、数据库信息、除了注册Eureka中的服务microservicecloud-dept（三个均一样）-
5.3 Ribbon核心组件IRule(很重要！！！)
先说一些常用的负载均衡策略，如下所示：
图5.3.1 常用的询查规则5.3.1 配置常用的Ribbon负载均衡策略
（1）在configBean中return new RandomRule();5.3.2 自定义Ribbo的负载均衡策略
（1）自定义一个新的配置类，切记一个坑：对于Ribbon的配置必须用@Configuration注解标识，并且不能被@Component注解或者@SpringBootApplication（因为里面包含了@Component）扫描到。因为如果被@ComponetScan扫描到会导致所有的RibbonClient都去共享这个配置。
（2）自定义的负载均衡策略RandomRule_WQ extends AbstractLoadBalancerRule，里面的choose()方法很重要可以自定义策略，比如我这实现的是每台机器5次。
6.Feign负载均衡
Feign是啥
它是一个声明式WebService客户端 （具体网上搜，我就略略略了）。Feign可以与Eureka和Ribbon组合使用以实现负载均衡。只需要创建一个接口，然后在上面添加注解即可。
Feign通过接口的方法调用服务（之前是Ribbon+RestTemplate），该请求发送给Eureka服务器(http://MICROSERVICECLOUD-DEPT/dept/list)，通过Feign直接找到服务接口，由于在进行服务调用的时候融合了Ribbon技术，所以也支持负载均衡作用。-
建立microservicecloud-consumer-dept-feign
（1）在Pom文件中加上Feign相关的Maven坐标
（2）api通用模块中也加上Feign相关的Maven坐标，以及新建一个接口DeptClientService，且添加@FeignClient(value = "MICROSERVICECLOUD-DEPT")
（3）在feign子工程中新建controller注入api通用模块中定义的DeptClientService
（4）feign子工程中主启动类上面添加@EnableFeignClients(basePackages= {"com.wq.springcloud"}) @ComponentScan("com.wq.springcloud")
7.Hystrix断路器
处理分布式系统延迟和容错的开源库。它能够保证在一个依赖出问题的情况下，不会导致整体服务失败，避免级联故障，以提高分布式系统的弹性。
“断路器”本身是一种开关装置，当某个服务单元发生故障之后，通过断路哭的故障监控（类似熔断保险丝），向调用方返回一个符合预期的、可处理的备选响应（FallBack），而不是长时间的等待或抛出调用方无法处理的异常，这样就保证了服务调用方的线程不会被长时间、不必要地占用，从而避免了故障在分布式系统中的蔓延，乃至雪崩。
-
7.1 服务熔断：熔断某个故障节点微服务的调用，快速返回“错误”的响应信息。
- （一般是某个服务故障或者异常引起，类似现实中的“保险丝”，当某个异常条件被触发，直接熔断整个服务，而不是一直等到此服务超时。）
新建microservicecloud-provider-dept-hystrix-8001
（1）Pom文件添加Hystrix的Maven坐标；
（2）在yml配置文件中修改实例名称为microservicecloud-dept8001-hystrix；
（3）在Controller层get()方法修改如果查询部门为空时，抛出一个异常，并在方法上添加@HystrixCommand(fallbackMethod = "getErrorDeptByHystrix")，并定义getErrorDeptByHystrix()方法；
（4）主启动类标明对hystrix熔断机制的支持@EnableCircuitBreaker。
- 7.2 服务降级（在客户端完成的降级跟服务端没有关系）
- 所谓降级，一般是从整体负荷考虑。就是当某个服务熔断之后，服务器将不再被调用。此时客户端可以自己准备一个本地的fallback回调，返回一个缺少值。这样做，虽然服务水平下降，但好歹可用，比直接挂掉要强。
（1）修改api的DeptClientService接口，根据已有的DeptClientService接口新建一个实现了FallbackFactory接口的类DeptClientServiceFallbackFactory（切记：一定要添加@Component）。（解耦）
（2）在客户端消费者microservicecloud-consumer-dept-feign修改yml配置文件开启服务降级功能。
- 7.3 豪猪hystrixDashboard
新建子模块：microservicecloud-consumer-hystrix-dashboard
（1）Pom文件添加hystrix和 hystrix-dashboard相关Maven坐标;
（2）配置文件中端口号设为9001;
（3）主启动类添加@EnableHystrixDashboard
访问http://localhost:9001/hystrix，出现如下画面，（初遇豪猪）
图7.3.1 豪猪监控配置
添加相应的监控信息，点击监控查看服务调用情况，如下所示：
图7.3.2 豪猪监控信息
8.SpringCloud_Zuul
- Zuul包含了对请求的路由和过滤两个最主要的功能：其中路由功能负责将外部请求转发到具体的微服务实例上，是实现外部访问统一入口的基础。而过滤器功能则负责对请求的处理过程进行干预，是实现请求校验、服务聚合等功能的基础。Zuul和Eureka进行整合，将Zuul自身注册为Eureka服务治理下的应用，同时从Eureka中获得其他微服务的消息，也即以后的访问微服务都是通过Zuul跳转后获得。
- 注意：Zuul服务最终还是会注册进Eureka。
- 提供=代理+路由+过滤三大功能
新建子模块microservicecloud-zuul-gateway-9527
（1）hosts文件添加域名映射关系 myzuul.com
（2）添加Zuul相关的Maven坐标；
（3）yml配置文件中设置微服务名microservicecloud-zuul-gateway以及暴露的实例名称为gateway-9527.com以及设置路由访问的映射规则（添加前缀，以及忽略原来可用的让它不可用）
（4）主启动类添加@EnableZuulProxy
图8.1 最终测试运行
💙注： 本文长期更新。此笔记纯个人学习记录整理，如有错误之处，欢迎指正！
