Spring Cloud Alibaba 最佳实践与面试考点

本章是 Spring Cloud Alibaba 独立教程的收官之作，将前面各章的知识点整合为生产可用的最佳实践方案，并从面试视角体系化梳理核心考点。

生产部署架构

完整微服务生产部署拓扑

飞翔科技在经历数月的微服务化改造后，CTO 大翔要求架构师白歌输出一份生产部署拓扑图。白歌花了三天时间，将 Nacos、Sentinel、Seata、RocketMQ 以及可观测性组件全部整合进一套拓扑中。

白歌将这张拓扑图贴在团队 Wiki 首页，标注了一句话："任何组件缺失，都可能导致某个维度失控——注册、配置、防护、事务、消息、可观测，六个维度缺一不可。"

Nacos 集群部署

在生产环境中，Nacos 必须高可用部署。白歌采用的方案是 3 节点 + MySQL 集群。

集群架构：

cluster.conf 配置：

# Nacos 集群配置（每个节点上的 cluster.conf 内容一致）
10.0.1.11:8848
10.0.1.12:8848
10.0.1.13:8848

application.properties（生产关键配置）：

# 数据源配置（生产必须外接 MySQL）
spring.datasource.platform=mysql
db.num=1
db.url.0=jdbc:mysql://10.0.1.20:3306/nacos_config?characterEncoding=utf8&connectTimeout=1000&socketTimeout=3000
db.user=nacos
db.password=${NACOS_DB_PASSWORD}

# Nacos 集群模式启动
nacos.core.auth.enabled=true
nacos.core.auth.system.type=nacos

启动命令：

# 生产模式启动（每个节点都执行）
cd nacos/bin
./startup.sh -m cluster

关键：Nacos 3 节点容忍 1 节点故障。2 节点容错为 0——任意 1 节点挂掉即丧失过半仲裁能力，因此生产环境必须至少 3 节点。

客户端连接配置：

spring:
  cloud:
    nacos:
      discovery:
        server-addr: 10.0.1.11:8848,10.0.1.12:8848,10.0.1.13:8848  # 集群地址
        namespace: prod

Seata Server 集群 + Nacos 高可用

Seata TC（Transaction Coordinator，事务协调器）同样是分布式事务的核心，必须高可用部署。

集群架构：

registry.conf：

registry {
  type = "nacos"
  nacos {
    application = "seata-server"
    serverAddr = "10.0.1.11:8848,10.0.1.12:8848,10.0.1.13:8848"
    group = "SEATA_GROUP"
    namespace = "prod"
    cluster = "default"
  }
}
config {
  type = "nacos"
  nacos {
    serverAddr = "10.0.1.11:8848,10.0.1.12:8848,10.0.1.13:8848"
    group = "SEATA_GROUP"
    namespace = "prod"
  }
}

高可用保障机制：

RocketMQ Dledger 集群架构

Dledger 是 RocketMQ 4.5+ 引入的基于 Raft（Raft Consensus Algorithm）协议的自动主从切换方案，替代传统人工主从模式。

Dledger 关键配置（broker.conf）：

enableDLegerCommitLog=true
dLegerGroup=broker-group-01
dLegerPeers=n0-10.0.1.31:40911;n1-10.0.1.32:40911;n2-10.0.1.33:40911
dLegerSelfId=n0

Dledger vs 传统主从：

监控整合方案

SkyWalking 接入 Spring Cloud Alibaba

SkyWalking（Apache SkyWalking）是开源的应用性能管理（APM，Application Performance Monitoring）系统，通过 Java Agent 探针实现零侵入的链路追踪。

Agent 下载与配置：

# 下载 SkyWalking Agent
wget https://dlcdn.apache.org/skywalking/java-agent/9.3.0/apache-skywalking-java-agent-9.3.0.tgz
tar -xzf apache-skywalking-java-agent-9.3.0.tgz -C /opt/

agent.config 关键配置：

# SkyWalking OAP Server 地址
agent.service_name=${spring.application.name}
collector.backend_service=10.0.1.41:11800

# 采样率（生产环境建议 10%~30%）
agent.sample_n_per_3_secs=30

Java 启动参数：

java -javaagent:/opt/skywalking-agent/skywalking-agent.jar \
     -Dskywalking.agent.service_name=order-service \
     -Dskywalking.collector.backend_service=10.0.1.41:11800 \
     -jar order-service.jar

白歌的运维经验：SkyWalking Agent 对 Spring Cloud Alibaba 组件（Nacos、Sentinel、Feign、RocketMQ）的链路采集是自动的——Agent 内置了对 Nacos 客户端、Sentinel、Feign 客户端、RocketMQ 的拦截插件，开发者无需写任何埋点代码。

SkyWalking 拓扑图中可见的调用链：

Gateway → OrderService → UserService（Feign）
                       → StorageService（Feign）
                       → RocketMQ（发送消息）
UserService → RocketMQ（消费消息）

Sentinel Dashboard + Prometheus + Grafana

Sentinel Dashboard 内置了轻量级监控，但在生产环境中白歌推荐接入 Prometheus（指标采集）+ Grafana（可视化）体系。

Sentinel 暴露 Prometheus 指标：

<dependency>
    <groupId>com.alibaba.csp</groupId>
    <artifactId>sentinel-prometheus-metric-exporter</artifactId>
    <version>1.8.6</version>
</dependency>

Prometheus 配置（prometheus.yml）：

scrape_configs:
  - job_name: 'sentinel'
    metrics_path: '/actuator/prometheus'
    static_configs:
      - targets: ['10.0.1.11:8719', '10.0.1.12:8719', '10.0.1.13:8719']

PromQL 查询示例：

Grafana 仪表盘布局建议：

┌───────────────────────────────────────────────────┐
│  第一行：整体概览 QPS / 平均 RT / 错误率 / 熔断状态   │
├───────────────────────┬───────────────────────────┤
│  第二行左：资源级 QPS    │  第二行右：资源级 RT 分布    │
├───────────────────────┼───────────────────────────┤
│  第三行左：限流/熔断趋势  │  第三行右：系统 Load / CPU   │
└───────────────────────┴───────────────────────────┘

关键监控指标速查表

Nacos 监控指标

Sentinel 监控指标

Seata 监控指标

RocketMQ 监控指标

告警规则参考

白歌根据生产经验建立了四级告警体系：

性能调优速查

Nacos 客户端调优

本地缓存调优：

spring:
  cloud:
    nacos:
      discovery:
        naming-load-cache-at-start: true       # 启动时立即加载本地缓存，加速首次调用
      config:
        enable-remote-sync-config: true        # 远程配置同步到本地快照，Nacos 宕机时兜底

白歌的实战经验：飞翔科技在一次 Nacos 集群短暂不可用期间（数据库主从切换），依赖本地快照缓存保证所有服务依然能发现彼此——"本地快照就是你的保险绳。"

Sentinel 调优

QPS 阈值参考（基于 4 核 8G 实例）：

重要：以上是初始建议值，生产环境必须通过压测确定真实阈值。小崔第一次直接把所有接口限流到 QPS=10，导致正常流量也被拒绝——孔蓝在运营群连发 5 条消息催修复。

Seata 调优

UNDO LOG 定期清理：

-- 清理 7 天前的已完成 UNDO LOG
DELETE FROM undo_log
WHERE log_status = 1  -- 1 = 已完成
  AND log_created < DATE_SUB(NOW(), INTERVAL 7 DAY)
LIMIT 1000;  -- 分批删除，避免锁表

警告：UNDO LOG 不会自动清理！飞翔科技曾经因为 undo_log 表膨胀到 50GB 导致数据库磁盘告警——孔蓝半夜被运维电话叫醒后，给白歌下了一个"每周清理"的死命令。

全局事务超时：

@GlobalTransactional(timeoutMills = 300000)  // 5 分钟超时（默认 60s 可能太短）
public void createOrder(Order order) { ... }

RocketMQ Producer / Consumer 调优

Producer 调优：

Consumer 调优：

JVM 通用建议

白歌为各组件制定了 JVM 配置建议：

# 典型 JVM 启动参数示例
java -Xms2g -Xmx4g -XX:+UseG1GC \
     -XX:MaxGCPauseMillis=200 \
     -XX:+HeapDumpOnOutOfMemoryError \
     -XX:HeapDumpPath=/opt/logs/heapdump.hprof \
     -jar order-service.jar

故障排查手册

Nacos 注册失败排查（6 个维度）

小崔某天部署新版本后，订单服务在 Nacos 控制台看不到。白歌带着他按以下维度逐一排查并最终定位。

最常见问题 Top 3：① gRPC 9848 端口未放行（2.x 专属）；② namespace 填名称而非 UUID；③ spring.application.name 未配置。

Sentinel 规则不生效排查（5 个维度）

Sentinel 诊断命令（本地接口）：

# 查看所有已加载的流控规则
curl http://localhost:8719/getRules?type=flow

# 查看某资源的实时 QPS
curl http://localhost:8719/cnode?id=getOrder

# 查看客户端与 Dashboard 的连接状态
curl http://localhost:8719/getDashboardServer

Seata 回滚失败排查（5 个维度）

Seata 错误码对照：

RocketMQ 消息丢失排查（4 个丢失环节）

发送端保障（同步发送 + 重试）：

// Producer 同步发送 + 结果检查
SendResult result = rocketMQTemplate.syncSend("order-topic", message);
if (!result.getSendStatus().equals(SendStatus.SEND_OK)) {
    log.error("消息发送失败: {}", result);
    // 写入本地失败表，定时补偿
    failedMessageMapper.insert(order.getId(), message, result);
}

消息重复消费——幂等性设计方案

RocketMQ 的至少一次（At-Least-Once）语义意味着消息可能被重复消费。白歌为团队设计了三种幂等方案。

方案一：数据库唯一索引去重

-- 在业务表中使用消息 ID 做唯一约束
CREATE TABLE order_event (
    id BIGINT PRIMARY KEY AUTO_INCREMENT,
    msg_id VARCHAR(128) NOT NULL,
    order_id BIGINT NOT NULL,
    status VARCHAR(32),
    UNIQUE KEY uk_msg_id (msg_id)     -- 消息 ID 唯一，重复抛异常
);

@Bean
Consumer<Message<Order>> input() {
    return message -> {
        String msgId = message.getHeaders().get("ROCKET_MQ_MESSAGE_ID");
        try {
            orderEventMapper.insert(msgId, message.getPayload());
        } catch (DuplicateKeyException e) {
            log.warn("消息重复消费，已跳过: {}", msgId);
        }
    };
}

方案二：Redis SETNX（原子性不存在则写入）

String msgKey = "msg:dedup:" + msgId;
Boolean success = redisTemplate.opsForValue()
    .setIfAbsent(msgKey, "1", Duration.ofHours(24));
if (Boolean.FALSE.equals(success)) {
    log.info("消息已处理，跳过");
    return;
}
// 执行业务逻辑...

方案三：消息 ID + 业务状态查重

// 先查业务状态，已处理则跳过
if (orderService.isAlreadyProcessed(orderId)) {
    log.info("订单已处理，跳过: {}", orderId);
    return;
}
orderService.process(order);

故障排查速查表

面试体系化梳理

白歌在帮助团队几位同事准备面试时，系统整理了以下考点。这些内容既是对前面八章的复习提纲，也是面试的高频提问方向。

组件级面试

Nacos

Q1：Nacos 的 AP/CP 双模式是什么意思？各自适用什么场景？

• AP 模式（Distro 协议，默认）：优先保证可用性（Availability）和分区容错性（Partition Tolerance），牺牲强一致性。适用于服务注册与发现——宁可短暂不一致（查到已下线的实例），也不能完全不返回实例。
• CP 模式（Raft 协议）：优先保证一致性（Consistency）和分区容错性，牺牲可用性。适用于配置管理——配置数据的强一致性必须保障，Leader 选举期间短暂不可写。
• 可以在同一个 Nacos 集群中共存：临时实例走 AP，持久化实例和配置走 CP。

Q2：Nacos 1.x 与 2.x 的通信协议有何变化？

Q3：Nacos 的保护阈值是什么？触发后会发生什么？

保护阈值（Protection Threshold）是一个 0-1 之间的浮点数。当健康实例占比低于保护阈值时，Nacos 触发保护模式：不再剔除任何实例（即使是不健康的），同时返回所有实例（健康 + 不健康）给消费者，由消费者自行判断。

为什么需要保护模式？ 防止因网络波动导致大量实例被误剔——比如 10 个实例中 5 个因网络短暂不通被标记不健康，如果此时剔除这 5 个，剩余 5 个直接被流量冲垮，引发雪崩。

Sentinel

Q1：Sentinel 的 Slot Chain（插槽链）用了什么设计模式？核心 Slot 有哪些？

使用责任链模式（Chain of Responsibility Pattern）。每个 Slot 有明确的职责，按固定顺序执行，支持通过 SPI（Service Provider Interface）机制扩展。

核心 Slot 及其职责：

Q2：LeapArray 滑动窗口的底层原理是什么？

LeapArray 是基于环形数组 + 滑动窗口的统计算法。以默认配置（1s 周期 / 2 个窗口）为例：

• 环形数组有 2 个槽位，每个槽位对应 500ms 的时间窗口
• 当前时间通过 currentTimeMillis / 500 % 2 定位当前槽位
• 每 500ms 窗口滑动一次，最旧槽位被重置复用
• 统计时累加所有槽位数据，覆盖最近 1s 的精确窗口

为什么不用简单计数器？ 简单计数器在跨秒边界精度崩溃——前一秒最后 100ms + 后一秒前 100ms 如果都计数，合并计算会翻倍。滑动窗口不存在此问题。

Q3：四种流控效果的区别？

Seata

Q1：AT 模式二阶段的"二阶段"与 XA 的"二阶段"有何本质区别？

关键差异：AT 模式在一阶段就已提交本地事务，锁持有时间远短于 XA。代价是如果二阶段回滚前发生了脏写（其他事务修改了同一行数据），回滚会失败。

Q2：TCC 模式的三大核心问题是什么？如何解决？

Q3：Seata 的全局锁机制如何工作？

全局锁存储在 lock_table 中，键为 row_key（resourceId + tableName + pk）。一阶段提交前 RM 向 TC 申请全局锁：

• 无冲突 → 插入 lock_table 记录，申请成功
• 有冲突 → 等待重试（默认 30 次，间隔 10ms）→ 超时抛 LockConflictException

全局锁的作用是防止多个全局事务并发修改同一行数据导致的脏写问题。事务完成后 RM 通知 TC 释放锁。

RocketMQ

Q1：RocketMQ 事务消息的"半消息"机制是如何工作的？

事务消息分为三个阶段：

1. Producer 发送半消息（Half Message）→ Broker
   半消息对 Consumer 不可见（不会投递）
2. Producer 执行本地事务
   - 成功 → 向 Broker 发送 COMMIT → 半消息变为可见，投递给 Consumer
   - 失败 → 向 Broker 发送 ROLLBACK → 半消息被删除
3. 如果 Broker 未收到二次确认（网络问题/Producer 宕机）→ Broker 发起回查
   → Producer 的 checkLocalTransaction() 返回最终状态

Q2：RocketMQ 如何保证分区顺序消息？

• 生产者端：发送时指定 hashKey（如订单 ID），RocketMQ 按 hashKey 取模将消息路由到固定的 MessageQueue
• Broker 端：同一 MessageQueue 内消息按写入顺序存储（FIFO）
• 消费者端：Consumer 使用有序消费模式（ORDERLY），同一 MessageQueue 同一时刻只被一个线程消费

Q3：RocketMQ 如何保证消息可靠性？

逐层保障：

架构级面试

Q1：Spring Cloud 原生方案 vs Spring Cloud Alibaba 全家桶如何选型？

从四个维度展开分析：

1. 组件功能维度

2. 项目活跃度维度

• Netflix OSS 系列（Eureka、Hystrix、Ribbon）已相继停更或进入维护模式
• Alibaba 系列由阿里巴巴持续维护，双十一核心链路验证，迭代活跃
• Sentinel GitHub Star 数远超 Hystrix

3. 国产化与合规维度

• 全部为中国主导的开源项目（归属 Apache 或阿里巴巴），中文文档完善
• 符合信创（信息技术应用创新）政策导向
• 阿里云 MSE 企业版提供商业兜底支持

4. 生态整合维度

• Alibaba 全家桶内部深度整合：Nacos 同时作为 Sentinel 规则持久化数据源、Seata TC 注册中心、RocketMQ 可选服务发现
• 四个中间件（Nacos + Sentinel + Seata + RocketMQ）覆盖全部 MSA 需求，减少运维组件数量

面试加分回答：如果面试官追问"有没有场景适合继续用 Spring Cloud 原生方案"，可以说："存量系统中，如果已深度定制了 Eureka 的客户端行为、或者团队对 Hystrix 的参数调优非常有经验，迁移成本可能高于收益。但对于新项目或即将重构的系统，Alibaba 方案更全面、更活跃。"

Q2：如何设计一个高可用的微服务治理体系？

从五个维度构建完整方案：

1. 注册中心高可用

Nacos 3 节点集群 + MySQL 集群
  ├── 服务发现：AP 模式（Distro），保证可用性
  ├── 配置管理：CP 模式（Raft），保证一致性
  └── 本地快照：Nacos 宕机时各客户端本地缓存兜底

2. 配置动态刷新

Nacos Config + @RefreshScope
  ├── 配置集中管理 + 版本回滚
  ├── 敏感信息加密（Jasypt / Vault）
  └── 灰度配置：按标签向指定实例推送

3. 熔断降级

Sentinel + Dashboard
  ├── 流控规则：QPS 限流 + 排队等待 + Warm Up 预热
  ├── 熔断降级：慢调用比例 / 异常比例 / 异常数
  ├── 系统保护：Load / CPU / RT 维度自适应保护
  ├── 集群流控：Token Server 统一计数
  └── Feign 整合：降级方法 FallbackFactory

4. 分布式事务

Seata AT 模式（默认）或 TCC（高性能场景）
  ├── undo_log 表 + 全局锁 table
  ├── TC 高可用（Seata Server 集群注册到 Nacos）
  └── 事务日志定期清理（global_table / branch_table / lock_table）

5. 监控告警

SkyWalking（链路追踪）+ Prometheus（指标采集）+ Grafana（可视化）
  ├── 自动采集 Nacos/Sentinel/Feign/RocketMQ 调用链
  ├── Sentinel 指标 PromQL 查询 + Grafana 仪表盘
  └── P0~P3 四级告警：电话 → 短信 → 企业微信 → 静默

Q3：单体迁移微服务的演进路线图

各阶段关键决策：

白歌的忠告：不要一上来就上网格化——大多数公司永远停在服务化阶段就够了。单体→服务化是质的飞跃，服务化→网格化只是运维模式的微调。

场景题

场景1：双十一大促——如何用 Sentinel + RocketMQ 扛住瞬时流量峰值？

问题：双十一零点的流量是平时的 50 倍，如何保证核心下单链路不雪崩？

设计方案：

用户请求
  │
  ▼
Gateway（Sentinel 网关流控）
  │  QPS = 10,000（集群 Token Server 统一计数）
  │  超出 → HTTP 429 "活动太火爆，请稍后再试"
  ▼
下单服务（Sentinel 流控）
  │  QPS = 5,000
  │  排队等待模式（Rate Limiter）
  │  超出 → 返回降级提示
  ▼
下单业务逻辑
  │  ① 校验库存（Redis 缓存预扣）
  │  ② 发送 RocketMQ 事务消息（半消息）
  │  ③ 写订单 DB
  │  ④ 提交事务消息
  ▼
RocketMQ（削峰填谷）
  │  Broker 暂存消息
  │  Consumer 匀速消费（库存真实扣减、积分发放）
  ▼
异步消费者
      ├── 库存服务：真实扣减 DB 库存
      ├── 积分服务：发放积分
      └── 通知服务：发送短信/推送

关键设计点：

场景2：跨机房部署——Nacos 多数据中心 + 就近路由

问题：飞翔科技业务扩展到全国，需要在北京、上海、广州三个数据中心部署微服务。用户如何就近路由？

方案：Nacos 多数据中心就近路由

北京数据中心                 上海数据中心                广州数据中心
┌──────────────┐          ┌──────────────┐          ┌──────────────┐
│ Nacos-1      │◄────────►│ Nacos-2      │◄────────►│ Nacos-3      │
│ (Raft CP)    │  跨机房    │ (Raft CP)    │  跨机房    │ (Raft CP)    │
└──────────────┘  复制     └──────────────┘  复制     └──────────────┘
      │                         │                         │
  服务实例                     服务实例                   服务实例
  cluster: BJ                 cluster: SH               cluster: GZ

配置路由规则（Spring Cloud LoadBalancer）：
  - 北京用户 → 优先路由到 cluster=BJ 的实例
  - 北京实例全挂 → 降级路由到 cluster=SH
  - 心跳就近上报（实例只向本地 Nacos 节点发心跳）

关键配置：

spring:
  cloud:
    nacos:
      discovery:
        server-addr: local-nacos.bj.datacenter:8848  # 就近连接本地 Nacos
        metadata:
          cluster: BJ                                 # 集群标记
        cluster-name: BJ

场景3：分布式事务选型——什么场景用 AT、什么场景用 TCC、什么场景用可靠消息？

白歌画了下面这张决策图：

              ┌── 需要强一致实时回滚？
              │
         ┌────┴────┐
         │  是      │  否（可接受最终一致）
         └────┬────┘          │
              │               ▼
         ┌────┴────┐    使用可靠消息最终一致性
         │ 业务代码  │    （RocketMQ 事务消息）
         │ 能改造？  │    示例：积分发放、通知推送、日志
         └────┬────┘
              │
     ┌────能───┴───不能（或数据库交互复杂）───┐
     │                                      │
     ▼                                      ▼
  TCC 模式                              AT 模式
  示例：金融转账                         示例：电商下单扣库存
  （需要显式冻结/解冻资源）                （基于关系型数据库的微服务）

学习路径与后续进阶

推荐学习顺序

白歌为团队制定的学习路径（同时也是本教程的章节阅读顺序）：

阶段一：概述
  └── 第 1 章：Spring Cloud Alibaba 概述与技术选型
        ├── 理解全家桶定位
        └── 掌握版本体系

阶段二：基础设施
  ├── 第 2 章：Nacos 注册中心（服务发现基础）
  └── 第 3 章：Nacos 配置中心（配置管理基础）

阶段三：稳定性
  ├── 第 4 章：Sentinel 流量控制（流量防护第一道防线）
  └── 第 5 章：Sentinel 降级与熔断（防止级联雪崩）

阶段四：关键能力
  ├── 第 6 章：Seata 分布式事务（数据一致性保障）
  └── 第 7 章：RocketMQ 消息驱动（异步解耦 + 削峰）

阶段五：综合实战
  └── 第 8 章：综合案例：电商微服务全栈实战
        └── 所有组件的整合验证

收尾：最佳实践
  └── 第 14 章：最佳实践与面试考点（本章）
        ├── 生产部署架构
        ├── 监控整合 + 性能调优 + 故障排查
        └── 面试体系化梳理

进阶方向

配套实践项目建议

白歌建议每位读者完成以下三个层次的实践：

Level 1：基础实践（必做）

• [ ] 搭建 Nacos 单机 Server + Spring Boot 服务注册/发现
• [ ] 使用 Nacos Config 实现配置动态刷新
• [ ] 搭建 Sentinel Dashboard + 配置 QPS 流控规则
• [ ] 编写 Seata AT 模式电商下单示例（含 undo_log）

Level 2：进阶实践（推荐）

• [ ] Nacos 3 节点集群 + MySQL 持久化部署
• [ ] Sentinel 集群流控（Token Server 模式）
• [ ] RocketMQ 事务消息 + 订单状态机
• [ ] TCC 模式金融转账示例（冻结→确认→解冻）
• [ ] 全链路压测（JMeter 模拟大促流量 + Sentinel Dashboard 观测）

Level 3：生产级实践（选做）

• [ ] SkyWalking + Prometheus + Grafana 全栈可观测性
• [ ] Nacos + Sentinel + Seata 规则全量持久化到 Nacos
• [ ] 多机房就近路由 + 全链路灰度发布
• [ ] Spring AI Alibaba 大模型接入 + Sentinel 保护
• [ ] Kubernetes 集群部署 + MSE 微服务引擎

本章小结：从生产部署架构到故障排查手册，从性能调优速查到面试体系化梳理，本章将前面八章的知识点整合为可落地的生产实践和面试指南。CTO 大翔看完后对白歌说了一句话："这份文档，值三个架构师的年薪。"

教程完：感谢你学完 Spring Cloud Alibaba 独立教程。这是一个以飞翔科技团队故事串联的微服务全家桶教程，从概述到最佳实践，覆盖了 Nacos、Sentinel、Seata、RocketMQ 四大核心组件的完整学习路径。预祝你在微服务架构的道路上越走越远。

[memory_id: memory_00_8u9RKB0pxBPUy0Bm0zxz0289]