十年再出发：回顾我与 TiDB 的成长之旅

唐刘

走到今天，我们逐渐开始认真思考：

“数据库的本质到底是什么？”

答案其实很简单：
1.数据库不需要很多 fancy 的功能；
2.最重要的是能方便、稳定、安全地帮助客户处理好他们的数据。

这个认知彻底改变了我们后续的开发策略，TiDB 越来越成为一个真正面向客户场景的数据库产品。

唐刘

回顾这段历程，我们从混乱无序，逐渐走向了清晰的产品驱动和客户成功驱动。

这个转型虽然漫长而痛苦，但最终我们看到了曙光，真正学会了：
1.PM 的重要性；
2.质量第一的原则；
3.“小步快跑”到“云时代”的灵活发布策略；
4.以及数据库本质的重新思考。

唐刘

六：TiDB Cloud，那段辛酸又收获颇丰的云旅程
TiDB Cloud 的故事说起来挺长的。坦白说，这几年做 TiDB Cloud，真的是走了不少弯路。

最初我们对“云”的理解实在太简单了：

“不就是把 TiDB 数据库放到云上跑起来嘛，这有什么难的？”

结果现实狠狠地教训了我们一次又一次，才终于明白： “云数据库”绝对不是简单地把数据库搬到云上这么简单。

这就像是刚接触 Kubernetes（K8s）时，我们觉得：“不就是写个 YAML 文件部署一下嘛？” 但真上了生产环境才发现，事情比我们想象得复杂百倍。

唐刘

在很早（2018年），我们就决定把 TiDB Cloud 构建在 Kubernetes 之上。当时 AWS 还没有成熟的EKS 服务，我们居然天真地选择了一个叫 Gardener 的开源项目自己运维 K8s 集群。

这一决定后来变成了我们巨大的噩梦：
1.Gardener稳定性奇差，维护成本爆炸；
2.我们甚至有专门的工程师每天被折磨得痛不欲生；
3.后来花了整整数年，才成功从 Gardener 迁移到云厂商托管的 EKS 集群。

这次教训深刻提醒我们：

“云时代，要充分相信云厂商的进化速度。”

唐刘

更严重的错误是我们早期过于固执于本地磁盘：
1.觉得本地盘性能好，死活不肯用云盘；
2.为了让 K8s 支持本地盘的调度，花了无数精力；
3.结果后面发现，云盘性能突飞猛进，而本地盘运维实在复杂得吓人。

客户增长后，光本地盘的运维成本，就能把我们活活折磨死。

现在回头再看，我们早期的坚持真的是：

“程序员的完美主义，碰到了云时代的现实，结果就是狠狠地被现实揍了一顿。”

唐刘

做传统的软件公司，我们只管把软件交付给客户，运维是客户的事。

但云服务不同，客户买的就是服务。
1.SLA 得管好；
2.运维窗口得规划好；
3.安全合规问题一个不能落；
4.客户一旦出问题，我们得随时顶上。

做了云服务之后，我才真正体会到：

“能做好服务运维，比写个好软件难上十倍。”

但也正是这种痛苦的磨练，让我们逐渐成长为一个真正具备云服务意识的团队。

唐刘

TiDB 最初架构是 Shared Nothing（共享无物），非常适合 IDC 时代，但在云时代却逐渐暴露了问题：
1.节点挂了就得重新调度数据；
2.存储容量扩容依赖物理节点，扩容成本极高。

于是，我们开始大规模转型：
1.将TiDB的数据存储从云盘迁移到 S3 对象存储；
2.架构从 Shared Nothing 变成了更弹性的 Shared Everything 架构；
3.进一步服务化拆分，真正变成了微服务架构，极大提高了扩展性与灵活性。

唐刘

有人问：“放到 S3 性能不就差了吗？” 答案是：“不会，因为我们在缓存、访问路径等多层面都做了深度优化。”这个有空后面再说。

拆分微服务的最大好处就是资源利用率和灵活度明显提升。比如：
1.可以把一些重 IO 的操作（如 Compaction）独立成服务；
2.客户高负载时弹性扩展，低负载时迅速回收资源，云成本下降显著。

转型之后，我们终于真正在云时代找到了正确的打开方式。

唐刘

回顾 TiDB Cloud 这段旅程，实在是一把辛酸泪，但也充满了收获：
1.早期对云的误解，让我们交了不少学费；
2.从 K8s、磁盘选择，到微服务架构，每一次的踩坑，都让我们更接近云的真谛；
3.客户运维体系的建立，也让我们真正成长为一个云服务导向的团队。

如今，TiDB Cloud 已经占了公司超过一半的营收。这说明了什么？ 说明了云不只是未来，更是现在。

尽管过程艰难，但我们终于找到了属于 TiDB Cloud 的正确道路。未来，我们相信 TiDB Cloud 还能走得更远。

唐刘

七：全球化之路，程序员的国际化挑战
PingCAP 在真正走到全球市场面前时，我们就发现：

“为什么全球的客户会相信一帮草根做出来的数据库产品？”

毕竟数据库不是一般的软件，客户要把核心数据放进去，简直就是把命运交到你手里。

要建立信任，哪有那么容易？