我们如何在（不停机的情况下）重建云控制台

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

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

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

云平台是一个有趣的野兽。你永远无法真正地只为一个用户设计它们。虽然关于各种用户角色可以写很多东西，但为了这篇文章的目的，我们将保持简单。

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

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

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

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

每当您使用复杂的系统和大量数据时，重要的是它不感觉像您在使用复杂的系统和大量数据。出于这个原因，我们知道在美学上，我们需要朝干净和轻盈的方向发展。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 上关注并贡献，或者在 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% 的推出，并且截至发布之时，错误报告的数量仍然相对较低，并且反馈非常积极。同样，我们想借此机会感谢所有花时间向我们提供建设性反馈的人——我们认为这对于我们云控制台体验的持续发展至关重要。

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