一、前言

经过一段时间的测试，对tidb的阿里云计算巢服务有了一定的了解，整体服务架构官网已经给出，如下图所示，接下来说说整体的体验感受

二、实际试用

1.部署

首先来说说部署方面，整体的部署流程非常简单。填写所需的服务实例名称（这里要注意，服务实例名称不是真实的cluster name,真实的cluster name是写死的tidb-prod,官方之后应该会有改进），地域，配置等，但是多可用区只有高可用版本才有，试用版是没有的，所以也就意味着在试用版试用labels的功能对可用性没有太大的意义

整体的搭建速度很快，只需要接近八分钟的时间即可，省去了自己搭建的时候创建用户，下载tiup，编辑配置文件等时间，但同时，初始化的配置文件信息不能配置也有些影响（比如new_collations_enabled_on_first_bootstrap之类的参数，只能在集群创建的时候指定，不能更改，如这种就比较不好操作了）。搭建好的集群信息如下图所示，会有节点数量，创建时间，dashboard,grafana地址等信息。

2.运维

tidb常用的运维操作，也是非常好的一个功能就是在线横向扩展，这里面把弹性扩缩容集成起来了，只需要点点点就可以了，针对tiflash,tidb,tikv有不同的模版，在扩缩容的时候可以指定对应的组件和要扩缩容的数量，不过可惜的一点是，缩容的时候不能指定ip,也就是说缩容是随机的，这可能在高可用性能上产生非预期的情况，而且当前界面上的操作详情是没有办法查看的，这一点对扩缩容失败的排查带来了一些困难。

因为扩缩容是最常见的运维操作，所以这里做了一些测试

2.1 缩容一个tikv

单个store180个region缩容情况下迁移leader和region的时间为10分钟（这个时候查看display已经实际缩容完成） 平台界面实际的时间为35分钟。缩容完成之后,pd监控会有个tombstone stores的问题，需要手动调用pd-tcl来进行操作，消除监控里的tombstone stores的问题，感觉这个加入到缩容的步骤里更好，这样可以简化人工调用调用pd-ctl的步骤

2.2 命令行界面混用缩容操作

在使用过程中发现一个问题，手动缩容的时候，集群真实的实例变少了，但是阿里云平台界面的数量并没有变化，这就导致了下面两个场景的产生

场景一：比如初始有4个tikv,扩容之后变成5个tikv,此时在命令行中缩容一个tikv,这时集群有4个tikv,此时界面上本不应该允许继续缩容tikv,但是此时界面上记录的tikv数量为5个，所以还能继续缩容tikv,这样就导致了集群真实的tikv变成了3个。

场景二：如场景一中的例子，假如初始情况是3个tikv，最后一步缩容就会一直不成功，因为是三副本，所以tikv会一直处于pendding offline状态，这就导致了界面一直卡死的情况，等到很长一段时间后界面才会显示缩容失败，之后即使手动强制缩容，界面上的缩容也不会显示成功，而界面上缩容tikv失败之后，就无法再通过界面来对集群的tikv进行扩缩容操作，报错是因为上一个缩容操作没有正常完成

2.3 缩容tiflash

第一次想测试界面的缩容是否检测了tiflash副本，答案是肯定的，replica为1的情况下，一个tiflash不能正常缩容，界面显示缩容失败，然后又将replica设置为0，通过界面进行缩容，依旧显示缩容失败，这里比较难以理解，最后只能手动缩容，不过手动缩容就会出现上面所提到的问题，界面以为tiflash还存在着，数量并没有变更

3.删除服务实例

基本功能测完之后，对整体集群进行了回收操作，删除集群是非常方便的，只需要点击删除服务实例，8分钟整个服务实例删除完成

总结：

整体来说使用是非常方便的，包括部署和运维都能够快速上手，极大简化了基础运维操作，稍微有点基础就能上手操作，而且权限放的很开，能够在集群上做labels等相关操作，但如果能够定义初始化的配置文件，集群名称等，能够检测真实的集群各个组件的数量，有详细的集群界面扩缩容的报错，有备份恢复的方式会更好一些。