【十二】一杯敬大佬，一杯敬SpringCloud

《小吴同学的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 最终测试运行

注： 本文长期更新。此笔记纯个人学习记录整理，如有错误之处，欢迎指正！