分布式与微服务
开发工具

分布式与微服务

分布式与微服务

微服务简介

单体架构

整个项目中所有功能模块都在一个工程中开发；项目部署时需要对所有模块一起编译、打包；项目的架构设计、开发模式都非常简单。

随着项目的业务规模越来越大，团队开发人员也不断增加，单体架构就呈现出越来越多的问题：

  • 团队协作成本高：试想一下，你们团队数十个人同时协作开发同一个项目，由于所有模块都在一个项目中，不同模块的代码之间物理边界越来越模糊。最终要把功能合并到一个分支，你绝对会陷入到解决冲突的泥潭之中。

  • 系统发布效率低：任何模块变更都需要发布整个系统，而系统发布过程中需要多个模块之间制约较多，需要对比各种文件，任何一处出现问题都会导致发布失败，往往一次发布需要数十分钟甚至数小时。

  • 系统可用性差：单体架构各个功能模块是作为一个服务部署，相互之间会互相影响，一些热点功能会耗尽系统资源，导致其它服务低可用。

微服务架构

首先是服务化，就是将单体架构中的功能模块从单体应用中拆分出来，独立部署为多个服务。同时要满足下面的一些特点：

  • 单一职责：一个微服务负责一部分业务功能，并且其核心数据不依赖于其它模块。

  • 团队自治：每个微服务都有自己独立的开发、测试、发布、运维人员，团队人员规模不超过10人（2张披萨能喂饱）

  • 服务自治：每个微服务都独立打包部署，访问自己独立的数据库。并且要做好服务隔离，避免对其它服务产生影响

SpringCloud

SpringCloud官方文档：https://spring.io/projects/spring-cloud

Spring Cloud 是分布式微服务架构的一站式解决方案，它提供了一套简单易用的编程模型，使我们能在 Spring Boot 的基础上轻松地实现微服务系统的构建。 Spring Cloud 提供以微服务为核心的分布式系统构建标准。

Spring Cloud 本身并不是一个开箱即用的框架，它是一套微服务规范，共有两代实现。

  • Spring Cloud Netflix 是 Spring Cloud 的第一代实现，主要由 Eureka、Ribbon、Feign、Hystrix 等组件组成。

  • Spring Cloud Alibaba 是 Spring Cloud 的第二代实现，主要由 Nacos、Sentinel、Seata 等组件组成。

SpringCloudAlibaba官方文档：https://sca.aliyun.com/zh-cn/

spring-cloud

SCA相关组件

  • Spring Cloud Gateway：网关

  • Nacos：服务注册和配置中心

  • Sentinel：熔断限流

  • Seata：分布式事务

  • RocketMQ：消息队列，削峰填谷

  • Docker：使用Docker进行容器化部署

  • Kubernetes：使用k8s进行容器化部署

微服务拆分

拆分原则

微服务拆分时粒度要小，这其实是拆分的目标。具体可以从两个角度来分析：

  • 高内聚：每个微服务的职责要尽量单一，包含的业务相互关联度高、完整度高。

  • 低耦合：每个微服务的功能要相对独立，尽量减少对其它微服务的依赖，或者依赖接口的稳定性要强。

高内聚首先是单一职责，但不能说一个微服务就一个接口，而是要保证微服务内部业务的完整性为前提。目标是当我们要修改某个业务时，最好就只修改当前微服务，这样变更的成本更低。

一旦微服务做到了高内聚，那么服务之间的耦合度自然就降低了。

当然，微服务之间不可避免的会有或多或少的业务交互，比如下单时需要查询商品数据。这个时候我们不能在订单服务直接查询商品数据库，否则就导致了数据耦合。而应该由商品服务对应暴露接口，并且一定要保证微服务对外接口的稳定性（即：尽量保证接口外观不变）。虽然出现了服务间调用，但此时无论你如何在商品服务做内部修改，都不会影响到订单微服务，服务间的耦合度就降低了。

明确了拆分目标，接下来就是拆分方式了。我们在做服务拆分时一般有两种方式：

- 纵向拆分

- 横向拆分

所谓纵向拆分，就是按照项目的功能模块来拆分。例如商城项目中，就有用户管理功能、订单管理功能、购物车功能、商品管理功能、支付功能等。那么按照功能模块将他们拆分为一个个服务，就属于纵向拆分。这种拆分模式可以尽可能提高服务的内聚性。

而横向拆分，是看各个功能模块之间有没有公共的业务部分，如果有将其抽取出来作为通用服务。例如用户登录是需要发送消息通知，记录风控数据，下单时也要发送短信，记录风控数据。因此消息发送、风控数据记录就是通用的业务功能，因此可以将他们分别抽取为公共服务：消息中心服务、风控管理服务。这样可以提高业务的复用性，避免重复开发。同时通用业务一般接口稳定性较强，也不会使服务之间过分耦合。

服务调用

为了实现跨微服务的远程调用（RPC），Spring给我们提供了一个RestTemplate的API，可以方便的实现Http请求的发送。这与前端ajax发送请求非常相似，都包含四部分信息：

  • 请求方式

  • 请求路径

  • 请求参数

  • 返回值类型

服务注册和发现

通过Http请求实现了跨微服务的远程调用。不过这种手动发送Http请求的方式存在问题。

假如商品微服务被调用较多，为了应对更高的并发，我们进行了多实例部署

此时，每个item-service的实例其IP或端口不同，问题来了：

  • item-service这么多实例，cart-service如何知道每一个实例的地址？

  • http请求要写url地址，cart-service服务到底该调用哪个实例呢？

  • 如果在运行过程中，某一个item-service实例宕机，cart-service依然在调用该怎么办？

  • 如果并发太高，item-service临时多部署了N台实例，cart-service如何知道新实例的地址？

为了解决上述问题，就引入注册中心的概念了。

注册中心原理

流程如下：

  • 服务启动时就会注册自己的服务信息（服务名、IP、端口）到注册中心

  • 调用者可以从注册中心订阅想要的服务，获取服务对应的实例列表（1个服务可能多实例部署）

  • 调用者自己对实例列表负载均衡，挑选一个实例

  • 调用者向该实例发起远程调用

当服务提供者的实例宕机或者启动新实例时，调用者如何得知呢？

  • 服务提供者会定期向注册中心发送请求，报告自己的健康状态（心跳请求）

  • 当注册中心长时间收不到提供者的心跳时，会认为该实例宕机，将其从服务的实例列表中剔除

  • 当服务有新实例启动时，会发送注册服务请求，其信息会被记录在注册中心的服务实例列表

  • 当注册中心服务列表变更时，会主动通知微服务，更新本地服务列表

Nacos是一个更易于构建云原生应用的动态服务发现、配置管理和服务管理平台。

Nacos官方文档：https://nacos.io/zh-cn/docs/v2/quickstart/quick-start.html

Docker安装Nacos：https://nacos.io/zh-cn/docs/v2/quickstart/quick-start-docker.html

服务注册

  • 添加依赖：

<!--nacos 服务注册发现-->
<dependency>
    <groupId>com.alibaba.cloud</groupId>
    <artifactId>spring-cloud-starter-alibaba-nacos-discovery</artifactId>
</dependency>

  • 配置Nacos

spring:
  application:
    name: item-service # 服务名称
  cloud:
    nacos:
      server-addr: 192.168.150.101 # nacos地址

服务发现

  • 添加依赖

<!--nacos 服务注册发现-->
<dependency>
    <groupId>com.alibaba.cloud</groupId>
    <artifactId>spring-cloud-starter-alibaba-nacos-discovery</artifactId>
</dependency>

  • 配置地址

spring:
  cloud:
    nacos:
      server-addr: 192.168.150.101

服务调用者必须利用负载均衡的算法，从多个实例中挑选一个去访问。常见的负载均衡算法有：

  • 随机

  • 轮询

  • IP的hash

  • 最近最少访问

OpenFeign

简介

OpenFeign组件让远程调用像本地方法调用一样简单。远程调用的关键点就在于四个：

  • 请求方式

  • 请求路径

  • 请求参数

  • 返回值类型

OpenFeign利用SpringMVC的相关注解来声明上述4个参数，然后基于动态代理帮我们生成远程调用的代码，而无需我们手动再编写，非常方便。

快速入门

  • 引入依赖

  <!--openFeign-->
  <dependency>
      <groupId>org.springframework.cloud</groupId>
      <artifactId>spring-cloud-starter-openfeign</artifactId>
  </dependency>
  <!--负载均衡器-->
  <dependency>
      <groupId>org.springframework.cloud</groupId>
      <artifactId>spring-cloud-starter-loadbalancer</artifactId>
  </dependency>

  • 启用OpenFeign

Application启动类上添加@EnableFeignClients注解，启动OpenFeign

  • 编写OpenFeign客户端接口示例

@FeignClient("item-service")
public interface ItemClient {

    @GetMapping("/items")
    List<ItemDTO> queryItemByIds(@RequestParam("ids") Collection<Long> ids);
}

这里只需要声明接口，无需实现方法。接口中的几个关键信息：

  • @FeignClient("item-service") ：声明服务名称

  • @GetMapping ：声明请求方式

  • @GetMapping("/items") ：声明请求路径

  • @RequestParam("ids") Collection<Long> ids ：声明请求参数

  • List<ItemDTO> ：返回值类型

有了上述信息，OpenFeign就可以利用动态代理帮我们实现这个方法，并且向http://item-service/items发送一个GET请求，携带ids为请求参数，并自动将返回值处理为List<ItemDTO>。 我们只需要直接调用这个方法，即可实现远程调用了。

调用示例：

日志配置

OpenFeign只会在FeignClient所在包的日志级别为DEBUG时，才会输出日志。而且其日志级别有4级：

  • NONE：不记录任何日志信息，这是默认值。

  • BASIC：仅记录请求的方法，URL以及响应状态码和执行时间

  • HEADERS：在BASIC的基础上，额外记录了请求和响应的头信息

  • FULL：记录所有请求和响应的明细，包括头信息、请求体、元数据。

Feign默认的日志级别就是NONE，所以默认我们看不到请求日志。

定义日志级别

import feign.Logger;
import org.springframework.context.annotation.Bean;

public class DefaultFeignConfig {
    @Bean
    public Logger.Level feignLogLevel(){
        return Logger.Level.FULL;
    }
}

接下来，要让日志级别生效，还需要配置这个类。有两种方式：

  • 局部生效：在某个FeignClient中配置，只对当前FeignClient生效

@FeignClient(value = "item-service", configuration = DefaultFeignConfig.class)

  • 全局生效：在@EnableFeignClients中配置，针对所有FeignClient生效。

@EnableFeignClients(defaultConfiguration = DefaultFeignConfig.class)

网关路由

简单介绍

  1. 微服务拆分后，每个微服务都独立部署，这就存在一些问题：

  • 每个微服务都需要编写登录校验、用户信息获取的功能吗？

  • 当微服务之间调用时，该如何传递用户信息？

  1. 此时就用到网关，前端请求不能直接访问微服务，而是要请求网关：

  • 网关可以做安全控制，也就是登录身份校验，校验通过才放行

  • 通过认证后，网关再根据请求判断应该访问哪个微服务，将请求转发过去

SpringCloudGateway：基于Spring的WebFlux技术，完全支持响应式编程，吞吐能力更强

官方网站：https://spring.io/projects/spring-cloud-gateway#learn

快速入门

需要给网关创建独立的微服务。大致步骤：

  • 创建网关微服务模块

  • 引入SpringCloudGateway、NacosDiscovery依赖

<!--网关-->
        <dependency>
            <groupId>org.springframework.cloud</groupId>
            <artifactId>spring-cloud-starter-gateway</artifactId>
        </dependency>
        <!--nacos discovery-->
        <dependency>
            <groupId>com.alibaba.cloud</groupId>
            <artifactId>spring-cloud-starter-alibaba-nacos-discovery</artifactId>
        </dependency>
        <!--负载均衡-->
        <dependency>
            <groupId>org.springframework.cloud</groupId>
            <artifactId>spring-cloud-starter-loadbalancer</artifactId>
        </dependency>

  • 编写启动类

@SpringBootApplication
public class GatewayApplication {
    public static void main(String[] args) {
        SpringApplication.run(GatewayApplication.class, args);
    }
}

  • 编写yaml配置网关路由示例

server:
  port: 8080
spring:
  application:
    name: gateway
  cloud:
    nacos:
      server-addr: 192.168.150.101
    gateway:
      routes:
        - id: item # 路由规则id，自定义，唯一
          uri: lb://item-service # 路由的目标服务，lb代表负载均衡，会从注册中心拉取服务列表
          predicates: # 路由断言，判断当前请求是否符合当前规则，符合则路由到目标服务
            - Path=/items/**,/search/** # 这里是以请求路径作为判断规则
        - id: cart
          uri: lb://cart-service
          predicates:
            - Path=/carts/**
        - id: user
          uri: lb://user-service
          predicates:
            - Path=/users/**,/addresses/**
        - id: trade
          uri: lb://trade-service
          predicates:
            - Path=/orders/**
        - id: pay
          uri: lb://pay-service
          predicates:
            - Path=/pay-orders/**

然后就可以用 http://localhost:8080 拼接微服务接口路径来测试。

网关登录校验

简单介绍

一切请求都需要先经过网关。我们可以把登录校验的工作放到网关去做，实现了：

  • 只需要在网关和用户服务保存秘钥

  • 只需要在网关开发登录校验功能

使用网关实现登录校验的流程

网关过滤器

要想在请求转发之前做登录校验，就必须了解Gateway内部工作的基本原理。

  1. 客户端请求进入网关后由HandlerMapping对请求做判断，找到与当前请求匹配的路由规则（Route），然后将请求交给WebHandler去处理。

  2. WebHandler则会加载当前路由下需要执行的过滤器链（Filter chain），然后按照顺序逐一执行过滤器（后面称为Filter）。

  3. 图中Filter被虚线分为左右两部分，是因为Filter内部的逻辑分为pre和post两部分，分别会在请求路由到微服务之前和之后被执行。

  4. 只有所有Filter的pre逻辑都依次顺序执行通过后，请求才会被路由到微服务。

  5. 微服务返回结果后，再倒序执行Filter的post逻辑。

  6. 最终把响应结果返回。

我们需要定义一个过滤器，在其中实现登录校验逻辑，并且将过滤器执行顺序定义到NettyRoutingFilter之前，网关过滤器链中的过滤器有两种：

  • GatewayFilter：路由过滤器，作用范围比较灵活，可以是任意指定的路由Route.

  • GlobalFilter：全局过滤器，作用范围是所有路由，不可配置。

Gateway中内置了很多的GatewayFilter，详情可以参考官方文档：

https://docs.spring.io/spring-cloud-gateway/docs/3.1.7/reference/html/#gatewayfilter-factories

登录校验

利用自定义GlobalFilter来完成登录校验示例


@Component
@RequiredArgsConstructor
@EnableConfigurationProperties(AuthProperties.class)
public class AuthGlobalFilter implements GlobalFilter, Ordered {

    private final JwtTool jwtTool;

    private final AuthProperties authProperties;

    private final AntPathMatcher antPathMatcher = new AntPathMatcher();

    @Override
    public Mono<Void> filter(ServerWebExchange exchange, GatewayFilterChain chain) {
        // 1.获取Request
        ServerHttpRequest request = exchange.getRequest();
        // 2.判断是否不需要拦截
        if(isExclude(request.getPath().toString())){
            // 无需拦截，直接放行
            return chain.filter(exchange);
        }
        // 3.获取请求头中的token
        String token = null;
        List<String> headers = request.getHeaders().get("authorization");
        if (!CollUtils.isEmpty(headers)) {
            token = headers.get(0);
        }
        // 4.校验并解析token
        Long userId = null;
        try {
            userId = jwtTool.parseToken(token);
        } catch (UnauthorizedException e) {
            // 如果无效，拦截
            ServerHttpResponse response = exchange.getResponse();
            response.setRawStatusCode(401);
            return response.setComplete();
        }

        // TODO 5.如果有效，传递用户信息
        System.out.println("userId = " + userId);
        // 6.放行
        return chain.filter(exchange);
    }

    private boolean isExclude(String antPath) {
        for (String pathPattern : authProperties.getExcludePaths()) {
            if(antPathMatcher.match(pathPattern, antPath)){
                return true;
            }
        }
        return false;
    }

    @Override
    public int getOrder() {
        return 0;
    }
}

微服务获取用户

现在，网关已经可以完成登录校验并获取登录用户身份信息。但是当网关将请求转发到微服务时，微服务又该如何获取用户身份呢？

由于网关发送请求到微服务依然采用的是Http请求，因此我们可以将用户信息以请求头的方式传递到下游微服务。然后微服务可以从请求头中获取登录用户信息。

考虑到微服务内部可能很多地方都需要用到登录用户信息，因此我们可以利用SpringMVC的拦截器来实现登录用户信息获取，并存入ThreadLocal，方便后续使用。 据图流程图如下：

接下来：

  • 改造网关过滤器，在获取用户信息后保存到请求头，转发到下游微服务

  • 在common服务下先定义ThreadLocal工具类，然后编写微服务拦截器，统一拦截请求获取用户信息，保存到ThreadLocal后放行。示例：

public class UserInfoInterceptor implements HandlerInterceptor {
    @Override
    public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception {
        // 1.获取请求头中的用户信息
        String userInfo = request.getHeader("user-info");
        // 2.判断是否为空
        if (StrUtil.isNotBlank(userInfo)) {
            // 不为空，保存到ThreadLocal
        	UserContext.setUser(Long.valueOf(userInfo));
        }
        // 3.放行
        return true;
    }

    @Override
    public void afterCompletion(HttpServletRequest request, HttpServletResponse response, Object handler, Exception ex) throws Exception {
        // 移除用户
        UserContext.removeUser();
    }
}

  • 登录拦截器

@Configuration
public class MvcConfig implements WebMvcConfigurer {
    @Override
    public void addInterceptors(InterceptorRegistry registry) {
        registry.addInterceptor(new UserInfoInterceptor());
    }
}

这个配置类默认是不会生效的，要将其添加到`resources`目录下的`META-INF/spring.factories`文件中

OpenFeign传递用户

前端发起的请求都会经过网关再到微服务，由于我们之前编写的过滤器和拦截器功能，微服务可以轻松获取登录用户信息。

但有些业务是比较复杂的，请求到达微服务后还需要调用其它多个微服务。比如下单业务，流程如下：

要想实现微服务之间的用户信息传递，就必须在微服务发起调用时把用户信息存入请求头。让每一个由OpenFeign发起的请求自动携带登录用户信息。

在FeignClient所在模块编写拦截器，实现Feign中提供的一个拦截器接口：feign.RequestInterceptor，利用RequestTemplate类来添加请求头。这样以来，每次OpenFeign发起请求的时候都会调用该方法，传递用户信息。

@Bean
public RequestInterceptor userInfoRequestInterceptor(){
    return new RequestInterceptor() {
        @Override
        public void apply(RequestTemplate template) {
            // 获取登录用户
            Long userId = UserContext.getUser();
            if(userId == null) {
                // 如果为空则直接跳过
                return;
            }
            // 如果不为空则放入请求头中，传递给下游微服务
            template.header("user-info", userId.toString());
        }
    };
}

配置管理

简单介绍

到此微服务还存在几个问题：

  • 网关路由在配置文件中写死了，如果变更必须重启微服务

  • 某些业务配置在配置文件中写死了，每次修改都要重启服务

  • 每个微服务都有很多重复的配置，维护成本高

此时用到Nacos的配置管理功能

微服务共享的配置可以统一交给Nacos保存和管理，在Nacos控制台修改配置后，Nacos会将配置变更推送给相关的微服务，并且无需重启即可生效，实现配置热更新。

网关的路由同样是配置，因此同样可以基于这个功能实现动态路由功能，无需重启网关即可修改路由配置。

配置共享

实现步骤：

  • 在Nacos中添加共享配置

比如jdbc相关配置，日志配置，swagger以及OpenFeign的配置都可以添加到Nacos

  • 微服务拉取配置

将拉取到的共享配置与本地的application.yaml配置合并，完成项目上下文的初始化。

需要注意的是，读取Nacos配置是SpringCloud上下文（ApplicationContext）初始化时处理的，发生在项目的引导阶段。然后才会初始化SpringBoot上下文，去读取application.yaml。 也就是说引导阶段，application.yaml文件尚未读取，根本不知道nacos 地址，该如何去加载nacos中的配置文件呢？

SpringCloud在初始化上下文的时候会先读取一个名为bootstrap.yaml的文件，如果我们将nacos地址配置到bootstrap.yaml中，那么在项目引导阶段就可以读取nacos中的配置了。

此时具体步骤

  • 引入依赖

 <!--nacos配置管理-->
  <dependency>
      <groupId>com.alibaba.cloud</groupId>
      <artifactId>spring-cloud-starter-alibaba-nacos-config</artifactId>
  </dependency>
  <!--读取bootstrap文件-->
  <dependency>
      <groupId>org.springframework.cloud</groupId>
      <artifactId>spring-cloud-starter-bootstrap</artifactId>
  </dependency>

  • 新建bootstrap.yaml示例

spring:
  application:
    name: cart-service # 服务名称
  profiles:
    active: dev
  cloud:
    nacos:
      server-addr: 192.168.150.101 # nacos地址
      config:
        file-extension: yaml # 文件后缀名
        shared-configs: # 共享配置
          - dataId: shared-jdbc.yaml # 共享mybatis配置
          - dataId: shared-log.yaml # 共享日志配置
          - dataId: shared-swagger.yaml # 共享日志配置

  • 修改application.yaml需要拉取的配置的配置值为服务名

动态路由

// todo

微服务保护

简单介绍

在微服务远程调用的过程中，还存在几个问题：业务健壮性问题和级联失败问题或者叫雪崩问题

业务健壮性问题：服务a调用服务b返回数据，即使b故障了服务a也应当正常展示数据，即使数据不一致。

级联失败问题：如果一个服务故障了或并发高导致响应时长增加，那调用他的服务甚至整个调用链上的服务响应时长都会增加甚至不可用。

服务保护方案

  • 请求限流

  • 线程隔离

  • 服务熔断

实现微服务保护技术：Sentinel

官方网站：https://sentinelguard.io/zh-cn/

Sentinel 的使用可以分为两个部分:

  • 核心库（Jar包）：不依赖任何框架/库，能够运行于 Java 8 及以上的版本的运行时环境，同时对 Dubbo / Spring Cloud 等框架也有较好的支持。在项目中引入依赖即可实现服务限流、隔离、熔断等功能。

  • 控制台（Dashboard）：Dashboard 主要负责管理推送规则、监控、管理机器信息等。

搭建控制台：

  • 下载jar包

下载地址：https://github.com/alibaba/Sentinel/releases

  • 运行

java -Dserver.port=8090 -Dcsp.sentinel.dashboard.server=localhost:8090 -Dproject.name=sentinel-dashboard -jar sentinel-dashboard.jar

其他配置项：https://github.com/alibaba/Sentinel/wiki/%E5%90%AF%E5%8A%A8%E9%85%8D%E7%BD%AE%E9%A1%B9

  • 访问

访问http://localhost:8080页面，就可以看到sentinel的控制台了：

需要输入账号和密码，默认都是：sentinel

登录后，即可看到控制台，默认会监控sentinel-dashboard服务本身：

微服务整合

  • 引入sentinel依赖

<!--sentinel-->
<dependency>
    <groupId>com.alibaba.cloud</groupId> 
    <artifactId>spring-cloud-starter-alibaba-sentinel</artifactId>
</dependency>

  • 配置控制台

spring:
  cloud: 
    sentinel:
      transport:
        dashboard: localhost:8090

  • 测试访问该服务接口

sentinel的客户端就会将服务访问的信息提交到sentinel-dashboard控制台。并展示出统计信息

// todo

分布式事务

简单介绍

每个微服务都有自己独立的数据库，当调用链发生时每个微服务都会执行自己的本地事务，称为分支事务。多个有关联的分支事务一起就组成了全局事务。因此必须保证整个全局事务同时成功或失败。

分布式事务解决方案：Seata

官方网址：https://seata.io/zh-cn/docs/overview/what-is-seata.html

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

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

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

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

Seata架构图

其中，TM和RM可以理解为Seata的客户端部分，引入到参与事务的微服务依赖中即可。将来TM和RM就会协助微服务，实现本地分支事务与TC之间交互，实现事务的提交或回滚。

而TC服务则是事务协调中心，是一个独立的微服务，需要单独部署。

部署TC服务

  • 准备数据库表

  • 准备配置文件

  • Docker部署

docker run --name seata \
-p 8099:8099 \
-p 7099:7099 \
-e SEATA_IP=192.168.150.101 \
-v ./seata:/seata-server/resources \
--privileged=true \
--network hmall \
-d \
seataio/seata-server:1.5.2

// todo

XA模式

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

两阶段提交

  • 正常情况：

  • 异常情况：

Seata的XA模型

Seata对原始的XA模式做了简单的封装和改造，以适应自己的事务模型，基本架构图：

优缺点

XA模式的优点是什么？

  • 事务的强一致性，满足ACID原则

  • 常用数据库都支持，实现简单，并且没有代码侵入

XA模式的缺点是什么？

  • 因为一阶段需要锁定数据库资源，等待二阶段结束才释放，性能较差

  • 依赖关系型数据库实现事务

AT模式

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

Seata的AT模型

AT与XA的区别

  • XA模式一阶段不提交事务，锁定资源；AT模式一阶段直接提交，不锁定资源。

  • XA模式依赖数据库机制实现回滚；AT模式利用数据快照实现数据回滚。

  • XA模式强一致；AT模式最终一致

可见，AT模式使用起来更加简单，无业务侵入，性能更好。因此企业90%的分布式事务都可以用AT模式来解决。