---
url: /zh/migrate/platform.md
description: 9.x 的平台服务（补偿服务、视图存储和数据集注册中心）在 V10 中的去向，以及怎样迁移每一个。
---

# 平台服务

9.x 在框架之外附带了三个服务：补偿服务、视图存储和数据集注册中心。V10 保留了视图存储，用 ops 服务取代补偿服务，用分析目录取代数据集注册中心。本页说明每个服务有什么变化，以及怎样迁移它。每项能力的去向见 [V10 中的 9.x 能力](./capabilities)。

| 9.x | V10 | 数据由谁迁移 |
| --- | --- | --- |
| 补偿服务 | ops 服务与控制台，基于每个服务的失败台账 | `migrate-data`，随每个服务的历史一起 |
| 视图存储 | V10 视图存储 | `migrate-data`，像任何服务的历史一样 |
| 数据集注册中心 | 分析目录（孵化中） | 重新定义，不迁移 |

## 补偿服务 → ops 服务 {#compensation-service-→-ops-service}

在 9.x 中，失败的处理由补偿服务记录，由它重试，并允许运维人员跳过。在 V10 中，什么都不会被跳过，也没有东西离开服务：一再失败的处理函数把它的聚合停放在服务自己的失败台账里，与它的检查点放在一起，停放的聚合会在更长的周期内重试。ops 服务汇集每个服务的台账，运维人员在它的控制台里查看停放的聚合，并恢复或跳过它们（[ops 服务与控制台](../operate/ops-console)）。

迁移步骤：

1. 部署 ops 服务，并把每个 V10 服务接到它上面。
2. 迁移每个服务的数据时，把 9.x 补偿服务的数据库交给 `migrate-data`。它把每个未解决的执行（`FAILED` 或 `PREPARED`）导入为所映射的 V10 订阅中的一个停放的聚合，从失败的版本开始，带着它的重试状态（[迁移数据](./data)）。
3. 与 9.x 应用一起停止 9.x 补偿服务：在默认的离线方式中，在导入之前停止；在在线方式中，在最后一次遍历之前停止。

切换之后，重试由 V10 服务负责。原来通知团队 9.x 失败的 webhook，改用 ops 服务的 webhook，它在聚合停放或用尽重试时通知团队。

## 视图存储 → V10 视图存储 {#view-store-→-v10-view-store}

视图存储保存视图引擎保存的视图和仪表盘，它被保留下来，并基于 V10 重写。它和其他服务一样是一个 Wow 服务，所以它的数据也以同样的方式迁移：`migrate-data` 把 9.x 的视图历史导入它的日志。

V10 视图存储按原样读取这些历史：

* 9.x 没有在视图上记录 `kind`；`ViewCreated` 和 `ViewSaved` 的修订号 2 记录了它。升级函数从 9.x 视图的配置中取得 kind，配置中没有 kind 的 9.x 视图会读取失败，并指出是哪个视图（[演进事件](../guide/event-evolution)展示了这个升级）。
* 9.x 把视图移到另一个受众（即转移所有者）的操作，保留为一个只存在于历史中的事件 `ViewAudienceChanged`：视图仍会带着它的受众和所有者加载，而没有任何 V10 命令会再产生这个事件。

视图引擎及其客户端通过 V10 视图存储的 V10 路由与它通信。

## 数据集注册中心 → 分析目录 {#dataset-registry-→-analytics-catalog}

9.x 的数据集注册中心为分析服务描述数据集。在 V10 中，分析的控制面是分析目录：它把数仓的表当作来源（ClickHouse Sink 保存的表由它在 `wow_catalog` 中的那一行描述），在来源之上把数据集定义为宽表，并把每个版本发布为一个 ClickHouse 视图，每个服务节点都在 `/wow/dataset/<context>/<name>/query` 下提供它。数据集的行带上调用方的作用域，每一列的脱敏遵循它的来源。

分析目录还在孵化中，尚未作为发布制品发布。9.x 的数据集定义不迁移：数据集要在 V10 数仓之上重新定义，因为它的表与 9.x 的不同。服务也可以不借助分析目录，在 `META-INF/wow/dataset/` 中声明基于它自己的表的数据集（[ClickHouse](../operate/clickhouse#datasets)）。