【金仓数据库征文】KFS滚动维护如何降低停机风险：共享存储高可用集群版本升级实录

想你依然心痛2026-07-29 15:42

文章目录

    • 每日一句正能量
    • 摘要
    • [1. 背景与问题](#1. 背景与问题)
      • [1.1 业务背景](#1.1 业务背景)
      • [1.2 滚动维护不等于零停机](#1.2 滚动维护不等于零停机)
      • [1.3 本次演练目标](#1.3 本次演练目标)
    • [2. 环境与数据](#2. 环境与数据)
      • [2.1 脱敏演练环境](#2.1 脱敏演练环境)
      • [2.2 业务探针表](#2.2 业务探针表)
      • [2.3 维护前采集基线](#2.3 维护前采集基线)
    • [3. 复现过程](#3. 复现过程)
      • [3.1 失败方案：双节点同时升级](#3.1 失败方案：双节点同时升级)
      • [3.2 失败方案：未隔离旧活动节点就接管共享盘](#3.2 失败方案：未隔离旧活动节点就接管共享盘)
      • [3.3 失败方案：只验证登录，不验证业务](#3.3 失败方案：只验证登录，不验证业务)
    • [4. 方案实施](#4. 方案实施)
    • [4.1 阶段零：判定是否允许滚动升级](#4.1 阶段零：判定是否允许滚动升级)
    • [4.2 阶段一：冻结变更与建立回退基线](#4.2 阶段一：冻结变更与建立回退基线)
    • [4.3 阶段二：升级非活动节点 B](#4.3 阶段二：升级非活动节点 B)
    • [4.4 阶段三：受控迁移资源到 B](#4.4 阶段三：受控迁移资源到 B)
    • [4.5 阶段四：稳定观察](#4.5 阶段四：稳定观察)
    • [4.6 阶段五：升级原活动节点 A](#4.6 阶段五：升级原活动节点 A)
    • [4.7 阶段六：恢复冗余并做故障注入](#4.7 阶段六：恢复冗余并做故障注入)
      • [演练 A：新备用节点代理异常](#演练 A：新备用节点代理异常)
      • [演练 B：当前活动节点数据库进程退出](#演练 B：当前活动节点数据库进程退出)
      • [演练 C：活动节点失去业务网络](#演练 C：活动节点失去业务网络)
      • [演练 D：FENCE失败模拟](#演练 D：FENCE失败模拟)
      • [演练 E：应用连接池恢复](#演练 E：应用连接池恢复)
    • [4.8 RTO 与 RPO 实测](#4.8 RTO 与 RPO 实测)
    • [5. 结果对比](#5. 结果对比)
      • [5.1 性能回归](#5.1 性能回归)
      • [5.2 业务一致性](#5.2 业务一致性)
    • [6. 风险与复盘](#6. 风险与复盘)
      • [6.1 新旧版本混跑风险](#6.1 新旧版本混跑风险)
      • [6.2 共享存储双访问风险](#6.2 共享存储双访问风险)
      • [6.3 自动故障转移干扰维护](#6.3 自动故障转移干扰维护)
      • [6.4 连接池放大短暂抖动](#6.4 连接池放大短暂抖动)
      • [6.5 回退介质不完整](#6.5 回退介质不完整)
      • [6.6 维护后未恢复冗余](#6.6 维护后未恢复冗余)
    • [7. 滚动维护检查清单](#7. 滚动维护检查清单)
      • [7.1 维护前](#7.1 维护前)
      • [7.2 每个节点升级前](#7.2 每个节点升级前)
      • [7.3 资源迁移时](#7.3 资源迁移时)
      • [7.4 维护后](#7.4 维护后)
    • [8. 总结](#8. 总结)

每日一句正能量

每一天都奔走在自己的热爱里，就是对漫漫人生最好的珍重和回馈。

让每一天的"过程"本身具有价值，而不是把全部意义寄托在未来的某个节点上。如果你今天做的事是你认可的，那今天就没有被浪费。这是对"漫长"最好的回应。

摘要

版本升级最危险的地方，不是执行安装命令，而是把"可回退的维护"做成"不可逆的全停升级"。共享存储高可用集群虽然没有主备日志追平问题，但数据库实例、集群资源、共享盘、VIP、仲裁和应用连接池相互依赖；一旦维护顺序错误，就可能出现共享盘被双节点同时访问、旧节点无法重新入群、应用长时间重连，甚至发生数据文件损坏。

本文以核心交易系统的双节点共享存储集群为背景，设计一次滚动维护演练：先建立基线与备份，在非活动节点完成软件替换和兼容验证，再受控迁移业务资源，升级原活动节点，最后恢复冗余并进行故障注入。文章给出操作步骤、回退点、业务探针、RTO/RPO实测方法和检查清单。核心原则只有一句：每一步都要有明确的进入条件、退出条件和可执行回退动作。

1. 背景与问题

1.1 业务背景

某核心业务系统采用两节点共享存储高可用架构。正常状态下，数据库资源、共享文件系统和业务 VIP 仅在节点 A 上运行；节点 B 处于可接管状态。应用通过 VIP 访问数据库，连接池包含自动重连和健康检查。

text 复制代码 
应用集群
   │
业务 VIP
   │
┌───────────────┐
│ 集群资源管理层 │
└───────┬───────┘
        │
   ┌────┴────┐
   │         │
节点 A      节点 B
活动节点    备用节点
   │         │
   └────┬────┘
        │
共享存储 / 多路径

本次维护包含数据库小版本补丁、集群组件补丁和操作系统安全更新。传统做法是停止整个集群后统一升级，维护窗口预计两小时。业务方只允许分钟级短暂中断，因此需要评估能否采用滚动方式降低停机风险。

1.2 滚动维护不等于零停机

官方高可用资料把节点滚动升级列为计划内维护的高可用手段，并指出数据库小版本、操作系统补丁等维护可将停机控制在数秒至数分钟。但"支持滚动升级"不是无条件承诺，至少要确认以下问题：

  1. 新旧版本是否允许短时间混合运行；
  2. 数据文件格式、系统目录和协议是否兼容；
  3. 集群管理组件与数据库版本是否存在安装顺序要求；
  4. 是否需要一次性执行不可逆升级脚本；
  5. 客户端驱动、备份工具、监控代理是否兼容；
  6. 软件回退是否只需切换二进制，还是必须恢复数据；
  7. 共享盘挂载和资源接管是否具备强制隔离保护。

只要其中一项不支持混跑，就不能机械地套用滚动方案，应改为蓝绿迁移、停机升级或厂商确认的专用升级路径。

1.3 本次演练目标

指标 目标值 测量口径
业务 RTO 不超过 90 秒 从首个失败请求到连续 3 次写入成功
技术 RTO 不超过 45 秒 从资源迁移开始到数据库与 VIP 在线
RPO 0 所有已确认提交的请求均可查询
未知提交请求 必须逐笔核验 以唯一请求号判断成功或失败
回退时长 不超过 10 分钟 从触发回退到旧版本稳定服务
冗余恢复 维护后 30 分钟内 两节点和隔离能力全部恢复

2. 环境与数据

2.1 脱敏演练环境

项目 示例配置
数据库 KingbaseES，旧版本 V_old，目标版本 V_new
集群组件 Clusterware 或项目实际共享存储集群组件
节点 db-a、db-b
共享存储 双控制器 SAN，双路径，多路径软件
文件系统 由集群资源统一挂载，禁止系统自动挂载
访问入口 VIP + 应用连接池
业务负载 订单写入 150 TPS，查询 600 QPS
演练数据 独立批次号与全局唯一请求号

以上均为脱敏示例。实际操作命令、组件名和升级顺序必须以当前版本官方手册和厂商实施方案为准。

2.2 业务探针表

滚动维护不能只看数据库进程是否启动。本文使用唯一请求号持续写入，并记录客户端发起时间和提交结果：

sql 复制代码 
CREATE TABLE maintenance_probe (
    request_id      VARCHAR(64) PRIMARY KEY,
    batch_no        VARCHAR(32) NOT NULL,
    business_no     BIGINT NOT NULL,
    amount          NUMERIC(14,2) NOT NULL,
    client_time     TIMESTAMP NOT NULL,
    server_time     TIMESTAMP DEFAULT CURRENT_TIMESTAMP,
    node_name       VARCHAR(64),
    remark          VARCHAR(200)
);

写入采用幂等语义：同一 request_id 重试时不能生成第二条业务记录。这样可以区分三种状态：

  • 客户端收到成功：属于已确认提交，RPO 必须为零；
  • 客户端明确收到失败：允许重试；
  • 客户端超时或连接断开：属于"提交结果未知"，恢复后必须按请求号查询。

2.3 维护前采集基线

维护前至少采集 30 分钟基线：

  • 请求成功率、平均耗时、P95、P99；
  • 活跃连接数、会话等待、事务数；
  • 数据库进程和集群资源状态；
  • 共享盘挂载点、设备 WWID、多路径状态；
  • CPU、内存、磁盘时延、网络丢包；
  • 备份可恢复性和最近一次恢复演练结果；
  • 软件包校验值、安装目录、配置文件差异；
  • 业务表行数、金额摘要和关键对象状态。

仅有"备份成功"日志不够。升级前必须确认备份介质可访问，并至少验证一次恢复路径。

3. 复现过程

3.1 失败方案：双节点同时升级

为了说明风险，先在测试环境复现一种常见错误：同时停止两个节点、覆盖软件目录、统一执行升级脚本，然后启动集群。结果出现三个问题：

  1. 维护期间业务完全不可用；
  2. 新版本启动失败时，两个节点都失去可用二进制；
  3. 升级脚本修改系统目录后，简单替换旧软件无法回退。

该方案的实际业务 RTO 为 38 分钟，远超目标。更严重的是，回退依赖恢复备份，维护窗口失去确定性。

3.2 失败方案：未隔离旧活动节点就接管共享盘

第二个反例是直接在节点 B 上强制启动资源，而节点 A 仍持有共享文件系统。即使数据库进程看似已经停止，只要旧节点仍有写路径或文件系统缓存未释放，就存在双访问风险。正确顺序必须是：

text 复制代码 
停止业务写入或迁移连接
→ 停止数据库资源
→ 卸载共享文件系统
→ 确认旧节点无写能力
→ 新节点挂载共享盘
→ 启动数据库
→ 启动 VIP
→ 恢复业务

任何"为了缩短几秒"而跳过隔离确认的做法，都可能把短暂停机变成数据恢复事故。

3.3 失败方案：只验证登录，不验证业务

测试中曾出现数据库端口已监听、SELECT 1 成功，但订单写入失败。根因是升级后应用账号默认 Schema、扩展库和自定义函数未完成验证。因此业务恢复标准不能只是"端口通"，至少需要三级探针：

  1. 连接探针：能建立连接并完成身份认证；
  2. 读取探针：能访问关键配置和只读对象；
  3. 写入探针：能提交幂等业务事务并立即读回。

4. 方案实施

4.1 阶段零：判定是否允许滚动升级

在执行任何命令前，组织数据库、操作系统、存储、网络、应用和厂商人员完成兼容评审。形成书面结论：

  • 允许新旧版本在一个维护窗口内混合存在；
  • 目标补丁不改变共享数据文件格式，或提供明确兼容机制；
  • 不需要在第一节点升级时执行不可逆全库脚本；
  • 集群组件、数据库和客户端驱动的支持矩阵已确认；
  • 旧版本安装介质、补丁、配置和许可证均已留存；
  • 回退不依赖临时从互联网下载安装包；
  • 共享盘和 FENCE 能够可靠阻止双节点写入。

若结论不明确，应停止滚动方案，不以生产环境试错。

4.2 阶段一：冻结变更与建立回退基线

维护开始前执行：

  1. 冻结 DDL、配置和发布；
  2. 完成全量备份和归档备份；
  3. 导出数据库、集群、VIP、存储和服务配置；
  4. 记录软件包清单及 SHA 校验值；
  5. 记录数据库对象数量和无效对象；
  6. 执行业务摘要校验；
  7. 持续运行维护探针；
  8. 确认带外管理、FENCE、备用网络可用。

回退点 R0：维护尚未开始。

任何前置检查失败，直接取消维护，不影响在线业务。

4.3 阶段二：升级非活动节点 B

节点 B 不承载数据库资源，因此先在 B 上执行维护：

  1. 在集群层将 B 置为维护模式，禁止自动接管；
  2. 确认共享盘未挂载，VIP 不在 B；
  3. 停止 B 上的集群代理和数据库相关进程；
  4. 备份旧软件目录、配置、服务单元和环境变量；
  5. 安装目标版本或补丁；
  6. 恢复并比对配置，禁止直接覆盖新版本模板；
  7. 启动节点代理但保持业务资源不迁移；
  8. 检查节点加入、仲裁通信、FENCE 和资源定义；
  9. 在隔离数据目录或厂商支持的验证方式下完成二进制自检。

回退点 R1：B 尚未承载业务。

若升级失败，停止新版本服务，恢复旧软件目录与配置，使 B 回到升级前状态。节点 A 继续承载业务，业务 RTO 为零。

4.4 阶段三：受控迁移资源到 B

资源迁移是整个维护中唯一允许出现短暂业务中断的环节。操作顺序：

  1. 通知应用进入维护保护模式，暂停非幂等批任务；
  2. 记录 T0：开始迁移；
  3. 将新写请求短暂排队或快速失败，禁止无限重试；
  4. 在 A 上正常停止数据库，等待事务结束；
  5. 卸载共享文件系统；
  6. 检查 A 无数据库进程、无挂载、无块设备写入；
  7. 必要时执行 FENCE 或资源隔离确认；
  8. 在 B 上挂载共享盘；
  9. 启动数据库并执行恢复；
  10. 完成连接、读取、写入三级探针；
  11. 启动或迁移 VIP；
  12. 刷新应用连接池；
  13. 连续 3 次业务写入成功后记录 T6。

不要把"数据库启动完成"作为 RTO 终点。真正的业务 RTO 应止于业务调用稳定成功。

回退点 R2：资源已迁移到 B，但 A 尚未升级。

若 B 上新版本不能稳定服务，停止 B 数据库、卸载共享盘、确认隔离后，在 A 上重新挂载并启动旧版本。由于 A 尚未改动，这是最重要、成本最低的回退窗口。

4.5 阶段四：稳定观察

在 B 上至少观察一个完整业务高峰或约定时间窗口，检查：

  • 业务成功率和延迟是否恢复基线；
  • 数据库日志是否出现新错误；
  • 共享存储时延和多路径是否异常；
  • 连接池是否持续重连；
  • SQL 执行计划和核心接口性能是否突变；
  • 备份、监控、审计、作业调度是否正常；
  • 已确认提交与未知提交请求是否全部核验。

只有稳定观察通过，才能升级 A。过早修改 A 会丢失最容易的回退路径。

4.6 阶段五：升级原活动节点 A

A 已不承载资源，操作与阶段二类似：

  1. 将 A 置为维护模式；
  2. 确认共享盘未挂载、VIP 不在 A；
  3. 停止代理并备份旧软件；
  4. 安装目标版本；
  5. 恢复配置并进行差异检查；
  6. 启动代理并重新加入集群；
  7. 验证仲裁、资源探测、FENCE、多路径；
  8. 保持 A 作为备用节点，不立即回切。

回退点 R3：两个节点软件均已升级。

此时软件级回退复杂度显著增加。若已执行不可逆数据升级，可能必须使用备份恢复或厂商专用降级方案。因此 R3 之后的回退要求必须在维护前明确，不可临场决定。

4.7 阶段六：恢复冗余并做故障注入

滚动维护成功的标准不是"两个节点版本一致"，而是高可用能力也恢复。至少完成以下演练：

演练 A：新备用节点代理异常

停止 A 上的集群代理，确认 B 上业务不受影响，集群产生告警但不误迁移资源。

演练 B：当前活动节点数据库进程退出

在审批的演练窗口注入数据库进程故障，验证集群能按设计重启或迁移。记录技术 RTO、业务 RTO 和未知提交请求。

演练 C：活动节点失去业务网络

验证 VIP 和业务访问能按策略恢复，同时确认共享盘不会被双节点同时访问。

演练 D：FENCE失败模拟

不得在生产直接破坏隔离设备，可通过测试环境或阻断授权模拟。预期行为应是"停止自动接管并告警"，而不是冒险提升另一节点。

演练 E：应用连接池恢复

确认旧连接能在超时窗口内被清理，新连接访问正确节点；禁止无限重试导致雪崩。

4.8 RTO 与 RPO 实测

建议把时间线拆成以下节点：

时间点 含义
T0 开始迁移或故障注入
T1 旧节点停止接收写入
T2 旧节点完成资源释放
T3 新节点完成共享盘接管
T4 数据库可连接
T5 VIP 与连接池恢复
T6 连续业务写入成功
T7 数据对账完成

计算：

text 复制代码 
技术 RTO = T4 - T0
业务 RTO = T6 - T0
验证完成时间 = T7 - T0

共享存储架构通常不依赖日志复制，因此正常安全切换可实现已确认提交零丢失。但 RPO 不能只写"理论为零"，必须核验：

  • 维护前已确认成功的请求是否全部存在；
  • 未知提交请求是否出现重复；
  • 数量、金额和状态汇总是否一致；
  • 关联流水是否存在孤儿记录；
  • 应用重试是否破坏幂等约束。

5. 结果对比

以下为脱敏演练示例：

指标 全停升级 滚动维护优化后
业务中断 38 分钟 42 秒
技术 RTO 31 分钟 28 秒
业务 RTO 38 分钟 42 秒
已确认提交丢失 0 0
未知提交请求 126 条 7 条，均完成核验
回退难度 需整体恢复 R2 阶段可直接回旧节点
高可用冗余缺失 全窗口 单节点升级期间
维护后故障演练 未执行 5 类演练全部通过

滚动方案的价值并不只是把 38 分钟缩短到 42 秒，更重要的是把风险分散到多个可验证阶段。R1 和 R2 都能在不修改在线数据的情况下快速回退，避免把所有风险集中到一次全停升级中。

5.1 性能回归

升级后核心接口 P95 从 82 ms 变为 86 ms，仍在 10% 容忍范围内；批处理耗时无明显变化。共享存储平均读时延保持在基线范围，未出现路径抖动。

5.2 业务一致性

维护批次共写入 52,860 个唯一请求号：

  • 已确认成功：52,831 条，全部存在；
  • 明确失败：22 条，重试后成功；
  • 结果未知：7 条，其中 5 条已提交、2 条未提交；
  • 重复请求号：0；
  • 金额摘要差异：0；
  • 孤儿流水：0。

由此实测 RPO 为 0。这里的"0"来自业务流水核验，而不是架构宣传口径。

6. 风险与复盘

6.1 新旧版本混跑风险

滚动维护最关键的前提是混跑兼容。若新版写入旧版无法识别的数据格式，资源一旦迁移就无法安全回旧节点。必须在 R2 前确认是否执行过不可逆动作，并在操作手册中用红色标记"最后安全回退点"。

6.2 共享存储双访问风险

共享存储的 RPO 可以很低，但前提是始终只有一个节点持有写资源。任何绕过集群直接手工挂载、系统开机自动挂载或 FENCE 失效，都可能造成严重后果。维护中所有挂载与卸载必须由集群资源管理或经批准的单一流程控制。

6.3 自动故障转移干扰维护

非活动节点升级期间若未进入维护模式，集群可能把正常维护误判为故障并触发接管。维护模式也不能长期遗忘；结束后必须恢复自动保护并验证告警。

6.4 连接池放大短暂抖动

数据库切换仅需二十几秒，但连接池若连接超时为两分钟、失败后无限重试，业务 RTO 会远大于技术 RTO。维护方案要同时调整连接超时、重试间隔、熔断和幂等策略。

6.5 回退介质不完整

只备份数据库数据而不保留旧软件、集群配置、驱动、许可证和服务文件，无法完成快速回退。回退包应离线保存在两个独立位置，并在演练前验证可用性。

6.6 维护后未恢复冗余

很多升级在"业务恢复"后就宣布结束，但备用节点、隔离设备、监控和备份可能仍未恢复。维护关闭条件必须包括：双节点版本一致、资源状态健康、FENCE 可用、业务探针通过、备份成功、故障演练完成。

7. 滚动维护检查清单

7.1 维护前

  • 已确认产品名称、版本、补丁和支持矩阵
  • 已获得新旧版本混跑的正式结论
  • 已识别不可逆升级步骤和最后安全回退点
  • 已完成备份并验证恢复路径
  • 已保存旧软件、配置、许可证和校验值
  • 已确认共享存储双路径和 FENCE 可用
  • 已确认备用管理通道
  • 已冻结 DDL、配置和应用发布
  • 已启动业务探针并采集基线
  • 已明确 RTO、RPO 和终止阈值

7.2 每个节点升级前

  • 节点已进入维护模式
  • 节点不承载数据库、VIP 和共享盘
  • 无残留数据库进程
  • 旧软件和配置已备份
  • 安装包校验值正确
  • 回退命令已准备
  • 有明确操作人、复核人和时间记录人

7.3 资源迁移时

  • 旧节点停止写入
  • 旧节点数据库正常停止
  • 共享文件系统已卸载
  • 旧节点无设备写入能力
  • 新节点挂载状态正确
  • 数据库、VIP 按依赖顺序启动
  • 连接、读取、写入三级探针通过
  • 未知提交请求开始核验
  • 技术 RTO 与业务 RTO 已记录

7.4 维护后

  • 两节点版本和补丁一致
  • 集群资源状态正常
  • 自动故障转移已恢复
  • FENCE、仲裁和多路径验证通过
  • 监控、备份、审计和调度正常
  • 核心 SQL 性能无显著回退
  • 已确认提交无丢失、无重复请求
  • 故障注入演练通过
  • 回退材料继续保留至观察期结束
  • 已完成演练报告和问题闭环

8. 总结

共享存储集群的滚动维护，不是"先升级一台、再升级另一台"这么简单。它是一套受控的风险分段方法：先确认兼容边界，再升级非活动节点；在最安全的 R2 回退点前验证新版本；稳定后才修改原活动节点；最后通过故障注入证明高可用能力真正恢复。

一次合格的滚动维护应同时回答四个问题：

  1. 业务实际中断了多久；
  2. 已确认提交是否零丢失；
  3. 每个阶段失败时如何回退；
  4. 维护结束后集群还能否正确处理下一次故障。

只有把部署步骤、业务探针、RTO/RPO、故障注入和回退点写进同一份操作方案，版本升级才从"经验操作"变成可审计、可复现、可回退的生产工程。

转载自：https://blog.csdn.net/u014727709/article/details/163283350

欢迎 👍点赞✍评论⭐收藏，欢迎指正

相关推荐
想你依然心痛1 天前
【金仓数据库征文】读写分离架构下的一致性边界：复制延迟、路由策略与故障演练实录
读写分离·路由策略·故障注入·金仓数据库·复制延迟·写后读一致性·rto/rpo
爱好曙光21 天前
云原生混沌工程实战：基于Litmus的故障注入与弹性测试
云原生·kubernetes·devops·混沌工程·故障注入·litmus·弹性测试
DarrenHChen_EDA3 个月前
【汽车芯片功能安全分析与故障注入实践 16】Regression and Trend Tracking：把安全分析变成可迭代工程闭环
ci·功能安全·安全指标·故障注入·汽车芯片·fmeda·安全回归
DarrenHChen_EDA3 个月前
【汽车芯片功能安全分析与故障注入实践 19】CI Automation：从手动安全运行到可复现安全回归门禁
功能安全·故障注入·汽车芯片·fmeda·安全证据·residual fit·ci自动化
DarrenHChen_EDA3 个月前
【汽车芯片功能安全分析与故障注入实践 20】发布Demo 包：从 CI 产物到可共享 GitHub Release
功能安全·故障注入·汽车芯片·fmeda·github release
DarrenHChen_EDA3 个月前
【汽车芯片功能安全分析与故障注入实践 18】Dashboard and Website Demo：从安全证据包到可交互工程评审门户
功能安全·故障注入·汽车芯片·fmeda·安全仪表盘·网站演示·工程评审
DarrenHChen_EDA3 个月前
【汽车芯片功能安全分析与故障注入实践 13】FMEDA Update：从 Measured DC 和 Residual FIT 到可追溯安全表格
dc·功能安全·fit·故障注入·汽车芯片·fmeda·measured dc
DarrenHChen_EDA3 个月前
【汽车芯片功能安全分析与故障注入实践 15】安全报告生成：从 Evidence Package 到可评审工程报告
功能安全·安全报告·故障注入·汽车芯片·fmeda
DarrenHChen_EDA3 个月前
【汽车芯片功能安全分析与故障注入实践 14】Safety Evidence Package：从 FMEDA 表到可评审安全证据包
功能安全·故障注入·汽车芯片·fmeda·安全证据·residual fit·traceability
热门推荐
01GitHub 镜像站点02如何新建文件夹？ 电脑新建文件夹的4种方法032026年7月AI圈大地震：GPT-5.6被政府限制、Claude入驻Slack、Anthropic自研芯片04国内可直接用、免费额度/永久免费的大模型API清单（含 SiliconFlow、火山、阿里、智谱、百度、Kimi、DeepSeek、DMXAPI 等）05AI科技热点日报 | 2026年07月01日062026 国产 AI 大模型横评：DeepSeek、通义千问、Kimi、文心一言、星火、豆包谁更能打？07AI 编程 IDE 全景解析 2026：Agent 全面接管开发链路08微信历史版本含下载地址（ Windows PC | 安卓 | MAC ）及设置微信不更新09CC-Switch & Claude 基于 Linux 服务器安装使用指南102026 年 AI 大模型 & AI 编程工具实战全总结