大家好，我是开源多维表格项目 Teable 的创始人陈加贝。
作为飞书多维表格的最早期负责人，我参与并见证了这个产品从 0 到 1 的全过程。这段经历也让我深入理解了企业在数据协作方面的真实需求。
以 Airtable 和 Notion 为代表的电子表格数据库，展现了一个令人兴奋的方向：让不懂代码的业务人员也能搭建自己需要的业务系统。但随着深入，我们发现现有产品都存在难以突破的核心矛盾：性能瓶颈、数据安全和开放能力。
Teable：重新定义多维表格
与市面上其他产品不同，Teable 的核心理念是"数据库平权"。我们观察到，用户对多维表格的期望远不止是一个更强大的电子表格，而是希望它能真正承载核心业务数据和应用。
Teable 的目标是将专业的数据库能力通过无代码界面开放给所有人。我们想要把原本给开发者用的专业数据库，变成让不懂代码的人也能使用的无代码工具。数据库不应该只是技术人员的工具，而是要成为支撑任何团队的业务应用的工具。
这促使我们启动了 Teable 项目。我们的思路很直接：
- 首先，通过开源确保数据完全可控
- 其次，支持百万级数据像呼吸一样自然
- 最后，让数据库保持像表格一样简单易用
这样各行各业的业务人员可以直接在数据库上面轻松搭建像客户管理、项目追踪、订单管理、行业定制数据系统等任意的管理系统，而且还可以轻松的与现有的数据系统和工具进行集成，在搭建好的应用上搭建进一步的自动化数据处理，数据洞察，和第三方应用。
选择开源是我们深思熟虑的结果。我们相信，专业的数据库能力应该触手可及，数据的掌控权应该回到用户手中。非常幸运这个理念得到了广泛认可：在开源后的8个月里，Teable 在几乎零推广的情况下获得了1.3万 Github stars，多次登顶 Github trending。目前用户已遍布100多个国家和地区，并入选 Runa 2024Q2 最具潜力开源项目榜单。
当开发者遇上运维难题
我们是一群程序员，并没有专门的运维工程师。
在项目发展过程中，我们团队面临了一系列技术基础设施方面的挑战。虽然我们在解决技术问题上非常有激情，但是显然我们并不希望把宝贵的时间浪费在处理运维问题上。
手工部署的困境
一开始我们采用了最简单的方案 - 购买服务器自行部署 Docker 容器。我们想着用户也不多，买个服务器用 Docker 起几个容器应该够用了。但很快，问题接踵而至：
- 数据库、对象存储、Redis 等中间件的管理
- SSL 证书更新和 CICD 流程的维护
- 系统稳定性问题 (如内存不足)
- 扩容时的各种技术细节
这些跟业务无关的事情浪费了我们大量时间，比如每个中间件都要单独买，成本比部署应用本身还高。而且经常会遇到内存不够、整个系统 crash 的情况，排查起来特别痛苦。
寻找更好的方案
我们尝试过多种解决方案。
一开始也试过各种大型云厂商 (比如 AWS 等) 的容器服务，但是需要单独部署一套 K8s 集群，维护成本很高，而且配置很复杂，我们根本就搞不定，不知道那么多选项是什么意思。
后来又试过 Railway 这种海外的创新 PaaS 平台，他们的用户体验确实做得很好，但是也有问题，虽然它屏蔽了底层细节，但是并没有为高级玩家提供高级功能的访问入口，比如我想进到容器里去调试，Railway 目前是不支持的。除此之外，Railway 只适合海外使用，国内访问速度较慢，无法满足国内的业务需求。
最终我们海外环境选择了使用 Railway 来部署，但是国内环境还得继续探索。
在寻找国内部署方案的过程中，我们也尝试过自建 K8s 集群。但这个过程让我们深刻体会到了中小团队在运维方面的挑战：
首先是学习成本。K8s 本身就是一个庞大的系统，涉及大量概念和配置项。即使是有经验的开发者，要完全掌握也需要投入大量时间。对于我们这种以产品开发为主的团队来说，这种投入性价比并不高。
其次是维护难度。搭建好集群只是第一步，后续还要处理各种运维问题：
- 节点扩容和缩容
- 监控和告警配置
- 日志收集和分析
最后是稳定性问题。由于缺乏专业运维经验，我们部署的集群经常会出现一些意想不到的问题。比如某次节点突然不可用，排查了很久才发现是磁盘空间不足导致的。这些问题不仅影响了我们的开发效率，也给用户体验带来了负面影响。
作为开发者，我们更希望把精力放在产品本身，而不是基础设施的维护上。我们需要一个既能满足技术需求，又容易维护的方案。
为什么选择 Sealos？
在经历了多次尝试后，我们最终选择了 Sealos 作为国内环境的基础设施方案。
Sealos 的设计理念和我们 Teable 很像，就是把复杂的技术通过简单的界面提供给用户，但又不限制高级用户的发挥空间。
具体来说，Sealos 解决了几个关键问题：
- 统一管理中间件：数据库、Redis、对象存储这些，都是标准的开源组件，不用担心被锁定。而且这些中间件可以一键部署，无需单独购买和维护 K8s 集群。
- 简单易用且收放自如：Sealos 屏蔽了 K8s 的复杂性，提供了直观的操作界面，操作体验简单直观。同时，Sealos 也保留了 K8s 的高级功能，我们可以根据需要进行灵活配置。
- 成本合理：之前单独买云数据库、Redis 的钱，都比部署应用本身还贵。现在我只需要为应用付费，不管是业务应用本身，还是中间件，都是按需付费。
上了 Sealos 之后，因为我们自己原因宕机的事情就没发生过了，现在有锅可以甩给你们了，这是好事哈哈。
从投入产出比来看，Sealos 让我在运维上的时间投入 ROI 变得异常的高，不需要再浪费时间在那些消耗生命的事情上。就算要学一点 K8s，学到的也都是能直接用的，学到就是赚到。
实施历程：从复杂到简单的转变
架构设计理念
在做架构设计时，我们秉持着 less is more 的理念。尽量用最简单的架构来解决复杂的问题。
Teable 的整体架构包含以下几个部分：
- 无状态应用
- 前后端打包在同一个 Docker 镜像中
- 支持横向扩展
- 便于部署和维护
- 核心中间件
- PostgreSQL 数据库 (必需)
- Redis 缓存和消息队列 (可选)
- MinIO 对象存储 (可选)
我们特意设计了降级方案，即使没有 Redis 或对象存储，应用也能运行，只是横向扩展会受限。
标准化部署流程
Sealos 的应用商店是个很棒的功能，它就和 macOS 的应用商店一样，可以一键安装应用，只不过安装的是云上的分布式应用。
借助 Sealos 应用商店，我们实现了高度标准化的部署流程，直接使用 Sealos 提供的应用模板，一键部署应用以及所有中间件依赖，自动完成配置和连接。
Sealos 还为每个用户提供了特定权限的 kubeconfig 文件，我们可以直接使用它来连接到集群，不需要再手动配置。
借助 kubeconfig，我们通过 GitHub Actions 实现了应用的自动化更新，也就是传说中的 CD。核心 Workflow 代码如下：
完整的 Workflow 可以参考：https://github.com/teableio/teable/blob/develop/.github/workflows/manual-preview.yml
以前要花好几天才能搭建的环境，有了 Sealos 之后，现在几分钟就能完成，这样我们就能把更多精力放在产品研发上。
预览环境自动化
既然有了 kubeconfig，预览环境也完全可以自动化了。
和生产环境部署类似，我们基于 Sealos 应用商店提供的 yaml 模板，通过 kubectl apply 创建预览环境，自动分配资源和配置。
Sealos 应用商店所有应用的 yaml 模板可以在这个仓库里找到。
现在，我们的工作流程是这样的：
- 开发提交 PR
- 自动创建预览环境
- 测试、review 都在预览环境进行
- 合并后自动清理资源
我们本来觉得搭建预览环境肯定很复杂，结果只花了一两天时间就搞定了。
你知道这意味着什么吗？每个开发分支都能有独立的测试环境。测试完自动清理，完全不用操心。这种能力，就算有专业运维团队也不一定搞得定。
详情可参考：
展望未来：与 Sealos 共同成长
说实话，我对 Sealos 的未来发展可是充满期待的，有些功能要是能持续迭代改进，那就太棒了。
以下是我对 Sealos 的一些期待：
- 可观测性增强。我们都知道，日志系统就像是应用的 “黑匣子”。要是能有更长的日志保存时间和更强大的搜索功能，那可真是帮了大忙。
- 对象存储优化。对象存储的成本还是有点高，要是能提供一些更便宜的对象存储方案，那就更好了。
- 用户体验提升。我知道 Sealos 为了减小故障域，采用了无主的架构，所有可用区都是自治的，也没有统一的控制台，每个可用区都是独立的域名。但这种架构方案在使用体验上还是有些需要优化的地方，每个可用区的域名都不一样，不容易记住，要是能自动跳转到用户经常访问的可用区就好了。
除此之外，我也很期待 Sealos 海外环境正式上线，这样我们就可以完全统一国内外的部署方案了。
选择合适的云平台和工具，可以帮助团队专注于产品开发，同时获得企业级的稳定性和可靠性。这也是云的价值所在 - 让技术能力的获取变得更加民主化，让每个团队都能构建高质量的应用。
我们期待着与 Sealos 一起成长，共同为开发者提供更好的工具和服务。
共同学习，写下你的评论
评论加载中...
作者其他优质文章
