SpringCloud相关概念及配置（一）

SpringCloud相关概念及配置（一）

前言

本篇笔记仅记录SpringCloud的相关概念及配置，底层的详细说明可能会在后期有所说明（也说不准，我可没答应你们哈），配置方面的话因系统及版本而异。如果遇到无法解决的问题可以私信我或者看其他博客。

SpringCloud相关概念介绍

微服务

• 微服务 Microservice：
  最早起源于2014年，2017年SpringCloud将微服务带入了顶峰。
  所谓微服务就是由一系列微小的服务组成；
  他们能独自运行在自己的计算机进程里面。
  可以独立部署
  基于分布式管理的服务
  官方解释：
  微服务就是由一系列服务功能组成，能单独运行在自己的进城里，每个服务独立开发、独立部署、分布式管理。

微服务的解决方案

• Dubbo 阿里： RPC框架（基于TCP协议的通讯框架）：Dubbo、zookeeper、SpringMVC、SpringBoot
• SpringCloud： 一栈式微服务开发 http协议

SpringCloud详解

一个涵盖多个子项目的开发工具集，集合了众多开源框架。和SpringBoot一样，类似于平台产品。共有如下特性：

• 服务注册和发现；
• 路由；
• service - to - service 调用；
• 负载均衡；
• 断路器。

微服务架构中容易出现的问题

• 负责记录服务、监控服务、服务发现。
  // eurekaser（停止维护）、consule（go语言编写）、nacos（alibaba的技术）
• 服务调用问题，使用http reset 方式调用 question：如何调用，服务调用时如何实现负载均衡。
  // rabbion（服务负载均衡） && openfeign（服务调用组件）
• 服务雪崩效应
  // hystrix（断路器） && hystrix dashboard(展示hystrix)
  // 系统中出现级联的时候，hystrix帮助把服务断掉，避免出现服务雪崩。
• 配置文件管理
  // config（统一配置中心组件）
• 网关组件
  // zuul(netflix)、geteway（cloud官方）
• 消息总线：
  // bus 实现config配置文件统一刷新功能。
• 消息中间件不一致：

SpringCloud和SpringBoot 的版本选择

• SpringCloud：最低要求Hoxton-SR6（从Hoxton结束后，版本号命名规范为2020开始）；
• SpringBoot：最低要求2.5以上版本。

---

---

服务注册中心：

Eureka

在整个微服务架构中单独提出一个服务，这个服务不完成系统的任何业务功能，仅仅用来完成对整个微服务系统的服务注册和服务发现，以及对服务的健康状态的监控和管理功能。
Eureka Server :服务注册中心组件。管理所有服务，支持所有服务注册

<!--引入EurekaServer依赖-->
        <dependency>
            <groupId>org.springframework.cloud</groupId>
            <artifactId>spring-cloud-starter-netflix-eureka-server</artifactId>
        </dependency>

• Eureka配置文件：

#eurekaserver端的配置文件
	server.port=8761
	spring.application.name=eurekaserver

	#eureka server 暴露的注册中心地址
	eureka.client.service-url.defaultZone=http://localhost:8761/eureka/

	#不再将自己作为客户端进行注册
	eureka.client.register-with-eureka=false

	#设置该项目作为客户端不在启动时立即注册
	eureka.client.fetch-registry=false
	#必须同时关闭立即注册和客户端身份进行注册，否则eureka依旧会在启动时尝试注册，直到启动结束后才不会注册。

//
#eurekaclient端的配置文件
	server.port=8888

	spring.application.name=eurekaclient

	eureka.client.service-url.defaultZone=http://localhost:8761/eureka

	#不在启动时立即注册
	eureka.client.fetch-registry=false

Eureka相关细节：

• eureka自我保护机制，频繁重启会出现一个红色警告。该自我保护机制有一个规则：
  • Eureka Server在一定时间内（默认90秒）没有接收到某个微服务实例的心跳，Eureka Server 将会移除该实例。到那时当网络分区故障发生时，微服务与Eureka Server之间无法正常通信，而微服务本身是正常运行的，此时不应该一出这个微服务，所以引入了自我保护机制。
  • Eureka Server在运行期间会统计心跳失败比例在15分钟内是否低于85%，如果低于85%，Eureka Server 会将这些实例保护起来，让这些实例不会过期。

Consul

本身是一个软件，安装后每次需要注册中心的时候启动consul就可以，无需新建项目开发注册中心。

• 健康检查：
  consul界面有红叉代表当前服务不可用。
  需配置健康检查依赖才能准确检查。

• 启动方式：
  Windows：配置环境变量后，在cmd中输入 consul agent -dev
  Linux：在解压consul的路径中，输入 ./consul agent -dev -client xx.xx.xx.xx
  （IP地址为本机本机内网IP，如果写为 0.0.0.0表示允许任何接入）

• 【不同注册中心区别】：各种注册中心的区别主要体现在CAP定理。

  • CAP定理（CAP原则）：
    指的是在一个分布式系统中，一致性（Consistency）、可用性（Availability）、
    分区容错性（Partition tolerance），这三个特性最多只能是想两点，不可能三者兼顾；
    下午介绍原因。

    • 一致性：在分布式系统中的所有数据备份，在同一时刻是否同样的值。（等同于所有节点访问同一份最新的数据副本）
      [注]：新的服务必须在集群中所有的节点中注册，否则该服务不可用。
    • 可用性：在集群中一部分节点故障后，几区年整体是否还能相应客户端的读写请求。（对数据更新具备高可用性）
      [注]：新的服务不必须在及群众所有节点中注册，只要有一个节点有该服务即可。
    • 分区容忍性：高可用性，一个节点崩了，并不影响到其他的节点。
      [注]：集群中必须具备的特性。100个节点挂掉几个，并不影响。
    • Eureka（AP）：没有任何数据强一致性算法保证不同集群间的server的数据一致，
      仅通过数据拷贝的方式争取注册中心数据的最终一致性。虽然，
      放弃数据一致性但是换来了server的可用性，降低了注册代价，
      提高了集群运行的健壮性。

  • 以下两种对于一致性要求很高：

    • consul（CP）：基于Raft算法（数据强一致性算法）。通过Gossip协议，Consul可以很好地
      监控Consul句群的运行，同时可以方便通知各类事件，如Leader选择发生、
      server地址的变更等。
    • zookeeper（CP）：基于Zab协议，zookeeper可以用于构建具备数据强一致性的服务注册与发现中心，（用户可以向集群中任意一个节点写数据，被写数据的节点会向master节点提交信息，由master节点确认数据是否正确，如果正确则会发布原子广播使所有节点都更改数据，如果原子广播不成功，则无法保存数据）

    consul使用

• 安装完consul后可以配置path路径实现全局启动

• windows启动时命令为：、

consul agent -dev   //  表示localhost启动
consul agent -dev -client x.x.x.x  //  表示以  x.x.x.x ip启动
[注]：0.0.0.0 表示可以改主机的任何ip连接当前的consul,配置文件中需要以启动时的ip 来连接。

• 其他配置：
  • spring.cloud.consul.discovery.healthCheckInterval = 秒
    // 表示心跳检查的间隔
  • spring.cloud.consul.discovery.register-health-check = true
    // 开启心跳检查

负载均衡组件

• Ribbon组件（负载均衡）

  • 客户端负载均衡，一次性将所有的服务拉下来，再通过负载均衡的算法计算客户端请求的服务。

    [注]：Ribbon依赖 在引入consulClient时便已关联。

    • 使用注解方式来进行基于负载均衡策略的选择服务

    @Configuration
    public class RestTemplateConfig {
    	@Bean  //  在工厂中创建一个restTemplate对象
    	@LoadBalanced   //  代表ribbon负载均衡的restTemplate客户端对象
    	public RestTemplate getRestTemplate(){
    		return new RestTemplate();
    	}
    }
    

    • 接下来只要在controller中注入RestTemplate对象即可

    @Autowired
    private RestTemplate restTemplate;
    

    • handler中：

  String url = "http://服务名/路径";
  Object obj = restTemplate.getForObject(url,String.class);
  

Ribbon组件的负载均衡策略：

• 轮循（RoundRobinRule）：从注册中心下拉列表，在下拉的列表中执行轮循;

• 随机（RandomRule）：从注册中心下拉列表，在下拉的列表中随机选择；

• 可用过滤（AvailabilityFilteringRule）：检查服务是否可用，如果由于服务正在等待或由于多次访问发生断路的状况，那么就会对剩余的服务执行轮询访问;

• 响应时间加权（WeighteResponseTimeRule）：根据平均响应时间计算所有服务的权重，响应时间越快，权重越大。）：根据平均响应时间计算所有服务的权重，响应时间越快，权重越大。被选中的几率越大。在刚启动时，由于数据不足，无法计算，则先使用轮循策略，当信息足够计算时，再执行响应时间加权策略；

• 重试策略（RetryRule）：先按照轮循方式来获取服务，如果获取失败则在指定时间内进行重试，获取可用服务。

• 最低并发（BestAviableRule）：先将由于多次访问故障而处于断路器跳闸状态的服务，然后选择一个并发量最小的服务。服务器并发量分为：

  • 业务并发用户数；
  • 最大并发访问数；
  • 系统用户数；
  • 同时在线用户数；

  假设一个OA系统有1000用户，这是系统用户数；最高峰同时有500人在线，是“同时在线人数”，也称作“最大业务并发用户数”；500个同时使用系统用户中20%查看系统公告，不构成压力；20%填写表格（只在提交时才会请求，填写对服务器不构成压力）；40%在发呆（什么都没做）；20%用户不停从一个页面跳转另一个页面（只有这20%对服务器产生了压力）。

服务间通信手段

• Http 应用层协议 ： 基于http rest 传输json（键值对） —— 效率低；HttpClient 对象： RestTemplate

  • 缺点：

    • 调用地址写死在代码中，不利于维护；且在服务调用的时候无法实现负载均衡。

    • 使用Ribbon解决调用服务过程中的负载均衡；

    • Ribbon仅仅完成了请求的负载均衡的节点选择，具体请求的对象依旧是RestTemplate！

    • Ribbon原理是 根据请求服务的Id，在服务注册中心获取相应的服务列表，然后根据轮循策略（默认轮循）选择一个可用的节点！

• RPC 传输层协议 ： 二进制序列化对象交互 ——效率高（hession、ribbon、dubbo）

总结

本篇笔记总结了使用SpringBoot以及SpringCloud搭建微服务架构的实际操作的核心配置以及微服务架构的相关概念介绍，可能比较困难，多看几遍对未来会有帮助。