作者介绍： 王天宜，TiDB Community 架构师。曾就任于 Fidelity Investment，Softbank Investment，领有丰盛的数据库高可用方案设计教训，对 TiDB、Oracle、PostgreSQL、MySQL 等数据库的高可用架构与数据库生态有深入研究。
现在数据库上云这一话题受到越来越多的关注，数据库作为重要的根底软件，在云原生时代将面临怎么的改革？当数据库遇上云原生，又将碰撞出什么火花？近日，在亚马逊云开发者 Meetup 上，TiDB Community 架构师王天宜分享了 TiDB 与云原生实际开发教训。
本文将 从以下三个方面解读 TiDB Operator 与云原生：
- 什么是云原生数据库；
- 为什么云原生数据库 TiDB 要拥抱 Kubernetes；
- TiDB 在 AWS 上的最佳实际。
什么是云原生数据库
什么是云原生
任何技术的改革，肯定是思维后行的。我认为云原生是一套应用程序在云上运行的方法论。
咱们能够将云原生拆成云和原生两局部，所谓的云，必然是指利用位于云中，而不再是传统的数据中心中。比方云盘中的文件就在云中，而不是存储在本地的硬盘中。对于原生的解读，我认为是生而为云，应用程序从设计之初就须要思考云环境，在云上以最佳姿势运行。
总而言之，云原生就是 充分利用和施展云平台的弹性 + 分布式的劣势，是生在云上，长在云上，用在云上的技术。
云原生的特点
自 2013 年云原生这一概念诞生开始，其定义在不断完善。云原生有以下四个特点：
- 继续交付：大略在十年前就有了麻利开发的概念。麻利开发的目标是要应答用户的需要扭转，做到频繁的公布，疾速的交付。在某些灰度公布，金丝雀公布的场景中，可能要有几个不同的版本同时提供服务。
- 容器化：容器化使咱们的开发、测试、生产环境高度对立，在调研阶段，咱们也能够应用 docker compose 等命令疾速搭建一个调研环境。
- 微服务：微服务是一个独立公布的应用服务，利用之间通过 rest API 进行通信，能够被独立部署、更新、扩容和重启。
- DevOps：DevOps 强调高效地协调开发与运维的关系。通过自动化部署、CI 工具疾速地将利用部署到生产环境中。
云原生的实质就是施展云计算资源池化，平台规模化等技术红利劣势，发明更多业务价值。
什么是云原生数据库
云原生数据库，是一种通过云平台构建、部署和散发的数据库服务。它以 PaaS 的模式进行散发，也常常被叫做 DBaaS。相比于传统数据库，云原生数据库提供了更好的拜访性和可伸缩性。
云原生数据库的特点
- 云原生数据库要有主动容错的机制，做到宕机主动迁徙，故障主动隔离，保障利用的高可用性。这是云原生数据库最根本的特点。
- 云原生数据库要有很好的弹性伸缩能力，能够依据 CPU load，memory 使用率等做到主动伸缩，秒级扩容。
- 针对于弹性伸缩，要有弹性的计费办法，能够按流量领取，按资源领取，也能够是组合的套餐服务，多种定价策略，为用户实现降本增效的指标。
- 云原生数据库应该是易于治理的，提供了很好的告警监控服务，运维操作简单化，由自助运维向主动运维转化。
- 云原生数据库也应该有很好的平安隔离机制。既蕴含了多租户的资源隔离，也包含网络安全隔离。
这所有的个性都是为了用户的极致体验，低学习老本，低运维老本，低价格老本 应用云原生数据库。
为什么说 TiDB 是一款云原生数据库
咱们先来看一下TiDB 的根本架构：
- TiDB Server：负责承受客户端的连贯，执行 SQL 解析和优化，最终生成分布式执行打算。
- TiKV Server 和 TiFlash Server：用来存储数据，TiKV 是行式的存储引擎，TiFlash 是列式的存储引擎。
- PD：整个 TiDB 存储集群的源信息，负责集群的调度操作，是集群的大脑。
存储结点：
- TiKV：提供分布式事务的 key-value 行式存储引擎。
- TiFlash：列式存储引擎，次要是为了剖析类型场景进行减速。
TiDB Cluster 自身就具备高可用性与高度可扩展性，和云原生的概念是十分符合的。
为何拥抱 Kubernetes
Kubernetes 发展史
提到云原生有两个话题是无奈避开的，一个是容器化，另一个是容器编排。TiDB 要以什么样的形式上云呢？这里不得不提 Kubernetes。从 Kubernetes 的发展史来看，Docker 解决了容器化的问题，而 Kubernetes 解决了容器编排的问题：
- 2013 年，Docker 我的项目公布，使得全操作系统的沙盒技术唾手可得；
- 2014 年，Kubernetes 我的项目公布，容器设计模式正式确立；
- 2017 年，Kubernetes 我的项目施行规范确立；
- 2018 年，Kubernetes 曾经成为了云原生的操作系统。
初探 Database × Kubernetes
我在上一家公司已经设计了这样一种架构：底层数据库应用 MariaDB、Galera、Cluster 三主的构造。MariaDB、Galera、Cluster 是一个无状态实例组成的主主复制。下层应用无状态的 ProxySQL 进行 SQL 路由，而后到不同的 MariaDB 中。中间层应用 ZK 做服务注册与发现，管制下层的 ProxySQL 和上层的 MariaDB。那么这样的构造人造就适宜部署在 Kubernetes 上。
起初，咱们对 DataBase 上 Kubernetes 是有所放心的，所以咱们将绝对轻量级的 Proxy 结点放在了 Kubernetes 中，DataBase 层还是放在物理机上治理。为了应答意外的产生，除了 Kubernetes 上部署的 proxy，实体机上也部署了 proxy 结点。所以即使是 Kubernetes 集群产生了全故障，咱们也能轻松的应答这种状况。
积攒了半年多的 Kubernetes 保护教训，咱们决定将一套比拟边缘化的集群放在 Kubernetes 上。自此，既实现了 proxy 上 Kubernetes，又实现了 DataBase 上 Kubernetes。
TiDB 要以什么样的姿势拥抱 Kubernetes
将无状态的 TiDB 结点放到 Kubernetes 上是否适合呢？其实这跟将 proxy 放到 Kubernetes 上的思路是统一的。如果有 TiDB 上 Kubernetes 的打算，那么保护一套这样的 TiDB + Kubernetes 集群应该是应答生疏环境的最佳伎俩，尤其是对容灾的学习以及网络的配置，都是十分有帮忙的。有很多公司在上 Kubernetes 之前是这样应用 TiDB 的。
理解 TiDB 的同学应该晓得，PD 底层是基于 ETCD 实现的。对于 ETCD 有没有什么好的形式上 Kubernetes 呢？因为 ETCD 是一个有状态的服务，可能不适宜裸布在 Kubernetes 上。咱们能够学习业内比拟出名的 etcd-operator 来开发一套 pd-operator。
针对 TiKV 可能还要更简单一些。作为一款数据库产品，存储层上 Kubernetes 肯定要十分谨慎。在上 Kubernetes 之前，咱们能够看一下 TiKV 是如何实现的。
咱们将存储层 TiKV 中的数据拆成一个个的小数据块，这些数据块在 TiKV 中称之为 Region。
为了保障正确性和可用性，每个 region 都对应一个 raft group，通过 raft log 复制实现每个 region 至多有三个正本。能够看到，至多在 TiKV 这一层，是一个有状态的服务，当一个 TiKV 结点挂掉的时候，咱们没有方法简略的应用故障结点的 PV 新建一个 pod。
咱们都晓得，Kubernetes 判断结点故障是基于 Kubelet 服务是否可能失常上报结点状态。试想一下，如果 Kubelet 无奈失常启动，但结点内的容器还是失常运，此时再将 pv 挂到其余的结点上，就会呈现双写的问题。
因而，应用 Operator 治理 TiDB 的状态势在必行。
TiDB 在 AWS 上的最佳实际
为什么抉择 TiDB Operator
什么是 TiDB Operator？简略的说，TiDB Operator 就是 CRD + Controller 的组合。其中 CRD 负责申明式治理，Controller 负责驱动 TiDB cluster 的显示状态向冀望状态转化。比方咱们对 TiDB 的集群定义是 3 个 TiDB 和 3 个 TiKV，因为某些起因，挂掉了一个 TiDB 结点。那么事实状态是 2 个 TiDB 结点，冀望状态是 3 个 TiDB 结点。这个时候能够由 controller 去起一个新的 TiDB 结点。
CRD 中定义了很多 TiDB Cluster 的组件和生态组件的类型。比方对于 TiDB 集群定义了 TiDB Cluster 类型，对于监控定义了 TiDB Monitor 类型，对于 DM 同步组件定义了 DM Cluster 类型。
接下来看一下 TiDB-Operator 是怎么自动化保护 TiDB 集群的。
TiDB-Operator 利用实际
在部署的时候，TiDB Operator 会为每个组件抉择最佳的 Kubernetes 原生对象。PD 实质上是一个 ETCD 的组件，TiDB 是一个无状态的服务，不须要关怀用什么部署最合适，TiDB Operator 曾经帮咱们暗藏了这些信息。PD 是基于 ETCD 开发的，须要做 peer discovery，而 Operator 会打散 TiKV 容器并且主动增加 store-label，把每个容器出自哪个可用区，哪个机房设定好，辅助 PD 实现 region 的高可用拓扑。有了 TiDB Operator，咱们能够将原厂的运维教训通过代码的形式复制流传进来。只须要通过 yaml 格局的申明，就能够在 Kubernetes 上疾速部署一套 TiDB Cluster。当然，仅仅创立是不够的，Operator 也提供了运维的最佳实际。
在降级的时候，咱们给 TiKV 发送一个降级的申请，此时 TiKV 结点须要 shutdown 而后替换指定版本的 image。因为 TiKV 是一个有状态的服务，咱们在 TiKV 结点 shutdown 之前还须要做一些操作。比方调用 PD 接口，将 region leader 从以后的 TiKV 结点驱赶，此时的 TiKV 就不承受读写申请。之后就能够顺利的重建 TiKV 容器，降级 TiKV 到指定的版本。当然，在降级完结后，咱们又要调用 PD 接口将 region leader 迁回，以此往返，滚动降级。
这是一个工作失常的三正本 TiKV 结点，依据 raft 协定，须要半数以上结点存活能力对外提供服务，即最多可能容忍一个结点呈现故障。
当 TiKV 1 的服务不失常，联合 PD 的 store 信息和 Kubernetes 的容器信息，通过一些 probe 的伎俩，咱们能够获知 TiKV 是否是异样的。
那么是不是检测到故障就进行故障转移呢？其实并非如此。故障转移太快可能会因为网络资源或者 CPU 资源的抖动导致频繁的产生切换，故障转移太慢有可能升高集群的高可用性与吞吐。
此时 TiDB Operator 会进行自动化故障转移。什么状况下须要故障转移、距离多久进行故障转移，这些都交给 TiDB Operator 进行判断，至于如何进行故障转移，也交给 TiDB Operator 执行。
当然，在业界也流传了很多的拥护声音，咱们到底要不要在 Kubernetes 上部署 Database，还须要「三思」：
- 思退。咱们不仅要思考如何将实体机上的数据迁到 Kubernetes 上，也要想好进路，当 Kubernete 运维操作过于简单，或者临时因为一些其余起因咱们无奈笼罩太多的技术栈，如何从 Kubernetes 平台上撤下来，Binlog 和 TiCDC 工具是能够帮忙咱们的。
- 思危。多加了一层 Kubernetes 与 Operator 的技术栈，危险点也随之变高。那就意味着咱们要做更多的测试。Kubernetes master 结点挂了，咱们能够仍然对外放弃服务。当然，master 结点自身也是反对 Keepalived + Haproxy 高可用的。Node 结点挂掉了，咱们能够将该结点上的 Pod 迁到其余的 Node 结点上。Kubernetes 全副挂掉了，还有本地保留的 PV 文件。即使是真的灾难性的故障导致了 PV 文件的损坏，咱们还有定期的备份可供复原。
- 思变。Kubernetes 自身是一款为变动而生的平台，在 Kubernetes 上，降级操作、扩缩容，变得更简略了。
除此之外，还请再思考两个问题：
- 你违心置信 Kubernetes 是将来吗？
- 你筹备好了吗？
如果你当初还没有筹备好相干的技术栈，或者你想提前去感触 TiDB 在 Kubernetes 平台上的魅力，感触云原生的魅力，咱们为你提供了基于 AWS 的 DBasS 服务 —— TiDB Cloud。应用 TiDB Cloud，对于用户来说，既能够失去牢靠的数据库服务，又能享受到业余的运维服务，同时也防止了昂扬的学习老本。
用户在 TiDB Cloud 上能够自在的抉择用于计算的 TiDB 结点和用于存储的 TiKV & TiFlash 结点，能够 真正实现按需按量应用，按需按量付款，将云原生的劣势施展到极致，降本增效。
2014 年，Gartner 在一份报告中应用混合事务剖析解决 —— HTAP 一词形容新型的应用程序框架，以突破 OLTP 和 OLAP 之间的隔膜，既能够利用于事务型数据库场景，也能够利用于剖析型数据库场景。
HTAP 可能实现实时业务决策。这种架构具备不言而喻的劣势：岂但防止了繁琐且低廉的 ETL 操作，而且能够更快地对最新数据进行剖析。这种疾速剖析数据的能力将成为将来企业的外围竞争力之一。
有一些用户，每隔固定的工夫可能须要经营人员做一些查问类的剖析。这个时候咱们能够剖析前一天的上一个 TiFlash 结点，将数据从 TiKV 中同步到 TiFlash 结点，以供经营人员在第二天做剖析。因而，在云上弹性扩缩容的个性和 HTAP 的场景天生就是高度匹配的。
以上就是对于 TiDB Operator 与 Amazon Web Service 云原生相干的实践经验，心愿可能对大家有所帮忙。