Teable 通过 Sealos 降低了 80% 的基础设施成本

以 Airtable 和 Notion 为代表的电子表格数据库，展现了一个令人兴奋的方向：让不懂代码的业务人员也能搭建自己需要的业务系统。但随着深入，Teable 团队发现现有产品都存在难以突破的核心矛盾：性能瓶颈、数据安全和开放能力。

与市面上其他产品不同，Teable 的核心理念是 “数据库平权”。该团队观察到，用户对多维表格的期望远不止是一个更强大的电子表格，而是希望它能真正承载核心业务数据和应用。

Teable 的目标是将专业的数据库能力通过无代码界面开放给所有人。他们想要把原本给开发者用的专业数据库，变成让不懂代码的人也能使用的无代码工具。数据库不应该只是技术人员的工具，而是要成为支撑任何团队的业务应用的工具。

这促使他们启动了 Teable 项目。他们的思路很直接：

• 首先，通过开源确保数据完全可控
• 其次，支持百万级数据像呼吸一样自然
• 最后，让数据库保持像表格一样简单易用

这样各行各业的业务人员可以直接在数据库上面轻松搭建像客户管理、项目追踪、订单管理、行业定制数据系统等任意的管理系统，而且还可以轻松的与现有的数据系统和工具进行集成，在搭建好的应用上搭建进一步的自动化数据处理，数据洞察，和第三方应用。

Teable 平台截图：业务人员无需代码即可搭建数据库驱动的管理系统

选择开源是他们深思熟虑的结果。他们相信，专业的数据库能力应该触手可及，数据的掌控权应该回到用户手中。非常幸运这个理念得到了广泛认可：在开源后的 8 个月里，Teable 在几乎零推广的情况下获得了 1.3 万 Github stars，多次登顶 Github trending。目前用户已遍布 100 多个国家和地区，并入选 Runa 2024Q2 最具潜力开源项目榜单。

Teable 入选 Runa Capital 2024年第二季度最具潜力开源初创项目榜单截图。

在项目发展过程中，Teable 团队面临了一系列技术基础设施方面的挑战。他们并不希望把宝贵的时间浪费在处理运维问题上。

手工部署的困境

一开始团队采用了最简单的方案 - 购买服务器自行部署 Docker 容器。他们认为用户也不多，买个服务器用 Docker 起几个容器应该够用了。但很快，问题接踵而至：

• 数据库、对象存储、Redis 等中间件的管理
• SSL 证书更新和 CICD 流程的维护
• 系统稳定性问题 (如内存不足)
• 扩容时的各种技术细节

这些跟业务无关的事情浪费了他们大量时间，比如每个中间件都要单独买，成本比部署应用本身还高。而且经常会遇到内存不够、整个系统 crash 的情况，排查起来特别痛苦。

寻找更好的方案

一开始也试过各种大型云厂商 (比如 AWS 等) 的容器服务，但是需要单独部署一套 K8s 集群，维护成本很高，而且配置很复杂，团队成员根本就搞不定，不知道那么多选项是什么意思。

后来又试过 Railway 这种海外的创新 PaaS 平台，他们的用户体验确实做得很好，但是也有问题，虽然它屏蔽了底层细节，但是并没有为高级玩家提供高级功能的访问入口，比如开发者想进到容器里去调试，Railway 目前是不支持的。除此之外，Railway 只适合海外使用，国内访问速度较慢，无法满足国内的业务需求。

最终Teable 团队在海外环境选择了使用 Railway 来部署，但是国内环境还得继续探索。

在寻找国内部署方案的过程中，他们也尝试过自建 K8s 集群。但这个过程让他们深刻体会到了中小团队在运维方面的挑战：

• 首先是学习成本。K8s 本身就是一个庞大的系统，涉及大量概念和配置项。即使是有经验的开发者，要完全掌握也需要投入大量时间。对于像 Teable 这样以产品开发为主的团队来说，这种投入性价比并不高。

• 其次是维护难度。搭建好集群只是第一步，后续还要处理各种运维问题：

  • 节点扩容和缩容
  • 监控和告警配置
  • 日志收集和分析

• 最后是稳定性问题。由于缺乏专业运维经验，他们部署的集群经常会出现一些意想不到的问题。比如某次节点突然不可用，排查了很久才发现是磁盘空间不足导致的。这些问题不仅影响了他们的开发效率，也给用户体验带来了负面影响。

作为开发者，他们更希望把精力放在产品本身，而不是基础设施的维护上。因此，他们需要一个既能满足技术需求，又容易维护的方案。

在经历了多次尝试后，Teable 团队最终选择了 Sealos 作为其国内环境的基础设施方案。

Sealos 的设计理念和 Teable 很像，就是把复杂的技术通过简单的界面提供给用户，但又不限制高级用户的发挥空间。

具体来说，Sealos 解决了几个关键问题：

• 统一管理中间件：数据库、对象存储这些，都是标准的开源组件，不用担心被锁定。而且这些中间件可以一键部署，无需单独购买和维护 K8s 集群。
• 简单易用且收放自如：Sealos 屏蔽了 K8s 的复杂性，提供了直观的操作界面，操作体验简单直观。同时，Sealos 也保留了 K8s 的高级功能，他们可以根据需要进行灵活配置。
• 成本合理：之前单独买云数据库的钱，都比部署应用本身还贵。现在该团队只需要为应用付费，不管是业务应用本身，还是中间件，都是按需付费。

上了 Sealos 之后，因为自身原因宕机的事情就没发生过了。他们开玩笑说，如果再出问题，终于可以将责任归咎于平台方了。

从投入产出比来看，Sealos 让该团队在运维上的时间投入 ROI 变得异常的高，他们不需要再浪费时间在那些消耗生命的事情上。就算团队成员需要学习一点 K8s，学到的也都是能直接用的知识，学到就是赚到。

架构设计理念

在做架构设计时，Teable 团队秉持着 less is more 的理念。尽量用最简单的架构来解决复杂的问题。

Teable 整体架构设计图

Teable 的整体架构包含以下几个部分：

1. 无状态应用

• 前后端打包在同一个 Docker 镜像中
• 支持横向扩展
• 便于部署和维护

2. 核心中间件

• PostgreSQL 数据库 (必需)
• Redis 缓存和消息队列 (可选)
• MinIO 对象存储 (可选)

Teable 团队特意设计了降级方案，即使没有 Redis 或对象存储，应用也能运行，只是横向扩展会受限。

标准化部署流程

Sealos 的应用商店是个很棒的功能，它就和 macOS 的应用商店一样，可以一键安装应用，只不过安装的是云上的分布式应用。

Sealos 应用商店界面

借助 Sealos 应用商店，Teable 团队实现了高度标准化的部署流程，直接使用 Sealos 提供的应用模板，一键部署应用以及所有中间件依赖，自动完成配置和连接。

使用 Sealos 应用模板一键部署 Teable 应用及其依赖项

Sealos 还为每个用户提供了特定权限的 kubeconfig 文件，Teable 团队可以直接使用它来连接到集群，不需要再手动配置。

Sealos 平台提供用于直接连接集群的特定权限 kubeconfig 文件

借助 kubeconfig，Teable 团队通过 GitHub Actions 实现了应用的自动化更新。核心 Workflow 代码如下：

Teable 使用 GitHub Actions 和 kubeconfig 实现自动化部署 (CD) 的核心 Workflow 代码片段

完整的 Workflow 可以参考：https://github.com/teableio/teable/blob/develop/.github/workflows/manual-preview.yml

以前要花好几天才能搭建的环境，有了 Sealos 之后，现在几分钟就能完成，这样Teable 团队就能把更多精力放在产品研发上。

预览环境自动化

既然有了 kubeconfig，预览环境也完全可以自动化了。

和生产环境部署类似，Teable 团队基于 Sealos 应用商店提供的 yaml 模板，通过 kubectl apply 创建预览环境，自动分配资源和配置。

用于通过 kubectl apply 创建 Teable 预览环境的 Sealos YAML 模板示例代码

Sealos 应用商店所有应用的 yaml 模板可以在这个仓库里找到。

现在，Teable 团队的工作流程是这样的：

1. 开发提交 PR
2. 自动创建预览环境
3. 测试、review 都在预览环境进行
4. 合并后自动清理资源

Teable 团队自动化预览环境工作流程：从提交 PR 到自动创建、测试、合并和清理

他们本来觉得搭建预览环境肯定很复杂，结果只花了一两天时间就搞定了。

你知道这意味着什么吗？每个开发分支都能有独立的测试环境。测试完自动清理，完全不用操心。这种能力，就算有专业运维团队也不一定搞得定。

详情可参考：

• 创建预览环境的 workflow：https://github.com/teableio/teable/blob/develop/.github/workflows/manual-preview.yml
• 预览环境清理的 workflow：https://github.com/teableio/teable/blob/develop/.github/workflows/preview-cleanup.yml