大家好，我是编程小6，很高兴遇见你，有问题可以及时留言哦。

　　摘要：TiDB作为开源分布式关系型数据库，具备良好的扩展性，结合云环境灵活的基础设施，可以充分发挥分布式数据库的优势。至于，为什么TiDB一定要上云？云原生数据库改造之前最大的挑战是什么？平安科技给出的答案是效率、成本和故障自愈需求！那么，在上云过程中，TiDB使用了哪些关键组件？如何在K8S上有效管理TiDB集群？如何充分利用云环境稳定运行TiDB？TiDB上云后如何提供更好的用户体验？本文结合平安科技实际业务环境，具体介绍了开发与应用实践过程！

　　本期分享嘉宾：平安科技资深研发工程师 宋歌

　　简介：平安科技研发工程师，熟悉Kubernetes contributor、TiDB contributor，热爱开源，同时也是《TiDB in action》作者之一。

　　云原生时代，以Kubernetes为代表的编排系统成为新应用的事实标准，甚至被称为是提升开发效率的“杀手锏”级应用，其无状态的弹性伸缩以及自动故障转移能力，无疑实现了生产力的又一次解放。

　　事实上，状态本身从未消失，而是下沉到底层的数据库、对象存储等有状态的应用上。那么，以TiDB为代表的有状态应用，如何在“负重前行”过程中，充分利用云以及Kubernetes的潜力，获得进一步的成功呢？平安科技总结出的关于TiDB与Kubernetes的“爱恨情仇”，或许能为更多企业的云原生实践带来参考和借鉴意义！

　　分布式数据库TiDB技术回顾

　　2018年，平安科技开始使用TiDB；2019年首次完成了线上业务部署。2019年以后，平安科技开始着手实现TiDB的上云。2021年，平安科技推出了UbiSQL云原生分布式数据库。

　　之所以要引入TiDB，主要是为了支持平安集团重大业务活动——平安1.8财神节。在短短10天活动高峰期，TiDB平稳地度过了活动大促。活动中，TiDB表现出卓越的延展性，可以支持快速扩缩容，实现业务峰值的覆盖。

　　众所周知，TiDB是一款开源分布式NewSQL数据库服务，源于谷歌发布的Spanner，支持OLTP和OLAP；同时，TiDB在横向扩展能力上，具有非常强的水平扩展能力，这是天然架构上的优势；TiDB支持分布式事务，高度兼容MySQL5.7协议，是HTAP交易分析混合型应用，适用于海量数据存储、高并发、高吞吐、高增速的业务场景，能使迁移成本降到极低。

　　为什么TiDB需要上云？

　　TiDB为什么要上云？运维成本是最大挑战！

　　当时，集群管理非常多，运维效率难以满足用户的交付时效。而从故障自愈的角度看，传统环境难以实现自动化。比如：当一个服务器挂掉以后，其实服务能力是受损的状态，需要DBA晚上爬起来去看这个问题怎么解决。如果业务晚上有高峰，还要新建一个实例去扩容，这些都需要去手动操作。

　　上云自动化以后，对用户来说最直接的感受就是成本和效率。在传统环境去部署TiDB的时候，比较碎片化，管理成本较高，通过配置脚本做自动化部署，缺少对整个集群状态的维护和自动管理能力，也很难做资源调度，并且资源调度依赖于外部的算法或者框架来做。另外，传统环境很难实现故障自愈、弹性服务；但是上云以后，数据库实例超过一定时间没有响应后，Operator会帮你把新的节点自动拉起来，提供数据库服务故障自愈能力。而从用户应用交付来看，我们原来从准备资源到到交付一套生产集群可能需要数天时间，因为需要申请服务器，还需要规划一些端口；而上云以后的交付时效是分钟级别，这是非常明显的用户体验上的提升。

　　基于上述几点因素，TiDB上云成为最佳选择！

　　在云化过程中，我们用了TiDB Operator这个组件，同时做了一些二次开发，在K8S集群上去交付一套TiDB容器化的集群，可以很好地将资源利用率提高到一个比较高的水平。在传统环境下，需要人工去管理资源，比如：通过粗糙的资源算法去管理，资源利用率比较低；而云化以后，可统一管理资源池，通过K8s编排和调度充分利用主机资源，使主机资源使用率得到大幅提升。同时，云上是使用容器化的方式去部署的，节点失效了以后可以由Controller自动拉起，很好地做到节点的容灾，确保节点在一台主机挂掉以后，在其他节点或者计算层可以维持副本数量。

　　尤为重要的是，TiDB上云把所有的TiDB集群做了集约化管理以后，可以很明显看到规模效应。分布式数据库集群组件很多，节点也很多，管理大量集群的时候，会导致信息管理成本、集群的管理成本、运维成本陡然上升，而把所有的集群进行集中化管理后会产生规模效应。TiDB上云以后，可以有效降低每套集群的边际管理成本。

　　换言之，管理的集群越多，每个节点所需要消耗的技术、人力成本就越少。同时，集约化管理还带来另一个好处，集团各公司用户可以共享技术红利。我们在做代码的提升时，发布了新的功能，比如：快速备份、基于时间点恢复、参数调优等，都可以在云上集约化管理方式下，把技术能力提供给被托管集群，最终效果就是降本增效。

　　如何在云上管理TiDB集群？

　　那么，我们如何在K8S集群上管理TiDB集群呢？大概构建了以下5个核心能力！

　　自动化部署。首先，使用TiDB Operator做了一些二次开发，实现了一些云上自动化的管理能力。比如：自动化交付，让用户在平安云界面上一键点击，创建集群，选择规格、实例，然后选择存储的空间大小，自动在后端创建TiDB集群，交付这个集群。

　　2．滚动升级。TiDB社区版的升级频率非常高，前几年，大概一个半月，就升级一个小版本。所以，在线上，我们也会有一些碎片化的小版本，在做滚动升级的时候， DBA可以在运维时间段，将集群做一个小版本的一个升级，目前可以做到一键滚动升级。

　　3．备份管理。基本做到了全量备份、增量备份、全量恢复、按时间点恢复（PITR）。

　　4. 参数管理。DBA可以在平安云页面上做参数配置，同时这个参数配置可以记录你的参数修改历史，给你一些默认参数；并且，根据不同的套餐给你一些默认的参数。你去修改调整以后，会记录谁什么时候修改的什么东西。并且，还有可以修改参数的时间段，设置控制参数生效规则，比如：不要在业务高峰期调整这个参数，然后由用户在页面上配置。

　　5. 用户管理。目前，主要针对集团内部子公司，对于数据库的用户管理有一些管理规范，结合内部系统的一些建设规范和审批流程，通过审批以后按照规范去创建用户的功能。

　　如何充分利用云环境稳定运行TiDB？

　　第一，容器网络。使用了K8S比较常见的Calico作为网络插件，相比Flannel的好处在于，可以在网络层面通过BGP的方式实现容器网络互连，避免overlay 模型隧道开销。另外，我们还在验证基于自研的K8S网络插件实现静态IP的网络方案。

　　第二，Load Balancer。数据库实例增加后，业务访问的时候就需要一个负载均衡，目前我们使用了K8S的Service 作为它的一个负载均衡；同时，在做灰度升级、滚动升级的时候，利用了负载均衡的标签选择能力，来做流量的控制。

　　第三，Service Discovery。基于DNS实现服务自动发现。所谓“服务发现”，在搭建PD的时候，要去配置一些静态节点。PD有几种集群搭建方式，一种是配置一个静态的集群，各节点相互知道其他节点IP。也可以基于服务发现机制，节点自动组建集群。采用服务发现的好处是，集群的规模比较灵活，比较容易做一个动态的集群，而非采用静态的方式。

　　第四，Backup&Restore。基于社区工具和对象存储实现备份恢复数据。之前备份恢复功能，基于MySQL、Lightning做TiDB层的数据备份和恢复，Lightning还涉及写KV。而Backup&Restore工具直接从KV层备份数据。由于是在每个TiKV节点上直接备份，所以还可以支持更高的并发和吞吐。并且避免计算层的SQL解析，恢复速度也比较快。目前来看，这个工具很快，我们集成了Backup&Restore工具。同时，可以基于云备份到对象存储，再从对象存储做数据恢复。

　　另外用户更多关心采用容器化以后，如何确保稳定性，如何在一个复杂的系统里使用一个新的技术，让整个系统变得更好而非更糟糕。

　　这里有几项相对来说比较智能化的技术：

　　Automatic Failover。相当于你的TiKV本身具备故障自愈能力，假设指定了三个副本，当Operator检测到有个副本挂掉了，超过30分钟没有恢复，他就会做一个故障的自愈，这是传统的Ansible没有的特性，是TiDB Operator独有的一个特性，这也是基于云带来的一个好处。假设有三个副本，有一个副本做了健康检查失败了，时间已经超过30分钟，就会自动恢复一个新的副本。不用管原来的副本了，这个时候依然保持弹性的服务能力。当然，等待故障节点恢复了以后，会有一个超出期望的4个副本，这个时候DBA再去根据故障情况去判断，要不要把新增的副本下线掉。当然，这个30分钟的限制，也是Operator自身的一个参数，可以配置多长时间以后Operator才能新建节点。

　　Auto-scaling，结合Prometheus、TiDB的Pod及K8S的HPA能力，基于Metrics的一些关键指标，实现实例节点的扩容。当我们发现节点、业务特别繁忙的时候，会基于资源池进行扩容。用户可以指定扩容规则，比如最大的扩容上线，扩容的等待时间，可以有在用户端的页面按需设置。同时，有扩容就会有缩容策略，比如：有一个冷却的时间，超过这个时间以后，关键指标没有达到缩容的最低值，管控组件就自动缩容，告诉这个进程结束了，数据库会终止接受新的会话，并把当前会话进行处理完成，不会出现事务长时间的等待，超过等待时间被清除的情况。

　　Self-Driving，数据库集群整体有波动、有异常，如何把异常平滑地处理掉？通过监控、日志等自动地分析和识别参数，可以通过Self-Driving来实现。

　　TiDB上云后如何获得更好的用户体验？

　　一般情况下，DBA比较习惯在Linux里面去维护数据库，比如查看日志，但在分布式系统里很麻烦，因为需要登录到各个节点去看不同的路径，所以上云之后我们就接入了一些云本身的能力，包括集中日志管理，我们内部叫日志云，把K8S Pod上的日志等集中收集上来，然后在另外的产品页面里去做一些关键字的过滤、分析等。

　　另外，就是统一的监控页面，方便DBA做更好的分析，帮助用户做数据库性能的分析。该能力可以基于云平台的产品页面去添加，包括可以扩缩容，调整购买规格，调整付费方式，比如预付费还是按量付费等。

　　最后，云原生数据库也是一个持续演进的过程，为了让应用性能达到最佳，我们在底层技术支撑方面也在做一些新的探索，进行持续发力。

　　1、 纵向扩缩容（VPA）。我们在2021年推出的UbiSQL分布式数据库，在这方面在做进一步的探索，比如：如何基于实例进行纵向扩缩容（VPA）。原来的CPU有限定，但业务突然遇到高峰期，如果是水平扩容，首先能力和时间有限；另外，水平扩容有些大的SQL在单个实例上还是有瓶颈。于是套餐的规格需要扩大，在应用不用重启的情况下，原地增加可用资源限制，然后再去做纵向的套餐规格的扩容。

　　2、 异构集群（ Heterogeneous Cluster ）。存储节点在扩缩容的时候，包括底层存储，每个TiKV对应的存储块不一样，我们在构建集群的时候，允许加入不同的内存、CPU还有存储磁盘的比例，整个TiKV允许他有不同磁盘每一个块的比例。同时，异构集群还有一个特性，就是可以隔离AP和TP的请求。比如：有个做数据中台的业务找过来，有些业务是交易型，希望打在某个节点上；另外，有些业务是分析型的，希望打在另外的计算节点上，并且这些节点资源规格是不一样的，如何把这块功能以产品化的形式提供给用户，也是我们目前在做的事情。

　　3、 数据库自治能力（ Database Autonomy ）。我们也在做一些数据库自治探索。首先，构建数据库治理体系，因为治理体系是数据库自治的关键路径，先有一个治理的过程，有数据、有治理能力。接下来，再根据数据和治理能力再去做自动化，包括基于数据的分析、参数的调优。

　　TiDB可以优化的参数非常多，加上分布式架构组件，两者结合起来调优过程就非常复杂。而数据库自治可以解决很多问题。首先是，参数调优，根据不同的环境和业务负载，可以把数据库的一些参数调整到相对较好的状态。因为交付的集群都是默认的参数，这些参数要么是基于专家模型，专家觉得这个套餐能面向80%的业务，都在用这个参数，那就用这样的。但是，集群交付了以后，部分参数可以根据实际业务负载特性进行适当调整。我们通过数据库自治可以把参数调优变成一个自动化的过程。

　　然后是，积累下来的慢日志数据如何去优化？过去，很多日志数据都是基于人工的经验去做分析，我们希望把慢日志的分析能力自动化。现在，这些能力都依赖于所使用的基础设施，先把所有慢日志采集下来，然后再根据专家模型转化成自动化过程。

　　4、使用新型硬件优化KV存储（KVSSD）。将Rocksdb集成到SSD硬件中，从而直接使用硬件KV接口能力，上层应用原来需要通过Rocksdb访问SSD硬件。而现在硬件厂商直接就把KV能力集成到硬件中，类似于存算一体的硬件，可以显著提升SSD的KV读写性能。

　　总之，TiDB能超越传统数据库，让数据发挥更大价值，与容器相关的关键组件发挥了重要作用，而从云原生数据库设计的未来发展来看，还有更多可能性以及更大的探索空间！