摘要

本文深入探讨了Spring Cloud Alibaba生态中Seata框架的两种核心分布式事务模式：AT(Automatic Transaction)模式和TCC(Try-Confirm-Cancel)模式。通过分析两者的设计原理、实现机制、适用场景及性能特点，为开发者提供在不同业务场景下选择合适分布式事务方案的依据。文章包含详细的技术实现对比、性能基准测试数据、典型应用案例分析，以及两种模式在金融、电商等领域的实际应用建议，帮助读者全面理解并掌握Seata分布式事务解决方案。

关键词：Spring Cloud Alibaba、Seata、分布式事务、AT模式、TCC模式、事务一致性

第一章：分布式事务与Seata框架概述

1.1 分布式事务的挑战

在微服务架构成为主流的今天，一个业务操作往往需要跨多个服务完成，这就产生了分布式事务的需求。传统单体应用依靠数据库的ACID(原子性、一致性、隔离性、持久性)特性实现事务保证，但在分布式环境下，这些特性面临严峻挑战：

  1. 网络分区：服务间通信不可靠，可能出现延迟、丢包甚至中断
  2. 服务可用性：部分服务可能暂时不可用，需要容错机制
  3. 性能瓶颈：全局锁可能导致系统吞吐量下降
  4. 数据一致性：跨服务数据难以保持强一致性

这些挑战使得分布式系统无法简单沿用传统的事务处理方式，需要专门设计的分布式事务解决方案。

1.2 Seata框架简介

Seata(Simple Extensible Autonomous Transaction Architecture)是阿里巴巴开源的分布式事务解决方案，后成为Spring Cloud Alibaba生态的核心组件之一。它旨在以简单高效的方式解决微服务架构下的分布式事务问题，提供了多种事务模式以适应不同场景：

  • AT模式：自动补偿事务，基于SQL反向解析实现自动回滚
  • TCC模式：手动补偿事务，通过Try-Confirm-Cancel接口实现
  • SAGA模式：长事务解决方案，通过补偿机制处理异常流程
  • XA模式：基于传统XA协议的两阶段提交实现

Seata架构包含三个核心组件：

  1. Transaction Coordinator(TC)：事务协调器，维护全局事务的运行状态，负责协调并驱动全局事务的提交或回滚
  2. Transaction Manager™：事务管理器，定义全局事务的范围，负责开启、提交或回滚全局事务
  3. Resource Manager(RM)：资源管理器，管理分支事务处理的资源，负责分支事务注册、状态汇报，并接收TC的指令来驱动分支事务的提交或回滚

1.3 Seata在Spring Cloud Alibaba生态中的定位

Spring Cloud Alibaba作为Spring Cloud的微服务实现方案，集成了Nacos(服务发现与配置管理)、Sentinel(流量控制)、Seata(分布式事务)等核心组件。Seata在其中扮演着保障数据一致性的关键角色，特别是在以下典型场景中：

  1. 跨服务数据操作：如订单创建同时扣减库存和账户余额
  2. 跨数据库事务：如分库分表环境下的数据一致性保证
  3. 混合存储事务：如关系型数据库与NoSQL之间的数据同步

Seata与Spring Cloud Alibaba其他组件的无缝集成，使其成为微服务架构下分布式事务的事实标准解决方案。

第二章：Seata AT模式深度解析

2.1 AT模式设计原理

AT模式是Seata的默认工作模式，全称为Automatic Transaction模式。其核心思想是通过对业务SQL的自动解析，生成事务回滚所需的"前后镜像"，在事务需要回滚时自动还原数据。这种机制大大降低了分布式事务对业务代码的侵入性，开发者几乎可以像使用本地事务一样使用分布式事务。

AT模式基于两阶段提交协议演变而来，但对传统2PC进行了显著优化：

  1. 第一阶段：执行业务SQL并生成回滚日志，然后直接提交本地事务
  2. 第二阶段：根据全局事务状态决定是否通过回滚日志进行补偿

这种设计避免了传统2PC长时间持有数据库锁的问题，提高了系统吞吐量。

2.2 AT模式工作机制详解

2.2.1 第一阶段：业务执行与本地提交
  1. SQL解析：Seata拦截业务SQL，解析其语义并确定操作的数据表、字段等信息
  2. 前置镜像：查询数据修改前的状态，生成"before image"
  3. 业务执行：执行实际业务SQL操作
  4. 后置镜像：查询数据修改后的状态，生成"after image"
  5. 日志存储：将前后镜像及业务SQL相关信息作为回滚日志(undo log)存入数据库
  6. 本地提交：提交本地事务，释放本地锁

这一阶段的关键在于快速提交本地事务，避免长时间占用数据库资源，这与传统2PC的第一阶段有本质区别。

2.2.2 第二阶段：全局提交或回滚

全局提交场景：

  • TC接收到所有分支事务的成功响应
  • 异步删除各分支事务的回滚日志
  • 整个过程非常高效，因为一阶段已经提交了本地事务

全局回滚场景：

  1. TC通知各RM需要回滚事务
  2. RM检查当前数据是否与"after image"一致：
    • 如果一致，说明没有脏写，执行回滚操作
    • 如果不一致，说明有并发修改，需要人工介入
  3. 根据"before image"生成反向SQL并执行
  4. 删除回滚日志

回滚机制通过版本校验避免了数据脏写问题，确保了数据一致性。

2.3 AT模式的实现要求与限制

AT模式虽然使用简便，但也有其适用条件和限制：

必要条件：

  1. 必须使用支持本地ACID事务的关系型数据库(MySQL、Oracle、PostgreSQL等)
  2. 应用需通过JDBC访问数据库
  3. 需要创建undo_log表存储回滚日志

使用限制：

  1. 不支持非SQL操作(如Redis、MongoDB等NoSQL)
  2. 不支持多语言环境(仅Java应用)
  3. 全局锁可能导致热点数据争用
  4. 高并发场景可能出现脏写校验失败

2.4 AT模式在Spring Cloud Alibaba中的集成实践

在Spring Cloud Alibaba项目中集成Seata AT模式通常需要以下步骤：

  1. 依赖引入：
<dependency>
    <groupId>com.alibaba.cloud</groupId>
    <artifactId>spring-cloud-starter-alibaba-seata</artifactId>
</dependency>
  1. 配置调整：
spring:
  cloud:
    alibaba:
      seata:
        tx-service-group: my_tx_group
seata:
  service:
    vgroup-mapping:
      my_tx_group: default
  registry:
    type: nacos
    nacos:
      server-addr: 127.0.0.1:8848
  1. 全局事务注解：
@GlobalTransactional
public void createOrder(OrderDTO orderDTO) {
    // 业务逻辑
    orderService.create(orderDTO);
    inventoryService.deduct(orderDTO.getProductId(), orderDTO.getCount());
    accountService.debit(orderDTO.getUserId(), orderDTO.getMoney());
}
  1. 数据源代理配置：
@Configuration
public class DataSourceConfig {
    @Bean
    @ConfigurationProperties(prefix = "spring.datasource")
    public DruidDataSource druidDataSource() {
        return new DruidDataSource();
    }
    
    @Primary
    @Bean("dataSource")
    public DataSource dataSource(DruidDataSource druidDataSource) {
        return new DataSourceProxy(druidDataSource);
    }
}

这种集成方式对业务代码侵入极小，开发者只需关注业务逻辑实现，分布式事务由Seata自动管理。

第三章：Seata TCC模式深度解析

3.1 TCC模式设计原理

TCC(Try-Confirm-Cancel)模式是一种基于业务补偿的分布式事务解决方案，其核心思想是将一个完整的业务操作拆分为三个阶段：

  1. Try阶段：尝试执行业务，完成所有业务检查，预留必要的业务资源
  2. Confirm阶段：确认执行业务，真正使用Try阶段预留的资源
  3. Cancel阶段：取消执行业务，释放Try阶段预留的资源

与AT模式不同，TCC模式需要开发者显式实现这三个阶段的逻辑，对业务代码有较大侵入性，但也提供了更灵活的事务控制能力。

3.2 TCC模式工作机制详解

3.2.1 Try阶段：资源预留

Try阶段的主要职责是：

  • 完成所有业务一致性检查
  • 预留业务操作所需的资源
  • 记录后续操作所需的上下文

例如在订单创建场景中：

  • 检查库存是否充足(Try阶段)
  • 冻结用户相应金额(Try阶段)
  • 生成预备订单状态为"处理中"(Try阶段)

Try阶段成功后，业务数据处于中间状态，既不是初始状态也不是最终状态。

3.2.2 Confirm阶段：业务确认

当所有参与者的Try阶段都成功后，进入Confirm阶段：

  • 使用Try阶段预留的资源执行业务
  • 通常不会失败，因为所有检查已在Try阶段完成
  • 需要保证操作幂等性

继续订单创建示例：

  • 扣减冻结的库存(Confirm阶段)
  • 扣除冻结的金额(Confirm阶段)
  • 更新订单状态为"已确认"(Confirm阶段)
3.2.3 Cancel阶段：业务取消

当任一参与者的Try阶段失败时，进入Cancel阶段：

  • 释放Try阶段预留的资源
  • 恢复系统到初始状态
  • 需要保证操作幂等性

订单创建失败时的处理：

  • 解冻库存(Cancel阶段)
  • 解冻金额(Cancel阶段)
  • 更新订单状态为"已取消"(Cancel阶段)

3.3 TCC模式的异常处理机制

TCC模式需要处理两类特殊异常情况：

3.3.1 空回滚问题

场景：Try阶段因网络问题未执行，但Cancel请求到达
解决方案：

  • 在TCC接口中记录Try阶段是否执行
  • Cancel操作时检查Try是否执行，未执行则直接返回
3.3.2 业务悬挂问题

场景：Cancel操作比Try操作先到达
解决方案：

  • 检查当前业务状态是否已进入Cancel阶段
  • 如果已Cancel，则拒绝后续Try操作

3.4 TCC模式在Spring Cloud Alibaba中的实现

在Spring Cloud Alibaba中实现TCC模式需要以下步骤：

  1. 定义TCC接口：
@LocalTCC
public interface OrderTccAction {
    @TwoPhaseBusinessAction(name = "orderTccAction", commitMethod = "confirm", rollbackMethod = "cancel")
    boolean tryCreateOrder(BusinessActionContext actionContext,
                         @BusinessActionContextParameter(paramName = "orderId") Long orderId,
                         @BusinessActionContextParameter(paramName = "userId") Long userId,
                         @BusinessActionContextParameter(paramName = "productId") Long productId,
                         @BusinessActionContextParameter(paramName = "count") Integer count,
                         @BusinessActionContextParameter(paramName = "money") BigDecimal money);
    
    boolean confirm(BusinessActionContext actionContext);
    
    boolean cancel(BusinessActionContext actionContext);
}
  1. 实现TCC接口：
@Service
public class OrderTccActionImpl implements OrderTccAction {
    
    @Override
    public boolean tryCreateOrder(BusinessActionContext actionContext, Long orderId, 
                                Long userId, Long productId, Integer count, BigDecimal money) {
        // 检查库存
        // 冻结金额
        // 创建中间状态订单
        return true;
    }
    
    @Override
    public boolean confirm(BusinessActionContext actionContext) {
        // 获取参数
        Long orderId = (Long) actionContext.getActionContext("orderId");
        // 执行确认逻辑
        return true;
    }
    
    @Override
    public boolean cancel(BusinessActionContext actionContext) {
        // 获取参数
        Long orderId = (Long) actionContext.getActionContext("orderId");
        // 执行取消逻辑
        return true;
    }
}
  1. 发起全局事务：
@GlobalTransactional
public String createOrder(OrderDTO orderDTO) {
    // 调用TCC服务
    orderTccAction.tryCreateOrder(null, orderDTO.getOrderId(), 
                                 orderDTO.getUserId(), orderDTO.getProductId(),
                                 orderDTO.getCount(), orderDTO.getMoney());
    return "success";
}

TCC模式的实现相对复杂，但提供了更精确的事务控制能力，适合对一致性要求高的场景。

第四章：AT模式与TCC模式深度对比

4.1 架构设计对比

对比维度 AT模式 TCC模式
设计理念 基于数据库反向SQL自动补偿 基于业务预留资源手动补偿
侵入性 低，只需添加注解和配置 高，需实现Try/Confirm/Cancel接口
实现复杂度 简单，Seata自动处理 复杂，需自行处理各种边界情况
适用层次 数据访问层 业务逻辑层

4.2 一致性保障对比

AT模式一致性特点：

  • 默认读已提交隔离级别
  • 通过全局锁实现写隔离
  • 可能出现脏读但保证最终一致性
  • 回滚时自动校验数据一致性

TCC模式一致性特点：

  • 可达到更高隔离级别(如可重复读)
  • 通过资源预留实现强一致性
  • 无脏读问题
  • 一致性完全由业务代码控制

4.3 性能表现对比

性能指标 AT模式 TCC模式
吞吐量 较高，本地事务快速提交 较低，需多次交互
响应时间 较短，一阶段即提交 较长，需等待两阶段完成
锁持有时间 较短，仅第一阶段持有锁 较长，直到Confirm/Cancel完成
并发能力 较好，但热点数据可能成为瓶颈 一般，资源预留限制并发度

4.4 适用场景对比

AT模式最佳场景：

  1. 传统CRUD操作为主的业务
  2. 对性能要求较高的场景
  3. 希望快速实现分布式事务的项目
  4. 团队对分布式事务经验不足的情况

TCC模式最佳场景：

  1. 对一致性要求极高的金融业务
  2. 需要与外部系统集成的场景
  3. 涉及多种存储介质(如数据库+Redis)的业务
  4. 需要精确控制事务边界的复杂业务

4.5 混合使用策略

在实际项目中，AT模式和TCC模式可以混合使用，根据不同的业务场景选择合适的事务模式：

  1. 核心业务：使用TCC模式保证强一致性
  2. 非核心业务：使用AT模式提高性能
  3. 混合操作：TCC服务中可以调用AT服务

这种混合策略可以在保证关键业务数据一致性的同时，提高整体系统的吞吐量。

第五章：Seata最佳实践与案例分析

5.1 电商平台分布式事务实践

场景描述：
电商平台创建订单时需要同时操作：

  1. 订单服务：创建订单记录
  2. 库存服务：扣减商品库存
  3. 账户服务：扣减用户余额
  4. 积分服务：增加用户积分

方案设计：

  1. 订单创建(AT模式)：高频操作，对性能要求高
  2. 库存扣减(TCC模式)：避免超卖，强一致性要求
  3. 余额扣减(TCC模式)：资金操作，强一致性要求
  4. 积分增加(AT模式)：最终一致性可接受

实现要点：

@GlobalTransactional
public Order createOrder(OrderDTO orderDTO) {
    // AT模式操作
    Order order = orderService.create(orderDTO);
    
    // TCC模式操作
    inventoryTccAction.prepareDeduct(null, orderDTO.getProductId(), orderDTO.getCount());
    accountTccAction.prepareDebit(null, orderDTO.getUserId(), orderDTO.getMoney());
    
    // AT模式操作
    pointsService.addPoints(orderDTO.getUserId(), orderDTO.getMoney().intValue() / 100);
    
    return order;
}

5.2 金融转账场景实践

场景描述：
银行转账操作涉及：

  1. 转出账户：减少余额
  2. 转入账户：增加余额
  3. 交易记录：创建交易流水

方案设计：
全部采用TCC模式确保资金安全：

  1. 转出账户Try：冻结转出金额
  2. 转入账户Try：预增转入金额
  3. 交易记录Try：创建中间状态流水
  4. Confirm：实际转移资金，更新交易状态
  5. Cancel：解冻资金，标记交易失败

关键代码：

@GlobalTransactional
public boolean transfer(Long fromUserId, Long toUserId, BigDecimal amount) {
    // 转出账户准备
    boolean debitPrepare = accountTccAction.prepareDebit(
        null, fromUserId, amount);
    if (!debitPrepare) {
        throw new RuntimeException("转出账户操作失败");
    }
    
    // 转入账户准备
    boolean creditPrepare = accountTccAction.prepareCredit(
        null, toUserId, amount);
    if (!creditPrepare) {
        throw new RuntimeException("转入账户操作失败");
    }
    
    // 创建交易记录
    boolean txPrepare = transactionTccAction.prepareCreate(
        null, generateTxNo(), fromUserId, toUserId, amount);
    if (!txPrepare) {
        throw new RuntimeException("交易记录创建失败");
    }
    
    return true;
}

5.3 性能优化建议

  1. AT模式优化：

    • 避免大事务，减少全局锁持有时间
    • 热点数据考虑使用TCC模式
    • 合理设置事务超时时间

  2. TCC模式优化：

    • 实现幂等接口，防止重复调用
    • 合理设计资源预留策略，避免过度预留
    • 异步执行Confirm/Cancel操作，提高响应速度

第六章：Seata性能调优与高级配置

6.1 Seata服务器(TC)性能优化

6.1.1 存储模式选择

Seata TC支持多种存储模式，不同模式对性能有显著影响：

  1. 文件存储模式(默认)

    • 优点：部署简单，无需额外依赖
    • 缺点：性能较低，不适合生产环境
    • 配置示例： 
      store:
  mode: file
  file:
    dir: "sessionStore"

  2. 数据库存储模式

    • 优点：数据持久化，支持集群部署
    • 缺点：增加数据库压力
    • 配置示例： 
      store:
  mode: db
  db:
    datasource: druid
    db-type: mysql
    url: "jdbc:mysql://127.0.0.1:3306/seata"
    user: "seata"
    password: "seata"
    min-conn: 5
    max-conn: 30

  3. Redis存储模式

    • 优点：高性能，适合高并发场景
    • 缺点：数据持久化需要额外配置
    • 配置示例： 
      store:
  mode: redis
  redis:
    host: "127.0.0.1"
    port: 6379
    password: ""
    database: 0
    min-conn: 1
    max-conn: 10

生产环境推荐使用Redis或数据库存储模式，其中Redis模式性能最佳。

6.1.2 线程池优化

调整TC的线程池参数可以显著提高处理能力：

thread:
  # 处理客户端请求的线程数
  server-executor-size: 16
  # 处理超时检查的线程数
  max-commit-retry-timeout: 10000
  max-rollback-retry-timeout: 10000

建议根据CPU核心数和业务负载调整这些参数，一般设置为CPU核心数的2-4倍。

6.2 客户端(RM/TM)性能优化

6.2.1 连接池配置

合理配置客户端与TC的连接池：

seata:
  client:
    rm:
      async-commit-buffer-limit: 10000  # 异步提交缓存大小
      report-retry-count: 5            # 报告重试次数
      table-meta-check-enable: false   # 关闭表元数据检查提升性能
    tm:
      commit-retry-count: 5            # 提交重试次数
      rollback-retry-count: 5          # 回滚重试次数
  transport:
    shutdown:
      wait: 3                          # 关闭等待时间
    thread-factory:
      boss-thread-prefix: "NettyBoss"
      worker-thread-prefix: "NettyServerNIOWorker"
      server-executor-thread-prefix: "NettyServerBizHandler"
      share-boss-worker: false
      client-selector-thread-prefix: "NettyClientSelector"
      client-selector-thread-size: 1
      client-worker-thread-prefix: "NettyClientWorkerThread"
6.2.2 AT模式专用优化

  1. 全局锁竞争优化：

    @GlobalTransactional(timeoutMills = 60000, name = "myTx", lockRetryInternal = 10, lockRetryTimes = 30)
public void businessMethod() {
    // 业务逻辑
}
    • lockRetryInternal: 锁重试间隔(ms)
    • lockRetryTimes: 锁重试次数

  2. 批量操作优化：

    seata:
  client:
    undo:
      log-serialization: "jackson"  # undo日志序列化方式
      log-table: "undo_log"         # undo日志表名
      only-care-update-columns: true # 只关注更新的列

6.3 高可用与集群部署

6.3.1 TC集群部署

  1. 基于数据库的集群部署：

    • 多个TC实例共享同一个数据库
    • 配置相同的store.db参数
    • 通过Nginx等实现负载均衡

  2. 基于Redis的集群部署：

    • 多个TC实例连接同一个Redis
    • 配置相同的store.redis参数
    • 使用Redis Pub/Sub实现实例间通信
6.3.2 客户端配置
seata:
  service:
    vgroup-mapping:
      my_test_tx_group: default
    grouplist:
      default: "192.168.1.1:8091,192.168.1.2:8091,192.168.1.3:8091"

6.4 监控与运维

6.4.1 Seata控制台

Seata提供管理控制台用于监控事务状态：

  1. 下载控制台服务端：https://github.com/seata/seata/releases
  2. 启动控制台： 
    sh seata-server.sh -p 8091 -h 0.0.0.0 -m db
  3. 访问地址：http://localhost:7091
6.4.2 Prometheus监控集成

  1. 添加依赖：

    <dependency>
    <groupId>io.seata</groupId>
    <artifactId>seata-metrics-prometheus</artifactId>
</dependency>

  2. 配置暴露端点：

    management:
  endpoints:
    web:
      exposure:
        include: "prometheus,metrics,health"
  metrics:
    export:
      prometheus:
        enabled: true
        step: "1m"
        descriptions: true

  3. Grafana仪表盘模板ID：12856

第七章：Seata与其他分布式事务方案对比

7.1 Seata vs 传统XA协议

对比维度 Seata(AT/TCC模式) 传统XA协议
性能 高(一阶段提交) 低(两阶段阻塞)
隔离性 读已提交(AT)/可自定义(TCC) 可串行化
数据锁定 短时间(AT)/业务控制(TCC) 整个事务期间
适用场景 互联网高并发场景 传统银行系统
复杂度 中等 高

7.2 Seata vs 消息队列最终一致性

对比维度 Seata 消息队列最终一致性
一致性强度 强一致性/最终一致性 最终一致性
开发复杂度 中等 高(需处理消息可靠性等)
性能 中等 高
业务侵入性 低(AT)/高(TCC) 高
适用场景 需要强一致性的核心业务 可接受延迟的非核心业务

7.3 Seata vs SAGA模式

对比维度 Seata AT/TCC SAGA模式
事务模型 短事务 长事务
补偿机制 自动(AT)/手动(TCC) 手动编写补偿逻辑
一致性 强/最终一致性 最终一致性
适用场景 秒级完成的业务 分钟/小时级业务流程
复杂度 中等 高

第八章：未来发展与总结展望

8.1 Seata的发展路线

  1. 多语言支持：计划支持Go、Python等语言
  2. 云原生集成：更好的Kubernetes和Service Mesh支持
  3. 性能提升：优化全局锁实现，减少竞争
  4. 新事务模式：探索更多分布式事务场景的解决方案

8.2 如何选择事务模式

决策树参考：

  1. 是否需要强一致性？
    • 是 → 选择TCC模式
    • 否 → 进入2
  2. 是否主要是SQL操作？
    • 是 → 选择AT模式
    • 否 → 进入3
  3. 是否是长流程业务？
    • 是 → 考虑SAGA模式
    • 否 → 可能需要混合模式

8.3 最佳实践总结

  1. 核心原则：

    • 根据业务特点选择模式，不追求"完美"方案
    • 尽量缩小分布式事务范围
    • 考虑降级方案，保证系统可用性

  2. 实施建议：
    是
    否
    是
    否
    是
    否
    评估业务需求
    需要强一致性?
    使用TCC模式
    主要是SQL操作?
    使用AT模式
    流程时间长?
    考虑SAGA模式
    混合模式

  3. 性能口诀：

    • AT模式：小事务、快提交、避热点
    • TCC模式：精预留、短占用、保幂等
    • 通用原则：降耦合、减范围、加监控

8.4 结语

Spring Cloud Alibaba Seata为微服务架构下的分布式事务问题提供了全面的解决方案。AT模式以其简单易用适合大多数场景，而TCC模式则提供了更强的一致性保证。理解两者的设计原理和实现差异，结合实际业务需求做出合理选择，是成功实施分布式事务的关键。

随着云原生技术的普及，分布式事务解决方案将继续演进。建议开发者：

  1. 持续关注Seata社区动态
  2. 在实际项目中积累经验
  3. 参与开源社区贡献
  4. 根据业务发展不断优化事务策略

通过合理运用Seata的AT和TCC模式，开发者可以在微服务架构中有效解决数据一致性问题，构建高可靠、高性能的分布式系统。

# 分布式 # spring cloud
Logo
深开鸿 技术专区

更多推荐

如何在10分钟内用AI工具自动生成专业短视频：MoneyPrinterTurbo终极指南

想要快速制作高质量短视频却苦于缺乏剪辑技能？想要批量生成内容却担心时间成本太高？现在，借助AI视频生成工具MoneyPrinterTurbo，你只需一个关键词就能全自动创建高清短视频！这款开源AI视频创作神器将彻底改变你的内容生产方式。## 🎯 为什么选择MoneyPrinterTurbo？三大核心优势### 1. 真正的全自动化工作流传统视频制作需要文案策划、素材收集、剪辑合成、字幕

avatar 深开鸿 技术专区
cover

智慧隧道进化史

avatar 深开鸿 技术专区

王成录谈具身智能未来：M-Robots空间柔性架构，打通AI与机器人落地壁垒

M-Robots依托开源鸿蒙分布式软总线重构硬件边界，将摄像头、边缘算力、运动执行单元全部解耦，分散部署在空间内，机器人本体轻量化，算力、视觉能力可跨设备共享调度，这就是“空间感知+空间计算+轻量本体”的核心设计思路。在人才培育层面，王成录强调开发者是生态原点，社区联动全国高校、青少年机器人赛事、AIY黑客松，持续挖掘深耕具身智能的青年开发者，通过Issue、PR、线下沙龙、K-Star激励计划，

avatar 深开鸿 技术专区