共计 4670 个字符，预计需要花费 12 分钟才能阅读完成。
10 月 18 日~ 20 日，第 12 届中国数据库技术大会（DTCC2021）在北京国际会议中心隆重召开。PingCAP 联结创始人兼 CTO 黄东旭受邀在主会场进行了以“TiDB Cloud：from Product to Platform”为主题的演讲，分享了云原生时代数据库产品平台化的重要性，以及 TiDB 从 DB 到 DBaaS 的教训和领会。以下为分享实录。
在最近数据库行业的倒退中，比起“代码写得好不好”这样的工程技术问题，迷信问题更加突出：有一件事件十分粗浅地扭转了整个数据库的行业，那就是数据库底层产生了变动。
以往大家去思考数据库软件和系统软件，都会先做一个假如：软件是跑在计算机等具体的硬件上的，即便是分布式数据库，每个节点都还是一个一般的计算机。当初这个假如扭转了：咱们的下一代到可能学编程或者写代码的年纪，不会再像咱们当初这样可能看到 CPU、硬盘、网络，他们看到的可能就是 AWS 提供的一个 S3 的 API。其实这种扭转并不仅是软件载体的扭转，更重要的是架构、编程的底层逻辑产生了变动。
云对基础设施和软件的影响和扭转是深远的。具体到 PingCAP 身上，最大的感触就是比起做数据库内核，当初在云上做 TiDB Cloud 服务的投入可能多得多。这也是我明天要分享的主题，From Product to Platform —— 从 DB 到 DBaaS，数据库技术的以后和将来。
PingCAP 的守业初心
上图是我了解的数据库倒退历程。追溯到十几年前，咱们开始应用单机 MySQL，这个期间咱们对数据库的需要只有奢侈的增删改查，2010 年前后直到明天，暴发的数据量让单机数据库难以为继，大家只能通过分库分表或者中间件来实现分布式部署。
然而分库分表对业务的入侵性太大，那能不能有这样一个数据库，用起来和单机 MySQL 一样简略，然而扩容时不须要思考分片，而是通过零碎自身的机制来实现弹性、舒服、业务无入侵的拓展？这就是 PingCAP 守业的初心。
PingCAP 守业六年多以来，为了达成这个小指标，也总结了几点心得：
易用优先：协定大于实现
MySQL 协定比 MySQL 具体软件更重要。如果一款数据库可能兼容 MySQL 协定，能让用户在数据库的选型过程中无需思考对利用和业务的影响，就能领有最大的用户群。咱们无需创造一种新的应用形式，就像电动车还是会通过方向盘和油门来操控，尽管引擎下的世界和汽油车齐全不同。
用户体验优先
数据库的性能指标比方 TPS、QPS 等诚然重要，然而用户的体验才是一款数据库胜利的要害。因而，TiDB 在做所有技术决策的时候都是通过用户体验（Usability matters）来判断。从我过来的教训来看，许多互联网公司须要保护的数据库品种十分多，每启用一种新的数据库就会多一个数据孤岛。因而，在满足用户数据处理需要的同时，简化的技术栈可能才是真正的用户痛点。无论是 OLTP、OLAP 还是 HTAP，TiDB 心愿做的事就是让大家的生存变得好一点。
开源优先
PingCAP 始终保持开源策略，也因而受害颇多。
从生态角度，开源的研发模式可能迅速积攒用户。TiDB 1.0 版本 2017 年 11 月公布，从诞生到当初，咱们晓得名字的用户有 2000 多家，贡献者有 1500 多个，CNCF 开源组织的 Contribution Rank 中，PingCAP 排名寰球第六。
从技术角度，开源减速了产品的迭代速度。这张图的纵轴是代码量，横轴是工夫，不同色块是代表某一年写的代码量。从图中咱们可能看出，基本上每年 TiDB 的代码都在被重写，简直没有一年是跟去年的代码一样。这个迭代的速度就是通过开源社区来实现的，是任何一个团队、任何一个公司、任何一个企业从头开始做一个数据库都无奈达到的进化速度。
Why DBaaS
TiDB 的产品能力不是明天分享的重点，我明天想谈的是把一个产品变成云服务到底有多重要。首先抛出一个最终论断，当初这个时代对 CIO 尤其是海内的客户来说，数据库产品对云的适配成为了一个必选项。
当初咱们正好站在时代的接壤点上。从技术上来讲，数据库的倒退就是从 Standalone（单机）到 Cloud-Native（云原生）的过程。当初咱们处在第二条红线的地位，就是从 Shared-Nothing 到 Cloud-Native 的边界。从商业角度看，整个数据库和根底软件行业的商业模式也正在产生特地大的变动：过来咱们心愿通过售卖 license 进行私有化部署，到当初心愿可能实现规模化的扩张，这也正是 On-Prem 到 DBaaS 改革。
作为一家胜利将数据库商业化的公司，MongoDB 走出了一条很有代表性的路线。MongoDB 每年的市值都在翻番，当初曾经达到了 300 多亿美金。从 MongoDB 的财报能够看出，DBaaS 产品 MongoDB Atlas 基本上每年都放弃着超过 100% 的年复合增长率，这就是云服务的价值所在。
TiDB 在云上的平台化之路
最近两年我也从新定义了一下咱们的愿景和使命：全世界的开发者享受到咱们的服务，Anywhere with Any Scale。
想要实现这个指标，从 DB 到 DBaaS 是个必选项。只有云上的服务能力冲破地区的限度，并提供有限的算力。从 DB 到 DBaaS，远不止将底层资源换成云这么简略，须要思考的还有很多。技术上，要实现降本增效、运维自动化、多租户治理，合规上要思考数据安全，商业上，计价模式、商业化策略等都是须要纳入思考的范畴。接下来我将从技术角度谈谈 TiDB 在 DBaaS 过程中付出的致力。
老本节约：拆散的架构设计
云原生技术最终要解决的就是老本的问题。
在过来，TiDB 有一个 TiDB + TiKV 的协解决引擎，计算和存储的边界是十分含糊的，很难解决不同负载率的场景。本地部署的状况下，如果须要减少存储容量，就须要减少存储节点，因为硬件的限度，除了磁盘，CPU 及网络带宽也会同步减少，这就造成了资源的节约，这是所有 Shared-Nothing 的数据库都要面临的问题。
而到了云上，所有就截然不同。比方 AWS 的块存储设备的服务 EBS，特地是 GP3 系列，可能在不同的机器上运行，且达到同样的 IOPS 和 Cost，性能和对云原生的整合都十分好。为了利用 GP3 的个性，咱们是否能够把计算和存储的边界往下移，从原来的 TiKV 到存储，到当初 TiDB、TiKV 的大部分都能够是计算单元，更加灵便。
云带来的老本节约不止于此。云上真正值钱的货色是 CPU，瓶颈会是计算，而不是容量。集群和实例能够基于资源共享池进行优化（Spot instances & Clusters based on shared resource pools）、按需抉择存储服务的类型、对不同类型的 EC2 实例在特定场景组合交付、无服务器计算、弹性的计算资源都将成为可能。
此外，依据我的判断，除了计算存储拆散，网络、内存，甚至 CPU 缓存都会是拆散的。因为对一个应用程序来说，尤其是分布式程序，硬件资源的要求是不一样的。不论是做什么业务，就像做菜一样，手上只有一颗菜必定做不出什么花来，但原材料很多，就能够依照口味去做组合，云带来的就是这样的机会。
安全性
除了老本，云的安全性也是重要课题。TiDB 官网反对的私有云是 AWS 和 GCP。云上网络用户应用的都是本人的 VPC，两头也会有 VPC Peering 买通的环节，咱们看不到用户的数据，但用户能够很高性能地拜访本人的业务，安全性要怎么保障？
图中是 TiDB 的平安体系，云上的平安体系和咱们云下的思考齐全不同。举个特地简略的例子：云下只须要思考 RBAC 数据库外部的权限，但在云上就非常复杂，须要思考从网络到存储一整套的用户健全平安的体系。做好云上平安的关键点是千万不要本人反复创造，因为根本都有安全漏洞。所以咱们当初就是要充分利用云自身提供的一套残缺的平安机制，比方密钥治理和规定等。当然，最好的中央都是这些服务都可能明码标价，只有做出计费模型就好了。
运维自动化
对于 DBaaS 的构建还有一点很重要，其实也和老本无关，就是运维自动化。云是一个规模化的生意，而当初国内数据库生意最麻烦的局部之一就是交付。一个大客户巴不得派二十个人驻场，但这件事件可继续吗？。咱们要实现的就是能够通过 10 集体的交付团队去反对有 1000 个客户的零碎，这是规模化的前提。
这些是 TiDB 本人的云服务技术选型，通过 Kubernetes 实现云上部署，通过 Gardener 进行联邦治理，管控多个 Kubernetes 集群，Pulumi 是一个基础架构即代码的自动化工具。
Kubernetes
要把 TiDB 变成云服务总共分为几步？第一步就是人肉运维全副变成代码。TiDB 要扩容了，不要人肉扩容，零碎本人能不能扩容？TiDB 故障复原，人参加不了，机器能不能参加？咱们把所有 TiDB 的运维全副变成了 Kubernetes Operator，相当于咱们实现了主动运维 TiDB。Kubernetes 可能屏蔽所有云厂商的接口复杂性，每个云厂商都会提供 Kubernetes 服务。
Pulumi
方才说过这些货色的部署、运维、调度的逻辑，如果都是靠人写脚本，一是不稳固，二是不可保护。咱们的理念就是只有可能变成代码的货色就固化下来，千万不要依赖人，包含去开一个服务器，或者去买一个虚拟机，咱们都会把它变成 Pulumi 编程语言的脚本。
Gardener
TiDB 通过 Gardener 的 API 来管控多个不同 Region 里的 Kubernetes 集群，每个 Kubernetes 集群再去划分不同租户的 TiDB 集群，造成一个多云、多区域、多 AZ 的大的零碎。这个架构有一个益处：用户能够在本人应用程序所在的云服务商和天文区域按需启用 TiDB，放弃技术栈的对立。
商业 SLA
SLA 外面要思考的货色也很多，这是 TiDB 要做的且正在做的货色。
TiDB 的海内客户特地多，海内用户对数据库的需要与国内用户有很大不同，跨数据中心是一个刚需。因为当初各国的数据安全需要，数据的传输有了诸多限度，合规的、跨数据中心的能力对数据库来说非常重要。比方面对欧洲的 GDPR 管控，如果能把一部分数据就放在欧洲，不要进去，只有不在管控范畴内的货色能进去，就会省去很多麻烦。置信接下来这个能力对于中国的厂商和客户，包含做出海以及在国内做合规都会变成刚需。
这个性能在云上很容易实现，比方 AWS 自身就是多 AZ、多 Region 的架构，无需思考底层，在另外一个数据中心开几台机器，用户只须要在界面上点一下鼠标数据就过来了，但对于无奈在云端部署的数据库来说，如果要去解决全局的数据分布或者全局 Transaction 和 Local Transaction，须要思考的货色就多得多。
当初 TiDB 就是防患未然，这项性能曾经马上就要公布了。
想要在云上提供服务，技术诚然重要，合规是个前提。云上的生态整合有一个主线，就是跟着数据走，数据的上游、上游和管控是最重要的三个点。TiDB 的上游就是 MySQL、S3 外面的数据文件，上游只须要反对与 Kafka 或其余音讯队列服务的同步即可。在数据的管控层面，在云上尤其是对海内用户来说，比起通过数据库厂商去做整体的管控，更心愿和相似 DataDog、Confluent 这样的平台买通。
最初打个广告，TiDB 在 Q4 会推出对开发者的为期 12 个月的收费体验版，可能疾速部署，默认反对 HTAP 性能，通过容器实现计算隔离，同时具备专用的块存储，大家在云上能够随便应用。咱们的网址是 tidbcloud.com，将来也会反对国内的云，期待大家的体验和反馈。
心愿 PingCAP 可能真正做到：让全世界的开发者享受到咱们的服务，Anywhere with Any Scale。
