jdk8新特性以及微服务：微服务保护和分步式事务

JAVA8其他新特性

​ Java 8 (又称为 jdk 1.8) 是 Java 语言开发的一个主要版本。 Java 8 是oracle公司于2014年3月发布，可以看成是自Java 5 以 来最具革命性的版本。Java 8为Java语言、编译器、类库、开发 工具与JVM带来了大量新特性。

Lambda表达式

Lambda 是一个匿名函数，我们可以把 Lambda 表达式理解为是一段可以传递的代码（将代码像数据一样进行传递）。使用它可以写出更简洁、更 灵活的代码。作为一种更紧凑的代码风格，使Java的语言表达能力得到了 提升。

Lambda表达式是一个接口的实例，该接口应当是一个函数式接口（有且仅有一个抽象方法）

案例

public static void main(String[] args) {
    Runnable r1 = new Runnable() {
        @Override
        public void run() {
            System.out.println("hello");
        }
    };
    r1.run();

    Runnable r2 = ()-> System.out.println("hello,too");
    r2.run();
}

案例二

@Test
public void test1(){
    Comparator<Integer> c1 = new Comparator<Integer>() {
        @Override
        public int compare(Integer o1, Integer o2) {
            return Integer.compare(o1,o2);
        }
    };
    int result1 = c1.compare(12,21);
    System.out.println(result1);
	//lambda表达式
    Comparator<Integer> c2 = (o1,o2)->Integer.compare(o1,o2);
    int result2 = c2.compare(33,21);
    System.out.println(result2);

}

Lambda 表达式：在Java 8 语言中引入的一种新的语法元素和操 作符。这个操作符为 “->” ， 该操作符被称为 Lambda 操作符 或箭头操作符。它将 Lambda 分为两个部分：

左侧：指定了 Lambda 表达式需要的参数列表

左边：lambda形参列表的参数类型可以省略(类型推断)；如果lambda形参列表只有一个参数，其一对()也可以省略

右侧：指定了 Lambda 体，是抽象方法的实现逻辑，也即Lambda 表达式要执行的功能。

右边：lambda体应该使用一对{}包裹；如果lambda体只有一条执行语句（可能是return语句），省略这一对{}和return关键字

案例三：

@Test
public void test3() {
    Consumer<String> con = new Consumer<String>() {
        @Override
        public void accept(String o) {
            System.out.println(o);
        }
    };
    //lambda表达式
    Consumer<String> con2 = (String o) -> {
        System.out.println(o);
    };
    //数据类型可以省略，由编译器推断得出
    Consumer<String> con3 = (o) -> {
        System.out.println(o);
    };
    //参数只有一个时，参数小括号可以省略
    Consumer<String> con4 = o -> {
        System.out.println(o);
    };
    //有多个参数，多条语句，且有返回值
    Comparator<Integer> c1=(num1,num2)->{
        System.out.println(num1);
        System.out.println(num2);
        return num1.compareTo(num2);
    };
    //当lambda体只有一条时，return和大括号都可以省略
    Comparator<Integer> c2=(num1,num2)-> num1.compareTo(num2);
}

---

函数式接口

有且仅有一个抽象方法的接口成为函数式接口。@FunctionalInterface

你可以通过 Lambda 表达式来创建该接口的对象。（若 Lambda 表达式 抛出一个受检异常(即：非运行时异常)，那么该异常需要在目标接口的抽 象方法上进行声明）。

在java.util.function包下定义了Java 8 的丰富的函数式接口

隔离

限流是一种预防措施，虽然限流可以尽量避免因高并发而引起的服务故障，但服务还会因为其它原因而故障。

而要将这些故障控制在一定范围，避免雪崩，就要靠线程隔离（舱壁模式）和熔断降级手段了。

线程隔离之前讲到过：调用者在调用服务提供者时，给每个调用的请求分配独立线程池，出现故障时，最多消耗这个线程池内资源，避免把调用者的所有资源耗尽。

Feign整合Sentinel

• 修改OrderService的application.yml文件，开启Feign的Sentinel功能

feign:
	sentinel:    
		enabled: true # 开启Feign的Sentinel功能

• 给FeignClient编写失败后的降级逻辑

  方式一：FallbackClass，无法对远程调用的异常做处理

  方式二：FallbackFactory，可以对远程调用的异常做处理，我们选择这种

  public class UserClientFallbackFactory implements FallbackFactory<UserClient> {
      @Override
      public UserClient create(Throwable throwable) {
          return id->{
              System.out.println("查询异常"+id);
              return new User();
          };
      }
  }
  //注册到容器中
  @Bean
  public UserClientFallbackFactory userClientFallbackFactory(){
      return new UserClientFallbackFactory();
  }
  

• 在@FeignClient中加上fallbackFactory，不是fallback！！！

  @FeignClient(value = "userservice",fallbackFactory = UserClientFallbackFactory.class)
  

完成整合！

Sentinel支持的雪崩解决方案：

• 线程隔离（仓壁模式）

• 降级熔断

Feign整合Sentinel的步骤：

• 在application.yml中配置：feign.sentienl.enable=true

• 给FeignClient编写FallbackFactory并注册为Bean

• 将FallbackFactory配置到FeignClient

---

线程隔离有两种方式实现：

• 线程池隔离

• 信号量隔离（Sentinel默认采用）

如图：

线程池隔离：给每个服务调用业务分配一个线程池，利用线程池本身实现隔离效果

信号量隔离：不创建线程池，而是计数器模式，记录业务使用的线程数量，达到信号量上限时，禁止新的请求。

两者的优缺点：

---

熔断降级

熔断降级是解决雪崩问题的重要手段。其思路是由断路器统计服务调用的异常比例、慢请求比例，如果超出阈值则会熔断该服务。即拦截访问该服务的一切请求；而当服务恢复时，断路器会放行访问该服务的请求。

断路器控制熔断和放行是通过状态机来完成的：

状态机包括三个状态：

• closed：关闭状态，断路器放行所有请求，并开始统计异常比例、慢请求比例。超过阈值则切换到open状态
• open：打开状态，服务调用被熔断，访问被熔断服务的请求会被拒绝，快速失败，直接走降级逻辑。Open状态5秒后会进入half-open状态
• half-open：半开状态，放行一次请求，根据执行结果来判断接下来的操作。
  • 请求成功：则切换到closed状态
  • 请求失败：则切换到open状态

断路器熔断策略有三种：慢调用、异常比例、异常数

---

断路器熔断策略有三种：慢调用、异常比例、异常数

慢调用

• 慢调用：业务的响应时长（RT）大于指定时长的请求认定为慢调用请求。在指定时间内，如果请求数量超过设定的最小数量，慢调用比例大于设定的阈值，则触发熔断。

例如：

解读：RT超过500ms的调用是慢调用，统计最近10000ms内的请求，如果请求量超过10次，并且慢调用比例不低于0.5，则触发熔断，熔断时长为5秒。然后进入half-open状态，放行一次请求做测试。

案例

需求：给 UserClient的查询用户接口设置降级规则，慢调用的RT阈值为50ms，统计时间为1秒，最小请求数量为5，失败阈值比例为0.4，熔断时长为5

1）设置慢调用

修改user-service中的/user/{id}这个接口的业务。通过休眠模拟一个延迟时间：

此时，orderId=101的订单，关联的是id为1的用户，调用时长为60ms：

orderId=102的订单，关联的是id为2的用户，调用时长为非常短；

2）设置熔断规则

下面，给feign接口设置降级规则：

规则：

超过50ms的请求都会被认为是慢请求

3）测试

在浏览器访问：http://localhost:8088/order/101，快速刷新5次，可以发现：

触发了熔断，请求时长缩短至5ms，快速失败了，并且走降级逻辑，返回的null

在浏览器访问：http://localhost:8088/order/102，竟然也被熔断了：

异常比例

异常比例或异常数：统计指定时间内的调用，如果调用次数超过指定请求数，并且出现异常的比例达到设定的比例阈值（或超过指定异常数），则触发熔断。

例如，一个异常比例设置：

解读：统计最近1000ms内的请求，如果请求量超过10次，并且异常比例不低于0.4，则触发熔断。

一个异常数设置：

解读：统计最近1000ms内的请求，如果请求量超过10次，并且异常比例不低于2次，则触发熔断。

总结

Sentinel熔断降级的策略有哪些？

• 慢调用比例：超过指定时长的调用为慢调用，统计单位时长内慢调用的比例，超过阈值则熔断

• 异常比例：统计单位时长内异常调用的比例，超过阈值则熔断

• 异常数：统计单位时长内异常调用的次数，超过阈值则熔断

---

授权规则

授权规则可以对调用方的来源做控制，有白名单和黑名单两种方式。

• 白名单：来源（origin）在白名单内的调用者允许访问

• 黑名单：来源（origin）在黑名单内的调用者不允许访问

点击左侧菜单的授权，可以看到授权规则：

• 资源名：就是受保护的资源，例如/order/{orderId}

• 流控应用：是来源者的名单，

  • 如果是勾选白名单，则名单中的来源被许可访问。
  • 如果是勾选黑名单，则名单中的来源被禁止访问。

比如：

我们允许请求从gateway到order-service，不允许浏览器访问order-service，那么白名单中就要填写网关的来源名称（origin）。

如何获取origin

Sentinel是通过RequestOriginParser这个接口的parseOrigin来获取请求的来源的。

public interface RequestOriginParser {
    /**
     * 从请求request对象中获取origin，获取方式自定义
     */
    String parseOrigin(HttpServletRequest request);
}

这个方法的作用就是从request对象中，获取请求者的origin值并返回。

默认情况下，sentinel不管请求者从哪里来，返回值永远是default，也就是说一切请求的来源都被认为是一样的值default。

因此，我们需要自定义这个接口的实现，让不同的请求，返回不同的origin。

@Component
public class HeaderOriginParser implements RequestOriginParser {
    @Override
    public String parseOrigin(HttpServletRequest request) {
        //获取请求头信息
        String origin = request.getHeader("origin");
        //origin非空
        if (StringUtils.isEmpty(origin)){
            origin="balck";
        }
        return origin;
    }
}

使用网关添加请求头信息

- AddRequestHeader=origin,hello # 添加请求头

这样就只有网关过来的请求可以正常调用了

Blocked by Sentinel (flow limiting)

---

自定义异常结果

默认情况下，发生限流、降级、授权拦截时，都会抛出异常到调用方。异常结果都是flow limmiting（限流）。这样不够友好，无法得知是限流还是降级还是授权拦截。

而如果要自定义异常时的返回结果，需要实现BlockExceptionHandler接口：

public interface BlockExceptionHandler {
    /**
     * 处理请求被限流、降级、授权拦截时抛出的异常：BlockException
     */
    void handle(HttpServletRequest request, HttpServletResponse response, BlockException e) throws Exception;
}

这个方法有三个参数：

• HttpServletRequest request：request对象
• HttpServletResponse response：response对象
• BlockException e：被sentinel拦截时抛出的异常

这里的BlockException包含多个不同的子类：

异常	说明
FlowException	限流异常
ParamFlowException	热点参数限流的异常
DegradeException	降级异常
AuthorityException	授权规则异常
SystemBlockException	系统规则异常

---

案例

@Component
public class SentinelExceptionHandler implements BlockExceptionHandler {
    @Override
    public void handle(HttpServletRequest request, HttpServletResponse response, BlockException e) throws Exception {
        String msg = "未知异常";
        int status = 429;

        if (e instanceof FlowException) {
            msg = "请求被限流了";
        } else if (e instanceof ParamFlowException) {
            msg = "请求被热点参数限流";
        } else if (e instanceof DegradeException) {
            msg = "请求被降级了";
        } else if (e instanceof AuthorityException) {
            msg = "没有权限访问";
            status = 401;
        }

        response.setContentType("application/json;charset=utf-8");
        response.setStatus(status);
        response.getWriter().println("{\"msg\": " + msg + ", \"status\": " + status + "}");
    }
}

---

规则持久化

规则是否能持久化，取决于规则管理模式，sentinel支持三种规则管理模式：

• 原始模式：Sentinel的默认模式，将规则保存在内存，重启服务会丢失。
• pull模式
• push模式

---

pull模式

pull模式：控制台将配置的规则推送到Sentinel客户端，而客户端会将配置规则保存在本地文件或数据库中。以后会定时去本地文件或数据库中查询，更新本地规则。

---

push模式

push模式：控制台将配置规则推送到远程配置中心，例如Nacos。Sentinel客户端监听Nacos，获取配置变更的推送消息，完成本地配置更新。

---

实现push模式

要改源码。。。算了算了。

---

分步式事务

分布式事务，就是指不是在单个服务或单个数据库架构下，产生的事务，例如：

• 跨数据源的分布式事务
• 跨服务的分布式事务
• 综合情况

在数据库水平拆分、服务垂直拆分之后，一个业务操作通常要跨多个数据库、服务才能完成。例如电商行业中比较常见的下单付款案例，包括下面几个行为：

• 创建新订单
• 扣减商品库存
• 从用户账户余额扣除金额

完成上面的操作需要访问三个不同的微服务和三个不同的数据库。

订单的创建、库存的扣减、账户扣款在每一个服务和数据库内是一个本地事务，可以保证ACID原则。

但是当我们把三件事情看做一个"业务"，要满足保证“业务”的原子性，要么所有操作全部成功，要么全部失败，不允许出现部分成功部分失败的现象，这就是分布式系统下的事务了。

此时ACID难以满足，这是分布式事务要解决的问题

---

CAP定理

1998年，加州大学的计算机科学家 Eric Brewer 提出，分布式系统有三个指标。

• Consistency（一致性）
• Availability（可用性）
• Partition tolerance （分区容错性）

当P(分区出现时)，A(一致性)和C(可用性)不能同时存在。

它们的第一个字母分别是 C、A、P。

Eric Brewer 说，这三个指标不可能同时做到。这个结论就叫做 CAP 定理。

BASE理论

BASE理论是对CAP的一种解决思路，包含三个思想：

• Basically Available （基本可用）：分布式系统在出现故障时，允许损失部分可用性，即保证核心可用。
• Soft State（软状态）：在一定时间内，允许出现中间状态，比如临时的不一致状态。
• Eventually Consistent（最终一致性）：虽然无法保证强一致性，但是在软状态结束后，最终达到数据一致。

CAP定理和Base理论为解决分步式事务提供了理论基础。

而分布式事务最大的问题是各个子事务的一致性问题，因此可以借鉴CAP定理和BASE理论：

•AP模式：各子事务分别执行和提交，允许出现结果不一致，然后采用弥补措施恢复数据即可，实现最终一致。

•CP模式：各个子事务执行后互相等待，同时提交，同时回滚，达成强一致。但事务等待过程中，处于弱可用状态。

---

小结

• 简述BASE理论三个思想：

  • 基本可用

  • 软状态

  • 最终一致

• 解决分布式事务的思想和模型：

  • 全局事务：整个分布式事务

  • 分支事务：分布式事务中包含的每个子系统的事务

  • 最终一致思想：各分支事务分别执行并提交，如果有不一致的情况，再想办法恢复数据

  • 强一致思想：各分支事务执行完业务不要提交，等待彼此结果。而后统一提交或回滚

---

Seata

Seata是 2019 年 1 月份蚂蚁金服和阿里巴巴共同开源的分布式事务解决方案。致力于提供高性能和简单易用的分布式事务服务，为用户打造一站式的分布式解决方案。

Seata事务管理中有三个重要的角色：

•TC (Transaction Coordinator) - 事务协调者：维护全局和分支事务的状态，协调全局事务提交或回滚。

•TM (Transaction Manager) - 事务管理器：定义全局事务的范围、开始全局事务、提交或回滚全局事务。

•RM (Resource Manager) - 资源管理器：管理分支事务处理的资源，与TC交谈以注册分支事务和报告分支事务的状态，并驱动分支事务提交或回滚。

Seata基于上述架构提供了四种不同的分布式事务解决方案：

• XA模式：强一致性分阶段事务模式，牺牲了一定的可用性，无业务侵入
• TCC模式：最终一致的分阶段事务模式，有业务侵入
• AT模式：最终一致的分阶段事务模式，无业务侵入，也是Seata的默认模式
• SAGA模式：长事务模式，有业务侵入

无论哪种方案，都离不开TC，也就是事务的协调者。

---

整合Seata

• 引入依赖

<!--seata-->
<dependency>
    <groupId>com.alibaba.cloud</groupId>
    <artifactId>spring-cloud-starter-alibaba-seata</artifactId>
    <exclusions>
        <!--版本较低，1.3.0，因此排除--> 
        <exclusion>
            <artifactId>seata-spring-boot-starter</artifactId>
            <groupId>io.seata</groupId>
        </exclusion>
    </exclusions>
</dependency>
<dependency>
    <groupId>io.seata</groupId>
    <artifactId>seata-spring-boot-starter</artifactId>
    <!--seata starter 采用1.4.2版本-->
    <version>${seata.version}</version>
</dependency>

• 配置配置文件

seata:
  registry: # TC服务注册中心的配置，微服务根据这些信息去注册中心获取tc服务地址
    type: nacos # 注册中心类型 nacos
    nacos:
      server-addr: 127.0.0.1:8848 # nacos地址
      namespace: "" # namespace，默认为空
      group: DEFAULT_GROUP # 分组，默认是DEFAULT_GROUP
      application: seata-tc-server # seata服务名称
      username: nacos
      password: nacos
  tx-service-group: seata-demo # 事务组名称
  service:
    vgroup-mapping: # 事务组与cluster的映射关系
      seata-demo: SH

微服务如何根据这些配置寻找TC的地址呢？

我们知道注册到Nacos中的微服务，确定一个具体实例需要四个信息：

• namespace：命名空间
• group：分组
• application：服务名
• cluster：集群名

以上四个信息，在刚才的yaml文件中都能找到：

namespace为空，就是默认的public

结合起来，TC服务的信息就是：public@DEFAULT_GROUP@seata-tc-server@SH，这样就能确定TC服务集群了。然后就可以去Nacos拉取对应的实例信息了。

---

XA模式

XA 规范 是 X/Open 组织定义的分布式事务处理（DTP，Distributed Transaction Processing）标准，XA 规范 描述了全局的TM与局部的RM之间的接口，几乎所有主流的数据库都对 XA 规范 提供了支持。

正常情况：

异常情况：

一阶段：

• 事务协调者通知每个事物参与者执行本地事务
• 本地事务执行完成后报告事务执行状态给事务协调者，此时事务不提交，继续持有数据库锁

二阶段：

• 事务协调者基于一阶段的报告来判断下一步操作
  • 如果一阶段都成功，则通知所有事务参与者，提交事务
  • 如果一阶段任意一个参与者失败，则通知所有事务参与者回滚事务

---

优点和缺点

• 优点

  1. 事务的强一致性，满足ACID原则。
  2. 常用数据库都支持，实现简单，并且没有代码侵入

• 缺点

  1. 因为一阶段需要锁定数据库资源，等待二阶段结束才释放，性能较差
  2. 依赖关系型数据库实现事务

---

实现步骤

• 修改配置文件，开启XA模式

  data-source-proxy-mode: XA
  

• 标记入门方法@GlobalTransactional

  @Override
  @GlobalTransactional
  public Long create(Order order) {
      // 创建订单
      orderMapper.insert(order);
      try {
          // 扣用户余额
          accountClient.deduct(order.getUserId(), order.getMoney());
          // 扣库存
          storageClient.deduct(order.getCommodityCode(), order.getCount());
  
      } catch (FeignException e) {
          log.error("下单失败，原因:{}", e.contentUTF8(), e);
          throw new RuntimeException(e.contentUTF8(), e);
      }
      return order.getId();
  }
  

• 重启服务。

---

AT模式

AT模式同样是分阶段提交的事务模型，不过缺弥补了XA模型中资源锁定周期过长的缺陷。

基本流程图：

阶段一RM的工作：

• 注册分支事务
• 记录undo-log（数据快照）
• 执行业务sql并提交
• 报告事务状态

阶段二提交时RM的工作：

• 删除undo-log即可

阶段二回滚时RM的工作：

• 根据undo-log恢复数据到更新前

---

AT与XA的区别

简述AT模式与XA模式最大的区别是什么？

• XA模式一阶段不提交事务，锁定资源；AT模式一阶段直接提交，不锁定资源。
• XA模式依赖数据库机制实现回滚；AT模式利用数据快照实现数据回滚。
• XA模式强一致；AT模式最终一致

---

防脏写问题

在多线程并发访问AT模式的分布式事务时，有可能出现脏写问题，如图：

解决思路就是引入了全局锁的概念。在释放DB锁之前，先拿到全局锁。避免同一时刻有另外一个事务来操作当前数据。

在非常极端的情况，由非seata管理的全局事务，修改了被全局锁锁住的字段。

seata会将修改后的快照和回滚后的快照进行对比。

如果不同，则发送警告，由人工介入。

这是一种非常极端的情况，有多种方法可以规避。在业务中，更新数据库中必须使用由seata管理的全局事务等等。

---

优缺点

AT模式的优点：

• 一阶段完成直接提交事务，释放数据库资源，性能比较好
• 利用全局锁实现读写隔离
• 没有代码侵入，框架自动完成回滚和提交

AT模式的缺点：

• 两阶段之间属于软状态，属于最终一致
• 框架的快照功能会影响性能，但比XA模式要好很多

---

实现AT模式

AT模式中的快照生成、回滚等动作都是由框架自动完成，没有任何代码侵入，因此实现非常简单。

只不过，AT模式需要一个表来记录全局锁、另一张表来记录数据快照undo_log。

1）导入数据库表，记录全局锁

导入Sql文件：seata-at.sql，其中lock_table导入到TC服务关联的数据库，undo_log表导入到微服务关联的数据库：

2）修改application.yml文件，将事务模式修改为AT模式即可：

seata:
  data-source-proxy-mode: AT # 默认就是AT

3）重启服务并测试

标签：事务,调用,服务,请求,模式,熔断,分步,jdk8,异常
来源： https://www.cnblogs.com/Boerk/p/16098215.html