TCS声明式云原生数据库

诞生背景

说起 TCS 的云原生数据库，就要先从 TCS 开始讲起。TCS 是腾讯云推出的一款 PaaS 平台产品，可以作为腾讯专有云 TCE 的底座，也可以做为私有化 SaaS 的底座，亦可以作为一款 PaaS 类产品独立输出。在最早的 TCS 版本中，自用的是传统数据库，和其他很多平台一样，需要独占一些机器，资源消耗和灵活度在云原生应用交付场景下不太适用。随着 SaaS 私有化交付的兴起，专有云的工程师亟需一款轻便的数据库“接棒”。研发同学经过充分的技术论证，最终选择了社区热度最高的开源数据库产品 MariaDB ，于是专有云团队自研的第一款大规模使用的容器化 PaaS 服务就此诞生。

坎坷发展

艰难上线：摸石头过河

之前，研发同学对于数据库容器化没有经验，并且只使用过数据库，没有对数据库进行过深入了解。在时间紧和人力有限的压力下，实现了 MariaDB 集群全生命周期管理，支持 x86 和 arm 架构。主要功能涵盖：集群创建、集群删除、集群备份、集群恢复、集群监控、集群告警、水平扩容、垂直扩容。业务可以在几分钟内实现一个 MariaDB 集群的创建和销毁。

为了保障 MariaDB 稳定性，实现故障自愈。针对于常见的23种故障场景，比如 Pod 层面异常、主机层面异常（网络、磁盘）、 AZ 级别异常、极端场景和升级等，进行了多轮测试。

为了保障 Mairadb 性能，进行性能压测 Benchmark ，输出压测报告，提供资源和业务量比例的参照。

将一款数据库容器化以后，能支持快速部署、扩缩容及容灾切换；能屏蔽底层物理资源提升资源利用率；能通过自动化运维提升运维效率。为了能达到生产环境的要求，研发团队在数据库管控层面的建设过程中始终追求严谨，通过脑暴及缜密的测试，将潜在问题尽可能地考虑完整，真正地将容器化的优势发挥出来。与此同时，研发团队针对容器化带来的诸多负面影响也投入了非常大的精力尽可能去优化，尤其针对高可用、数据安全、性能及资源隔离方面结合 TCS 平台能力做了细致性的打磨，力求削减容器化数据库与物理部署数据库之间的差异。经过近半年的持续迭代，终于将容器化的数据库正式上线，开始正式作为元数据库支撑着 TCS 平台内部的各个服务，同时也陆续被 SaaS 产品所采用支持各自的生产业务。

故障频发：各种黑天鹅

尽管在上线前做了一系列准备，实际使用环境中还是暴露出许多意料之外的问题。研发同学之前对于数据库运维没有经验，很多问题都是第一次见到，处理这类问题尤其谨慎和耗时。为了确保数据不丢失，做任何操作之前，都会把数据备份。同时，环境比较多，早期 TCS 底座每套环境使用至少5套 MariaDB 集群，运维工作挑战巨大。

随着越来越多生产业务的深度使用，一系列极端的故障场景和问题也逐渐暴露出来，回顾两个最为严重的故障场景和大家分享我们踩过的坑，以及是如何解决的。

异常删除 PVC

管控的 Operator 会主动检测环境中是否有孤儿 PVC ，如果有孤儿 PVC 则主动删除，目的是在节点迁移或扩容场景下，不让旧的 PVC 影响数据的正确性。但最初未考虑到空洞序号等异常场景，对于孤儿 PVC 的判断逻辑上存在缺陷，导致误删了 PVC ，进而导致该 PVC 对应的节点数据丢失，造成了服务中断。研发团队针对孤儿 PVC 的清除逻辑进行了完整地修复，与此同时针对多主模式下主引导节点的选举逻辑进行了针对性的增强，以确保不会再次造成数据丢失的问题。

节点间异常协商

基于 Galera 方案的多主模式是 TCS 平台默认提供的一种集群模式，集群通过 inactive_check_period、keepalive_period、suspect_timeout 及 inactive_timeout 等参数一步一步探测节点是否已失联，如确认某节点已失联，则关闭该节点对外服务的功能并踢出集群。研发团队为了追求极致的高可用，针对单节点对外服务的逻辑进行了干预，导致在东西向网络异常时出现脑裂的情况。另一方面节点加入集群过程中，也遇到过由于底层网络的不稳定，导致节点之间主键步长协商失败，进而导致客户端插入数据偶现失败的现象。研发团队及时针对人为引入的缺陷进行了快速更正，并针对集群参数的配置开放了可动态配置的入口，以容忍恶劣的 IaaS 层环境，尽可能屏蔽底层环境带来的能力上的差异。

逐渐优化：小步快跑式迭代

总体来说上线初期容器化数据库的可用性非常低，最艰难时，负责私有化和交付同学保障的一半都是 MariaDB 贡献的。不过团队同学最终经过两个版本，30+次参数优化，40+次 bug 回合以及多次小版本推平，在支持管控业务方面，容器化的 MariaDB 最终稳定了。此时时间已经到了2021年12月初，历经几个月深度磨砺，团队成员正准备长舒一口气，打算写写年末总结，整理整理文档准备回家过年的时候，西安的疫情爆发了。毗邻西安的某省也进入疫情防控紧张局势。防疫通，腾讯云参与的， TCS 作为底座的一款 SaaS 服务，需要紧急上线。MariaDB 跟随 TCS 一并上了抗疫的战场。

小试牛刀

首次支持业务

防疫通项目使用 TCS 容器化数据库作为核心 DB ，承载着健康码及核酸采样等关键业务，对数据库的高可用性、稳定性及吞吐能力提出了更高的要求。一系列新的机遇与挑战更是激发了 TCS 团队的战斗欲望，在一个多月的项目支持过程中，因底层基础设施不稳定对数据库服务的可用性造成了一定影响，但经过整个团队的紧密合作，依次克服了各项困难，可喜的看到数据库已稳定运行在生产环境中，整个过程虽有坎坷，但对于 TCS 团队来说，容器化数据库经过这一番考验，看到了迈向成功的曙光，也更明确了前行的方向。

性能瓶颈

由于防疫项目对于应用的并发处理能力有很高的要求，客户聘请专业的压测团队以3:2 的读写比对业务接口进行了压测，压测结果不理想，并发处理能力始终达不到预期要求，并且接口出错的概率也比较高。

通过对比分析看到数据库是整个应用并发能力的瓶颈，研发团队进一步确认，在当前使用的多主模式下数据库已无法通过参数调优大幅度提升并发读写能力，结合业务对于数据库的实际使用场景，团队立即决议将新发布的主从模式回合到客户的目标版本中，准备采用主从模式接受压测。

压测爆表

仅用了不到两天的时间，TCS 研发完成了主从能力回合、防疫通生产环境的升级和多主模式向主从模式的切换。针对主从模式进行了一轮新的压测，压测结果相较于多主模式虽有提升但不明显，团队针对具体压测场景进行了数据库及网络上的参数调优，使得压测结果远超客户预期，顺利通过了压测评审，得到了业务认可。

注明：

多主模式压测：约 1W/s 随机读写。

主从模式优化前压测：约 1W/s 随机读写。

主从模式优化后压测：约 4.5W/s 随机读写，最高 4.9W/s 。

产品思考

稳定

系统稳定性是基础，要从代码编写、配置、系统设计、网络与存储及资源等各个方面全面思考如何分阶段分优先级逐步提升系统稳定性。

性能

系统性能优化不能盲从，必定是以问题为导向，性能优化也需要遵循二八原则，找出主要矛盾，优化主要的性能瓶颈点。性能优化是一个长期持续的过程，需要有具体的有效数据作为支撑。

轻便

系统设计要尽可能将实际需求进行抽象，不可过度设计，同时也尽量减少周边依赖，便于方案切换与系统升级。

易用

数据库是多数应用的基础，日常运维需要相配套的巡检工具，便于在问题发生时准确定位根因并第一时间恢复系统可用。

总结

目前生产环境中 TCS 的控制台、监控以及分布式存储等服务都已运行在容器化 MariaDB 上，同时已顺利支撑了腾讯会议等多个 SaaS 产品的管控业务，并且逐步接受了防疫项目等业务数据的大流量的考验。面对日益复杂的业务场景， TCS 的容器化数据库会持续积累经验，稳步迈向成熟。

最后，除了 MariaDB ，基于 TCS 研发团队的这套声明式 PaaS 平台，我们还支持了一些中间件服务，如 Zookeeper，Consul，Etcd，Kafka，RabbitMQ 等，以及其他数据库产品如 MongoDB，ClickHouse，PG SQL 等。目前 TCS 提供的11款自研声明式 PaaS 服务在 TCE，TCS PaaS 平台和 SaaS 私有化交付中持续演进，发光发热，后续我们会逐个进行介绍和说明。