我们如何重建云控制台（在运行它的同时）

欢迎来到我们发布周的第 2 天！

上个月，我们发布了 ClickHouse 云控制台的重大更新，您可以在这里阅读所有相关信息。在这篇文章中，我们想分享我们在从头开始重建云控制台过程中获得的经验和知识。

在 2022 年末，在 ClickHouse 云发布前不久，我们与一家构建名为 Arctype 的 SQL 客户端的初创公司早期阶段的公司联手。收购后，我们最初将 Arctype 的大部分 SQL 客户端和数据库可视化功能迁移到一个新的 ClickHouse 云原生（但仍然是独立的）SQL 控制台中，但我们的愿景始终是更进一步——我们认为，真正的“托管”DBaaS 不应仅仅抽象出基础设施的复杂性，还应为每天与数据打交道的开发人员和分析师提供一流的体验。换句话说，配置 ClickHouse 云服务应该只需要点击几下，并且与此服务（以及其中包含的任何数据）的交互不应要求用户离开云控制台。为了实现这一愿景，我们知道我们需要将旧的 ClickHouse 云控制台和新的 SQL 控制台合并到一个应用程序中。

云平台是一个有趣的难题。您永远无法真正地为一位用户进行设计。虽然可以写很多关于各种用户角色的内容，但为了这篇文章的目的，我们将保持简单。

首先，也是最重要的是，有管理类型的用户，他们需要对所有系统有一个全面的了解，并能够管理其用户的权限和安全访问，以及监控其使用情况和账单信息。这些用户可能每月只在任何给定的云界面上花费 1-5 个小时，但是当他们需要查找信息和完成任务时，速度和易用性是硬性要求。

其次，我们有分析师类型的用户，他们可能会：查看、创建和运行查询；导入和导出大量数据；启动、停止和调整 ClickHouse 服务的大小；并与他人分享他们的发现（查询和可视化）。与管理员用户不同，分析师可能每天在云界面上花费数小时。他们需要一个舒适、可预测的环境来帮助他们沉浸在工作中。

第三，也是最重要的，我们有开发人员。对于开发人员来说，云界面（在这种情况下，特别是云数据库界面）主要充当其数据的真实来源。例如 - 数据是否存在于表(s)中，存储了多少数据量，查询是否已正确优化等等，以及一个创建、修改和监控摄取/消费服务的集中位置。

毋庸置疑，这些用户角色中的每一个都代表着完全不同的使用模式、不同的重点，以及在判断我们假设的新云界面体验的质量时可能不同的标准集。考虑到所有这三个方面来设计东西将是棘手的。

无论何时您在处理复杂的系统和大量的数据，重要的是它不会让您感觉像是在处理复杂的系统和大量的数据。因此，我们知道在美学上，我们需要朝着干净和轻盈的方向发展。UI 框架必须是最小的，仅以情境化的方式提供最重要的信息。我们选择了清晰和一致的方法。可预测性确实是任何成功的用户界面的关键——如果用户知道当他们执行操作时接下来会发生什么，他们将很快信任并欣赏您的应用程序。

如前所述，我们有用户每天在我们的云界面上花费数小时。您投入一天中如此重要部分时间的任何地方都必须是舒适的。舒适性和可定制性是密切相关的，因此我们确保新迭代的 ClickHouse 云以非常模块化的方式设计——这将使我们能够轻松切换颜色以创建多个主题。

这一切在概念上都很棒，但现在我们实际上需要构建这个东西。

在我们朝着商定的愿景前进的道路上有一个小小的障碍；这将要求我们将两个大型代码库合并为一个，但更具挑战性的是，我们的旧云控制台是用 Angular 编写的，而 SQL 控制台则使用 React。换句话说，这两个应用程序是用截然相反的 JS 前端框架（或者更准确地说，是一个框架和一个库）编写的。

经过一番激烈的辩论，我们同意将旧云控制台 Angular 应用程序迁移到 React 是最佳方案。有大量文献比较和对比了两者，并且由于我们对其中一个与另一个的选择对这里的故事并不重要，我们将避免向大家详细介绍辩论过程。然而，足以说明的是，任何熟悉 React 和 Angular 的人都可能会觉得我们的决定是可以理解的（至少）。

无论如何，这意味着实现我们的愿景实际上需要在（至少）旧云控制台代码库上进行心脏直视手术，此外还要构建一个时尚、直观且有主见的端到端用户体验。尽管这听起来很有挑战性，但我们有很高的信心，因此，统一控制台项目诞生了。

我们将在本文稍后详细介绍，但在开始之前，这是我们最终工作流程的粗略概述。我们想要创建一个连接的系统，设计工作从 Figma 开始，与我们的 React 组件库紧密同步，并直接流向我们的云体验。

此时，我们已经同意使用 React 作为我们的 JS 框架和我们的设计愿景，但我们仍然需要决定如何重建云控制台本身。这次我们考虑的是更长远的 2-5 年，并且知道我们将雇用更多的设计师和开发人员，因此我们需要一种方法来确保新员工能够快速入职，同时仍然保持一致并忠实于我们的视觉形象。

在设计新版本的 ClickHouse 云时，我们也在 Figma 中构建我们的设计系统，并且如前所述，可定制性是首要原则，因此我们希望每个值都可以根据主题轻松定制。不仅是颜色，还有字体粗细、边框半径、阴影，一切都是如此。做到这一点的最佳方法是使用设计令牌。设计令牌本质上是变量，它们允许我们为属性分配一个值，例如 global.background.default，并且该值可以根据主题而有所不同。因此，在较浅的主题中，我们可能会看到以下内容

global.background.default: 白色

而在较深的主题中，同一个令牌可能具有不同的值

global.background.default: 黑色

这篇文章实际上并不是关于设计令牌的，因此如果您有兴趣，我们建议观看这个 5 分钟的快速视频，它对它们进行了出色的解释。

我们的目标不是在 Figma 中管理一组设计令牌——我们想要建立一个连接的系统，其中对 Figma 中令牌所做的更改可以向下流经代码并进入产品，而无需开发人员进行任何更新。

经过一些研究，我们选定了一个名为 Tokens Studio 的工具，在其中我们可以通过他们的 Figma 插件存储我们所有的令牌，然后以 JSON 格式导出它们。最近几个月，Tokens Studio 甚至添加了与 Figma 变量的无缝同步，这对于我们维护多个主题的设计师来说，是一个巨大的生活质量改进。

一旦令牌以 JSON 格式导出，我们仍然需要一种方法将它们转换为 CSS，以便它们可以在我们的组件中使用。引入 Amazon Style Dictionary。只需稍作自定义，这个非常灵活的构建系统就将我们的 JSON 文件按主题拆分为包含变量的 CSS 文件，然后可以使用名为 styled-components 的 css-in-js 库将这些文件导入到我们的组件中。

尽管取得了巨大的进展，但这又给我们带来了下一个难题——我们如何构建这些组件，它们在哪里存在？在之前的职位中，我们中的一些人曾亲自参与从头开始构建组件库的团队。虽然这可能是有益的，但在 ClickHouse，我们既没有时间也没有兴趣构建和维护这样一个完整的库。此外，鉴于今天有大量可用的优秀选项，从头开始构建组件库将是疯狂的。

因此，与其重新发明轮子，我们选择使用现有的开源（主要是）无头 React 组件库作为基础组件，然后使用我们的令牌添加样式。在花时间尝试了许多领先选项后，我们选定了 Radix-UI，它提供了全面的组件组合，并且开箱即用地提供了出色的可访问性。

由于我们在 Figma 中的设计系统被称为 Click UI，因此我们的组件库也应该被称为相同的名称是有道理的。我们着手从 Radix 导入组件，并将我们自己的样式和自定义应用于它们。在 ClickHouse，我们血管里流淌着开源的血液，因此 Click UI 从第一天起就将是开源的和内置公开的，这从来都不是问题。

Click UI 现在有超过 40 个组件，并且一直在增长。您可以关注并贡献 https://github.com/ClickHouse/click-ui 或在 https://click-ui.vercel.app/ 查看我们的公共 Storybook 游乐场

我们在开发 Click UI 时发现的一个反复出现的问题是在我们想要嵌入到库中的灵活性和一致性程度之间做出选择。

例如，对于我们的 Select 组件，我们讨论了是公开一个通用接口，该接口可以很好地适用于开发时未知的更多设计，还是公开一个更具限制性的接口，可定制性较差，但可以使 Select 组件更简洁且更易于使用。

用 React 术语来说，这将在以下两个接口之间转换

<Select>
  {children}
</Select>

和

<Select options=[{value: ‘value1’, label: ‘label1’}] />

虽然第一种情况可以轻松适应设计的更改（例如，为每个选项显示一个图标），但它也为更广泛的可能（误）用例打开了大门。

另一方面，第二种替代方案使组件的使用更加容易，并且通过仅传递数据，不允许使用可能破坏设计的样式，从而使整个应用程序更加一致。

这个旅程仍在进行中，因此，我们仍然没有找到完美的平衡。不过，显然，如果您必须为一个非常成熟的应用程序构建一个设计系统，您可能会理所当然地更倾向于一致性和易用性。

为了尝试解决这个问题，我们采用了一种混合方法，其中我们实现了具有灵活接口的内部组件，这些组件可以重复使用以构建具有更具限制性（和更简洁）接口的外部组件。这意味着开发人员可以有效地选择自己的冒险——我们既提供灵活的原语，也提供随时可用的构建块。

从一开始，我们就决定选择 storybook 作为记录和可视化测试我们组件的工具。

Storybook 在演示单个组件并展示如何使用它们的所有属性方面提供了出色的用户体验。它还通过易于设置的 github 集成提供对视觉测试的支持。每次打开新的 PR 时，都会针对现有组件运行一组检查。如果发现新的更改，您可以将新组件的外观与现有组件进行比较，并决定是否接受或拒绝新的更改。

这种方法的局限性在于，随着每个组件的变体数量的增加，检查组件的每种可能组合所需的视觉测试数量呈指数级增长。

我们还选择使用 Vercel，因为它为 Storybook 生成的应用程序提供了非常容易的部署，并为每个打开的新 PR 自动生成预览环境。此功能对于促进设计师和开发人员之间的交互非常有用，前者可以轻松转到生成的链接并检查最新的修改，而无需手动将更改部署在他们的本地机器上。

在这个阶段，我们有大量的设计，并且由于 Click UI，我们预先构建了大量的组件，所以现在所有的事情都是关于将它们组合在一起。

不过，在我们能够打开香槟之前，还有许多关于迁移的艰难决定要做。我们将以什么顺序转换页面？我们将一次性发布新体验还是采取更迭代的方法？为了发布这个版本，我们能承受多久停止开发新功能？

最初，我们计划将迁移分为两个阶段。我们当时假设的第 1 阶段将处理服务级别的功能——主要是因为我们新的以服务为中心的模型为这些页面的迁移指明了非常清晰的方向。关于组织级别页面如何适应此模型，我们仍然有一些悬而未决的问题，因此我们计划在第 2 阶段处理这些问题，以及入职和身份验证。回顾过去，我们找到了概述此计划的原始笔记

我们最终遵循了这个大纲，但有一个明显的例外：最初，我们计划在完成服务级别页面迁移（上面的步骤 #7）后立即切换到新体验。这将意味着暂时维护一个分支体验——类似于旧的控制平面/SQL 控制台划分，只是颠倒了。相反，我们选择完成迁移的两个阶段，然后利用功能标志在几周内逐步向用户推出完全集成的体验。

这个计划也带来了一些挑战

• 全新功能开发——在迁移进行期间，我们尽可能推迟新功能的工作。然而，一些关键功能无法推迟，因此需要在旧的 Angular 和新的 React 应用程序中实现。除了重复工作之外，这意味着完成一些页面迁移感觉就像试图击中移动的目标。
• 两种体验，一个应用程序——由于新的控制台体验实际上是构建在现有旧 SQL 控制台应用程序之上的，因此我们必须同时维护同一应用程序的两个版本，每个版本都具有略微不同的布局、路由机制和主题。随着我们越来越接近完成迁移，在发布测试期间（有时在生产环境中也是如此），旧 SQL 控制台中开始出现越来越多的回归。在两种体验中保持稳定性变得越来越困难。

毫不奇怪，向成千上万的现有用户（其中许多是付费客户）推出全新的体验并非易事。在理想的世界中，我们本可以维护两种体验几个月，并为现有用户提供从旧控制台过渡的选择。然而，主要是由于上述挑战，维护这两个应用程序将不是一个可行的选择——特别是考虑到我们的团队仅由少数工程师组成。换句话说，我们需要相对快速地揭开伤疤，以便团队可以恢复其他重要功能的工作。

在经过大约一个月的私有预览测试和迭代后，我们对新的云控制台感到足够有信心开始在全球范围内推出它。我们的计划是最初推出 20%，然后在 2-3 周内向上递增，直到达到 100%（假设没有出现问题）。不可避免地，一些与 UX 相关的要求使这个计划复杂化

• 组织中的所有用户都应具有相同的体验。这可以使用组织级功能标志轻松解决。

• 属于多个组织的用户应在其所有组织中具有相同的体验。这一个有点棘手，但方便的是，对我们的组织/用户群的粗略分析确定，大约 20% 的组织包含多个组织中的用户。因此，我们从这个细分市场开始推出。

从那时起，几乎一切都按计划进行。我们在 4 月 30 日达到了 100% 的推出率，截至发布时，错误报告的数量仍然相对较低，并且反馈非常积极。同样，我们想借此机会感谢所有花时间向我们提供建设性反馈的人——我们认为这对于我们云控制台体验的持续发展至关重要。

那么，接下来是什么？在接下来的几周内，云控制台中将推出许多令人兴奋的新功能——敬请期待！