Skip to content

Latest commit

 

History

History
93 lines (50 loc) · 11.4 KB

behind-tidb-5.0-engineering-system-of-pingcap-1.md

File metadata and controls

93 lines (50 loc) · 11.4 KB
Raw
title author date summary tags
Behind TiDB 5.0 - 聊聊 PingCAP 的工程体系（1）
唐刘
2021-04-19
本文介绍了我们是通过什么样的方式来打造 TiDB 5.0 的。
TiDB

最近，TiDB 终于发布了一个里程碑的版本 - TiDB 5.0。这里，我并不打算过多的聊 TiDB 5.0 架构实现、技术细节，这个大家可以参考 What's New in TiDB 5.0 以及后续的技术文章，我想聊聊其他的东西，也就是我们是通过什么样的方式来打造 TiDB 5.0 的。

首先，我们首先需要承认一个事实，就是开发一款数据库是非常困难的一件事情，我甚至都认为它是世界级别的挑战。在 PingCAP，我们遇到的难度可能比其他数据库厂商更大，包括但不限于：

  • 如何协调全球数百人的研发团队来开发 TiDB？

  • 如何协调社区数百人的贡献者给 TiDB 提交代码？

  • 如何保证 TiDB 在云上，云下都能稳定运行，基于物理机，VM，K8s 等也能稳定运行？

  • 如何让 TiDB 能跟不同数据处理生态（譬如 Flink，Kafka 等）有效集成？

  • 如何让 TiDB 满足全球不同行业，不同的场景？

  • 如何在支持公司商业化工作的同时，保留足够的带宽去研发 5.0？

  • 等等。。。。。。

可以看到，我们有太多的问题要解决，那么我们是如何来处理这些挑战的呢？当然，我们一开始也是没法解决所有的问题的，现在我们仍然面临巨大的挑战，但得力于我们不断迭代并且沉淀下来的一整套工程体系，我们开始慢慢变得游刃有余。这里，我会简单的介绍一下我们到底是怎么做的，当然，看到最后，大家可能会发现，原来我说的东西其实非常的简单，但确确实实会非常的高效。

PMC 和 TiDB TOC

我一直认为，在 PingCAP 做研发是一件难度挑战非常大的事情，因为研发同学会面对外面各种的需求，虽然我们有产品经理，但要平衡好各个业务线的诉求，也是一件很困难的事情。

所以我们在 PingCAP 内部成立了一个产品管理委员会的组织，简称 PMC（Product Management Committee），PMC 里面有产研的同学，也有各个业务线的负责人，大家定期坐在一起开会，用来确定需求的优先级，以及对下一个版本要带上的功能达成一致。虽然这并不是一个最优的解法，但至少能让产研跟业务团队能快速的对齐，不会出现一个版本发布的时候，业务方说『怎么这个需求没做』这样的事情。

PMC 只是 PingCAP 内部用来协调各个部门对产品达成共识的组织，PingCAP 也是 TiDB 这个社区的一份子。所以我们也跟社区的同学一起成立了 TiDB Community TOC(Technical Oversight Committee)。TOC 作为 TiDB 社区技术层面的最高决策机构，在 TOC 里面，会有来自各个 TiDB 社区项目的核心维护者，和来自 PingCAP 的代表，来自其他社区核心贡献企业的代表，定期会交流 TiDB 项目的进展，以及一起讨论一些大的功能是否会进入 TiDB，或者决议一些项目是否能在 TiDB 社区孵化。关于社区合作，如果有机会，我们后面会写一篇更详细的文章来介绍我们是如何打造 TiDB 社区的。

火车发版模型

之前，TiDB 采用的比较传统的一年或者半年发一个大版本的传统，但如果一个版本里面要带的功能太多，然后就出现了软件工程领域最熟悉的事情 - 延期。所以后面我们引入了火车发版模型。

火车发版模型其实就是一种敏捷迭代模型，我们会每隔 2 个月定期发布一个版本，我们会关注发版的节奏和版本的质量，如果一个功能在这个版本里面没有做完，我们仍然会发布这个版本，但会让这个功能顺延到下一个版本里面。这个对于业务方也有一个预期，他们会明确的知道，他们要的某个功能如果已经规划进入到某个版本了，最迟就是等 4 个月，所以业务方会根据这个来控制客户的预期。

有了火车发版模型，大家的工作就完全能迭代展开了，整个迭代流程类似如下：

  1. 每次版本要结束的时候，产品经理就会开始跟业务，研发一起讨论下一个版本要带上的功能，以及评估出来优先级，还有功能需要多少人月来开发。

  2. 产品经理会将所有的输入整理成一个列表，我们内部叫做装箱单，让 PMC 决策，PMC 会一起讨论哪些功能应该在装箱单里面，哪些不应该在，最终会确定好一个装箱单。

  3. 当迭代周期开始之后，研发就开始按照装箱单里面的功能进行开发，每一个功能都有一个 owner，项目经理会每周跟这些 owner 开会来对齐进度。发版经理会跟大家明确好功能的 GA 标准，以及整个版本的 GA 标准。

  4. 当迭代周期进入尾声，发版经理就会开始冻结分支，收回代码权限，这时候大家就进入全面测试阶段（当然，日常开发过程中我们也会进行大量的测试）。

  5. 当分支被冻结后，对于测试发现的 bug，发版经理会每天跟大家进行一次 bug traige，来确定这些 bug 是否应该进入这个版本，还是先不用管。

  6. 每周发版经理会组织大家进行一次 war meeting 会议，来讨论当前版本的状态，以及评估是否能发版，或者是延期。

我们当然希望能正常按时发版，但软件工程你懂的，理想很美好，现实很骨感。不过好在我们就 2 个月的迭代周期，规划的事情比较少，还比较可控，所以通常延期的风险就比较小。另外，上面这个流程我并没有提到如何跟社区合作，将社区的贡献带入到版本里面，这个后面我会介绍。

但我们不会就此满足，2 个月对我们来说就类似于中国的绿皮火车，我们的目标是变成中国的高铁。所以如果你在 DevOps 等方面有丰富的经验，让 TiDB 能够随时高质量发版，欢迎联系我们。

异步工作和 Wiki

作为一家开发分布式数据库的公司，我们自身也在践行全球化的分布式办公，我们的研发团队是分散在不同地点，不同时区的，在这种情况下，基于 IM 的同步工作方式就不起作用了，所以我们在开始探寻更好的异步工作方式。要做到异步工作，一个非常直观的转变就是大家要将自己的工作上下文详细的记录到文档里面，这样其他同学就能快速的了解你的工作。所以我们重度依赖 Google Docs，Jira，GitHub 等工具。

另外，PingCAP 从开始就使用的 Google 全家桶，所以我们的研发文档资料是全部在 Google drive 里面的，但大家也知道，Google drive 其实并不是一个很好的资料管理汇总的工具，但因为我们之前大量的数据已经在这边了，短期也不想迁移，所以为了提升我们使用 Google drive 的效率，以及更好的对我们所有的资料进行管理，我们基于 Google drive 开发了 PingCAP 自己的 Wiki 系统。

有了 Wiki，一个直观的好处就是一方面我们能很方便的继续使用 Google 全家桶，另外，也很好的解决了我们资料共享，协作的问题。后面，等我们梳理好文档的权限之后，我们也会将这个 Wiki 开发给社区，能让社区直接访问任何我们想公开的信息。

当然，鉴于 PingCAP 是一家天生喜欢开源的公司，我们自然也开源了这套 wiki 系统，大家可以访问 https://github.com/pingcap/gdocwiki 了解更多。这套系统并不一定是最高效的，只是现阶段对我们够用了。

防火墙和 resilience

之前，我们的研发工程师会处理太多的事情，不光要写代码，还得去做很多额外的事情，虽然我认为 PingCAP 的工程师是世界顶尖的人才，但一个人无论再怎么厉害，如果让他同时做多件事情，就会类似 CPU 频繁的进行 context switch，看起来很忙碌，但实际效率很低。

所以，我们成立一个了虚拟的防火墙 team，来隔离外部跟研发同学的直接对接。这个 team 每一段时间会有几名同学全职在里面，他们的责任就是最大化的保证其他研发同学不被打扰，能安安心心写代码，所以在这个 team 里面的同学压力会非常的大，他们不光要处理所有转交给研发的客户的线上问题，去会去帮助业务去支持客户的 PoC，甚至去给客户培训等等，虽然大家都是轮值，但一轮下来，真的有时候会累的脱层皮。

为了更好的提升防火墙的效率，我们在之后成立了一个虚实结合的 resilience team，这个 team 不光要做前面防火墙 team 做的事情，还做了更多的事情，包括但不限于分析故障处理记录，提炼产品的改进点，构建用户视图，对重要客户全程跟进，提升客户服务质量等。这也是一个神奇的 team，如果可能，我后面会专门介绍下这个 team 干的有趣的事情。

Bug jail

光有火车发版模型还不够，在上面提到，我们引入这个模型，主要是控制两个点，一个是发版的节奏，另外一个就是产品的质量。要保证高质量，在架构上面要足够简单，写代码要考虑边界异常处理，review 代码要仔细认真，写足够的测试等等。

这里，我跟大家讲讲我们设计的一个小游戏，来提升大家对质量的重视。作为一位研发同学，我其实非常能理解，大家迫切想写代码，开发新功能的意愿，但面对质量问题，一律得停下来。我们在 PingCAP 创建了 bug jail 机制，如果一位同学被分配的要修的 bug 太多，或者某个模块被测出来的 bug 太多，这位同学或者这个模块对应的 team 就会被强制进入 bug jail 里面，在 jail 里面的同学只能修 bug，不能再开发新的功能，除非他们把 bug 给修到某一个阈值以下。

当然，除开 bug jail，我们还做了很多其他工作来保证我们产品的质量，我们也对外输出了很多先进的测试理念，甚至开源了知名的混沌测试平台 ChaosMesh®，后面我也会详细在说说 PingCAP 的质量体系。

写在最后

当然，上面只是大概介绍了一些点，后面我还会介绍的更多，譬如我们的 CICD 系统，我们的 telemetry，dashboard 等，我希望能让大家更好的去理解 PingCAP 的工程体系。

知乎上面有一个帖子，做数据库内核开发的是不是很少，据我所知，至少在中国，这块的人真的是非常少，因为要做一个数据库真的是太难了。对于 TiDB 来说，我们不光有技术上面的挑战，还有开源合作，生态整合，云上云下，全球化，远程办公等，我甚至认为，开发 TiDB 在软件工程领域都是一个值得研究的案例，这也是为啥我想把我们如何来开发 TiDB 的一些基本的东西写下来的原因。

PingCAP 花了整整六年，才有了现在的成果，在未来，我们的挑战会更大，如果你也是那种想挑战世界顶级难度任务的同学，欢迎联系我，我相信，每一次 TiDB 大版本的发布都是一次见证奇迹的过程，未来让我们一起来不断的创造新的奇迹。我的邮箱 tl@pingcap.com，微信 siddontang。