我们如何重建云控制台（在运行中）

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

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

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

云平台是一个有趣的动物。你永远无法真正为一个用户设计它们。虽然可以写很多关于各种用户角色的内容，但为了这篇博文的需要，我们将保持简单。

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

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

第三，也是最重要的，我们有开发人员。对于开发人员来说，云界面（在本例中，更确切地说是一个云数据库界面）主要用作其数据的真实来源。例如 - 数据是否存储在表中，存储的数据量，查询是否得到正确优化，等等）以及创建、修改和监控摄取/消费服务的集中式位置。

可以肯定地说，每一个用户角色都代表着完全不同的使用模式、不同的重点，以及在评判我们假设的新云界面体验质量时，可能会有不同的标准。设计一个同时满足三者的东西将是一件棘手的事情。

无论何时你处理复杂系统和大量数据，重要的是它不能感觉像你正在处理复杂系统和大量数据。出于这个原因，我们知道在审美上，我们需要朝着一个干净、轻便的方向发展。UI 镀铬必须是最小的，以上下文方式提供最必要的信息。我们选择在我们的方法中保持清晰和一致。可预测性确实是任何成功用户界面的关键——如果用户知道他们在执行操作时将会发生什么，他们将很快信任和欣赏您的应用程序。

如前所述，我们有一些用户每天在我们的云界面中花费数小时。任何你投入如此大量时间的地方都必须舒适。舒适性和可定制性是相辅相成的，所以我们确保 ClickHouse Cloud 的新版本设计得非常模块化——能够让我们轻松地切换颜色以创建多个主题。

所有这些在概念上都很棒，但现在我们实际上需要构建这该死的东西。

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

经过一些热烈的辩论，我们一致认为，将传统的云控制台 Angular 应用程序迁移到 React 是最好的行动方案。有很多文献比较和对比这两个框架，因为我们选择一个而不是另一个对这里的故事并不重要，所以我们将省去每个人对辩论的逐字逐句分析。不过，可以肯定地说，任何熟悉 React 和 Angular 的人都可能会觉得我们的决定是可以理解的（至少）。

无论如何，这意味着实现我们的愿景实际上需要对（至少）传统的云控制台代码库进行心脏手术，以及构建一个时尚、直观且有见地的端到端用户体验。虽然这听起来很有挑战，但我们很有信心，就这样，统一控制台项目诞生了。

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

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

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

global.background.default: white

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

global.background.default: black

这篇文章并非真正关于设计令牌，如果您感兴趣，我们建议您观看这段简短的 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 关注并贡献，或者查看我们的公共 Storybook 游乐场https://click-ui.vercel.app/

我们在开发 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 阶段与 onboarding 和身份验证一起处理这些问题。回顾过去，我们发现了最初记录这个计划的笔记

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

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

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

不出所料，向数万现有用户推出全新的体验——其中许多是付费客户——并非易事。在理想情况下，我们会保留两种体验几个月，并为现有用户提供从传统控制台过渡的选项。然而，主要是因为上述挑战，维护这两个应用程序将不再是可行的选择——特别是考虑到我们团队只有少数工程师。换句话说，我们需要快速地撕掉绷带，以便团队能够恢复其他重要功能的工作。

在私人预览期间经过大约一个月的测试和迭代，我们对新的云控制台充满信心，可以开始在全球范围内推出它。我们的计划是最初推出 20%，在接下来的 2-3 周内逐步增加，直到达到 100%（假设没有出现问题）。不可避免地，一些与 UX 相关的需求使这个计划复杂化了

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

• 属于多个组织的成员应该在所有组织中拥有相同的体验。这个有点棘手，但幸运的是，对我们的组织/用户群进行的初步分析表明，大约 20% 的组织包含属于多个组织的用户。因此，我们从这部分用户开始推出。

从那时起，几乎一切都按计划进行。我们在 4 月 30 日达到了 100% 的推出率，截至发稿时，错误报告的数量仍然相对较低，反馈意见也压倒性地正面。同样，我们想借此机会感谢所有花时间向我们提供建设性反馈的人——我们认为这是我们不断改进云控制台体验的关键。

那么，下一步是什么？在接下来的几周内，云控制台将推出许多激动人心的新功能——敬请期待！