SpringCloud简概

SpringCloud简概：count：慢调用比例模式下为慢调用临界RT（超出该值计为慢调用）；异常比例、异常数模式下为对应的阈值。

Spring Cloud简概

• Spring Cloud是什么？
  • 版本说明
  • 服务注册中心
    • Zookeeper
      • 主要功能
        • 配置管理
        • 名字服务
        • 分布式锁
        • 集群管理
      • 节点类型
        • PERSISTENT持久化节点
        • PERSISTENT_SEQUENTIAL持久顺序节点
        • EPHEMERAL临时节点
        • EPHEMERAL_SEQUENTIAL临时自动编号节点
    • Eureka
      • 判断是否满足服务剔除的条件
        • 关闭了自我保护
        • 如果开启了自我保护，需要进一步判断是Eureka Server出了问题，还是Eureka Client出了问题，如果是Eureka Client出了问题则进行剔除。
    • Consul
      • 与Eureka对比
        • 服务注册比Eureka会稍慢一些。因为Consul的raft协议要求必须过半数的节点都写入成功才认为注册成功。
        • Consul Leader挂掉时，重新选举期间整个consul不可用。保证了强一致性但牺牲了可用性。
        • Eureka服务注册相对要快，因为不需要等注册信息replicate到其他节点，也不保证注册信息是否replicate成功。
        • 当数据出现不一致时，虽然A, B上的注册信息不完全相同，但每个Eureka节点依然能够正常对外提供服务，会出现查询服务信息时请求A查不到，但请求B就能查到。
    • Nacos
      • 关键特性
        • 服务发现和服务健康监测
        • 动态配置服务
        • 动态 DNS 服务
        • 服务及其元数据管理
  • 服务间通信
    • Ribbon
    • Feign
      • Feign 工作原理
        • 主程序入口添加了 @ EnableFeignClients 注解开启对 FeignClient 扫描加载处理；
        • 根据 Feign Client 的开发规范，定义接口并加 @ FeignClient 注解；
        • 当程序启动时，会进行包扫描，扫描所有 @ FeignClient 的注解类，并且将这些信息注入Spring IOC容器中；
        • 当定义的Feign接口中的方法被调用时，通过JDK的动态代理来生成具体的RequestTemplate；
        • 当生成代理时，Feign 会为每个接口方法创建一个RequestTemplate对象，该对象封装了HTTP请求需要的全部信息，如：请求参数名、请求方法等信息都是在这个过程中确定的；
        • RequestTemplate生成Request，然后把Request交给Client去处理（这里的Client可以是 JDK原生的 URLConnecttion、Apache的HttpClient、OKhttp）；
        • Client被封装到LoadBalanceClient类，这个类结合Ribbon负载均衡发起服务之间的调用；
    • OpenFeign
    • Ribbon和Feign区别
      • 启动类使用的注解不同
      • 服务的指定位置不同
      • 调用方式不同
    • 调用方式
      • 使用 Spring RestTemplate
        • 1.没有经过服务注册中心获取服务地址，代码写死不利于维护，当服务宕机时不能高效剔除；
        • 2.调用服务时没有负载均衡需要自己实现负载均衡策略；
      • 使用DiscoveryClient
      • 使用LoadBalancerClient
      • 使用 @LoadBalanced，整合 restTemplate + ribbon
      • 使用OpenFeign组件
  • 服务雪崩效应
    • 解决方案
      • 服务熔断
      • 服务降级
        • 自动降级分类
          • 超时降级
          • 失败次数降级
          • 故障降级
            • 降级后的处理方案
              • 默认值（比如库存服务挂了，返回默认现货）
              • 兜底数据（比如广告挂了，返回提前准备好的一些静态页面）
              • 缓存（之前暂存的一些缓存数据）
          • 限流降级
            • 降级后的处理方案
              • 排队页面（将用户导流到排队页面等一会重试）
              • 无货（直接告知用户没货了）
              • 错误页（如活动太火爆了，稍后重试）
      • 熔断、降级区别
        • 触发原因不一样
        • 管理目标的层次不一样
        • 实现方式不一样
    • Hystrix组件
      • Hystrix现状
      • 设计目标
        • 对通过第三方客户端库访问的依赖项（通常是通过网络）的延迟和故障进行保护和控制。
        • 在复杂的分布式系统中阻止级联故障。
        • 快速失败，快速恢复。
        • 回退，尽可能优雅地降级。
        • 启用近实时监控、警报和操作控制。
      • 工作原理
        • 1、创建HystrixCommand 或者HystrixObservableCommand
        • 2、执行命令
          • execute() -- HystrixCommand
          • queue() -- HystrixCommand
          • observe() -- HystrixObservableCommand
          • toObvsevable() -- HystrixObservableCommand
        • 3、返回结果是否被缓存？
        • 4、断路器是否打开？
        • 5、资源(线程池/队列/信号量)是否已满？
        • 6、执行 HystrixObservableCommand.construct() 或者 HystrixCommand.run()
        • 7、计算断路器的健康状况
        • 8、获取Fallback
          • 步骤4 断路器已经被打开
          • 步骤5 执行命令的线程池、队列或者信号量资源已满
          • 步骤6 Command执行时抛出了任何异常
          • 命令执行的时间超过阈值
        • 9、返回成功结果
      • 断路器工作原理
        • 1、断路器时间窗内的请求数是否超过了请求数断路器生效阈值circuitBreaker.requestVolumeThreshold，如果超过了阈值，则将会触发断路，断路状态为开启。例如，如果当前阈值设置的是20，则当时间窗内统计的请求数共计19个，即使19个全部失败了，都不会触发断路器。
        • 2、并且请求错误率超过了请求错误率阈值errorThresholdPercentage。
        • 3、如果两个都满足，则将断路器由关闭迁移到开启。
        • 4、如果断路器开启，则后续的所有相同请求将会被断路掉。
        • 5、直到过了沉睡时间窗sleepWindowInMilliseconds后，再发起请求时，允许其通过（此时的状态为半开起状态）。如果请求失败了，则保持断路器状态为开启状态，并更新沉睡时间窗。如果请求成功了，则将断路器状态改为关闭状态。
      • 断路器配置
        • 是否开启断路器：circuitBreaker.enabled，默认：true
        • 断路器启用请求数阈值：circuitBreaker.requestVolumeThreshold，默认：20
        • 断路器启用失败率阈值：circuitBreaker.errorThresholdPercentage，默认：50(%)
        • 断路器启用后的睡眠时间窗：circuitBreaker.sleepWindowInMilliseconds，默认：5000(ms)
        • 是否强制将断路器设置成开启状态：circuitBreaker.forceOpen，默认：false
        • 是否强制将断路器设置成关闭状态：circuitBreaker.forceClosed，默认：false
      • 资源隔离技术
        • 基于线程池的隔离
          • 优点
            • 使用超时返回的机制，避免同步调用服务时，调用时间过长，无法释放，导致资源耗尽的情况。
            • 服务方可以控制请求数量，请求过多，可以直接拒绝，达到快速失败的目的。
            • 请求排队，线程池可以维护执行队列，将请求压到队列中处理。
          • 缺点
            • 会根据服务划分出独立的线程池，系统资源的线程并发数是有限的，当线程数过多，系统花费大量的CPU时间来做线程上下文切换的无用操作，反而降低系统性能；如果线程池隔离的过多，会导致真正用于接收用户请求的线程就相应地减少，系统吞吐量反而下降。
          • 应用场景
            • 对像远程方法调用，网络资源请求这种服务时间不太可控的场景下使用线程池隔离模式处理。
        • 基于信号量的隔离
          • 优点
          • 缺点
          • 应用场景
        • 线程池VS信号量
          • 是否支持超时
          • 是否支持熔断
          • 隔离原理
          • 是否异步调用
          • 资源消耗情况
    • Sentinel组件
      • 基本概念
        • 资源
        • 规则
      • Sentinel使用
        • 定义资源
          • 方式一：主流框架的默认适配
          • 方式二：抛出异常的方式定义资源
          • 方式三：返回布尔值方式定义资源
          • 方式四：注解方式定义资源
          • 方式五：异步调用支持
        • 定义规则
          • 流量控制规则 (FlowRule)
            • resource：资源名，资源名是限流规则的作用对象
            • count：限流阈值
            • grade：限流阈值类型，QPS模式或并发线程数模式，默认：QPS 模式
            • limitApp：流控针对的调用来源，默认：default，代表不区分调用来源
            • strategy：调用关系限流策略：直接、链路、关联，默认：直接
            • controlBehavior：流控效果（直接拒绝/WarmUp/匀速+排队等待），默认：直接拒绝
            • clusterMode：是否集群限流，默认：否
          • 熔断降级规则 (DegradeRule)
            • resource：资源名，即规则的作用对象
            • grade：熔断策略：慢调用比例、异常比例、异常数策略，默认：慢调用比例
            • count：慢调用比例模式下为慢调用临界RT（超出该值计为慢调用）；异常比例、异常数模式下为对应的阈值
            • timeWindow：熔断时长，单位为s
            • minRequestAmount：熔断触发的最小请求数，请求数小于该值时即使异常比率超出阈值也不会熔断，默认：5
            • statIntervalMs：统计时长（单位为 ms），如60*1000代表分钟级，默认：1000ms
            • slowRatioThreshold：慢调用比例阈值，仅慢调用比例模式有效
          • 系统保护规则 (SystemRule)
            • Load自适应
            • CPU usage
            • 平均 RT
            • 并发线程数
            • 入口 QPS
          • 访问控制规则 (AuthorityRule)
            • resource
            • limitApp
            • strategy
          • 热点规则 (ParamFlowRule)
        • 检验规则是否生效
          • 判断限流降级异常
          • 暴露的 HTTP 接口
          • 日志
        • 集群流控
          • 集群流控中的两种身份
            • Token Client：集群流控客户端，用于向所属 Token Server 通信请求 token。集群限流服务端会返回给客户端结果，决定是否限流。
            • Token Server：即集群流控服务端，处理来自 Token Client 的请求，根据配置的集群规则判断是否应该发放 token（是否允许通过）。
      • Sentinel规则持久化
        • 持久化原理
          • 每个具体的 DataSource 实现类需要做的三件事
            • 实现AbstractDataSource抽象类的readSource方法将数据源中的原始数据转换成我们可以处理的数据S；
            • 提供一个 Converter 来将数据S转换成最终的数据T；
            • 将最终的数据T更新到具体的 RuleManager 中去；
        • Sentinel 支持的5种持久化的方式
          • File
          • Redis
          • Nacos
          • ZK
          • Apollo
      • Sentinel VS Hystrix
        • 侧重点
          • Hystrix
            • 隔离和熔断为主的容错机制，超时或被熔断的调用将会快速失败，并可以提供 fallback 机制。
          • Sentinel
            • 多样化的流量控制
            • 熔断降级
            • 系统负载保护
            • 实时监控和控制台
        • 资源模型和执行模型
          • Hystrix 的资源模型设计上采用了命令模式
          • 资源定义和规则配置是分离的
        • 隔离设计
          • Hystrix 提供两种隔离策略：线程池隔离和信号量隔离
          • Sentinel 提供信号量隔离
        • 熔断降级
          • Sentinel 与 Hystrix 都支持基于失败比率的熔断降级
          • Sentinel 还支持基于平均响应时间的熔断降级
        • 实时指标统计实现
          • Hystrix 和 Sentinel 的实时指标数据统计实现都是基于滑动窗口的
        • 总结
  • 服务网关
    • 什么是服务网关？
      • ​服务网关 = 路由转发 + 过滤器
      • 路由转发：接收一切外界请求，转发到后端的微服务上去；
      • 过滤器：在服务网关中可以完成一系列的横切功能，例如权限校验、限流以及监控等；路由转发也是通过过滤器实现的。
    • 无服务网关存在的问题
      • 客户端多次请求不同的微服务，增加客户端的复杂性；
      • 认证复杂，每个服务都要进行认证；
      • http请求增加，效率不高；
      • 存在跨域请求，比较复杂；
    • 服务网关的好处
      • 减少客户端与微服务之间的调用次数，提高效率；
      • 便于监控，可在网关中监控数据，可以做统一切面任务处理；
      • 便于认证，只需要在网关进行认证即可，无需每个微服务都进行认证；
      • 降低客户端与服务端的耦合度；
    • 服务网关的功能
      • 统一接入
        • 为各种无线应用提供统一接入服务
        • 高性能、高并发、高可靠性
        • 负载均衡，容灾切换（异地多活）
      • 流量管控
        • 服务降级
        • 熔断
        • 路由（异地多活中的应用）
      • 协议适配
        • 前端系统（http、https），后端业务系统（RPC）
        • 长、短连接支持
        • 根据前端请求路由至相应的SOA服务并执行，返回结果给前端
      • 安全维护
        • 对接安全部，IP黑名单，URL黑名单
        • 风控防刷，防恶意攻击等
    • 服务网关（Zuul）
      • Zuul的核心是一系列的过滤器，这些过滤器可以完成以下功能：
        • 身份认证与安全
        • 审查与监控
        • 动态路由
        • 压力测试
        • 负载分配
        • 静态响应处理
        • 多区域弹性
      • 查看端点
        • 开启端点暴露
          • 修改application.yml,暴露端点
        • 查看路由 routes 端点
          • 访问：http://localhost:8060/actuator/routes 可以查看路由设置
        • 查看过滤器 filters 端点
          • 访问：http://localhost:8060/actuator/filters 可以查看过滤器端点
      • 路由配置
        • 默认转发规则：API 网关地址+访问的服务名称+接口 URI
          • API 网关地址：http://localhost:8080
          • 用户服务名称：user-service
          • 用户登录接口：/user/login
          • 通过 Zuul 访问登录接口的规则就是 http://localhost:8080/user-service/user/login
        • 指定具体服务路由
          • zuul.routes.fsh-house.path=/api-house/**
        • 路由前缀
          • zuul.prefix=/rest
        • 本地跳转
          • 在访问 api/1 的时候会路由到本地的 local/1 上去
      • 过滤器
        • 过滤器类型
          • pre
          • route
          • post
          • error
        • 请求的生命周期
          • 过滤器的执行生命周期
          • com.netflix.zuul.http.ZuulServlet 源码
        • 自定义过滤器
          • 创建一个 pre 过滤器，来实现 IP 黑名单的过滤操作
            • 代码示例
            • 过滤器定义完成之后我们需要配置过滤器才能生效
          • 自定义过滤器需要继承 ZuulFilter，并且需要实现下面几个方法
            • shouldFilter
            • filterType
            • filterOrder
            • run
        • 过滤器禁用
          • 利用 shouldFilter 方法中的 return false 让过滤器不再执行。
          • 通过配置方式来禁用过滤器，格式为“zuul. 过滤器的类名.过滤器类型 .disable=true”。
        • 过滤器中传递数据
          • 可以通过 RequestContext 的 set 方法进行传递，RequestContext 的原理是 ThreadLocal。
        • 过滤器拦截请求
          • 拦截并返回结果
          • ctx.setSendZuulResponse(false) ：告诉 Zuul 不需要将当前请求转发到后端的服务。
          • ctx.set("sendForwardFilter.ran"，true)：用来拦截本地转发请求。
          • 当有多个拦截器时，通过 ctx.setSendZuulResponse(false) 设置了不路由到服务，并且返回 null，只是当前的过滤器执行了拦截，后面的过滤器仍然会继续执行。怎么办？
            • 通过拦截器传递参数的方式解决
            • 后面的拦截器只需要在 shouldFilter 方法中判断这个值来决定自己此时是否需要执行
        • 过滤器异常处理
          • 过滤器中的异常主要发生在 run 方法中，可以用 try catch 来处理。
          • Zuul 中提供了一个异常处理的过滤器，当过滤器在执行过程中发生异常，若没有被捕获到，就会进入 error 过滤器中。
            • error过滤器
            • 某个过滤器发生异常时，错误信息输出到页面
            • 通过实现 ErrorController，将错误信息封装成Json格式返回
            • Json格式的错误信息
          • Spring Boot统一异常处理的办法是否可应用于 Zuul ?
            • @ControllerAdvice 注解主要用来针对 Controller 中的方法做处理，作用于 @RequestMapping 标注的方法上，只对我们定义的接口异常有效，在 Zuul 中是无效的。
      • 容错机制
        • 当某个服务不可用时，能够切换到其他可用的服务上去，也就是需要有重试机制。
        • 在属性文件中开启重试机制以及配置重试次数
        • 测试
      • 回退机制
  • 统一配置中心
• 什么是微服务？
  • 一系列微小的服务
  • 围绕自己的业务开发
  • 运行在自己的进程里
  • 独立部署
  • 基于分布式管理
• 为什么是微服务？
  • 单一应用架构
  • 垂直应用机构
  • 分布式应用架构
    • RPC（Remote Procedure Call）远程过程调用
      • RPC实现方式
        • 原理图
        • 执行过程
          • 1、客户端（client）以本地调用方式（即以接口的方式）调用服务；
          • 2、客户端存根（client stub）接收到调用后，将方法、参数等组装成能够进行网络传输的消息体（将消息体对象序列化为二进制）；
          • 3、客户端通过sockets将消息发送到服务端；
          • 4、服务端存根( server stub）收到消息后进行解码（将消息对象反序列化）；
          • 5、服务端存根( server stub）根据解码结果调用本地的服务；
          • 6、本地服务执行并将结果返回给服务端存根( server stub）；
          • 7、服务端存根( server stub）将返回结果打包成消息（将结果消息对象序列化）；
          • 8、服务端（server）通过sockets将消息发送到客户端；
          • 9、客户端存根（client stub）接收到结果消息，并进行解码（将结果消息发序列化）；
          • 10、客户端（client）得到最终结果。
  • 流动（弹性）计算架构