共计 3754 个字符，预计需要花费 10 分钟才能阅读完成。
前言
TiDB 从 4.0 开始推出 TiUP 对 TiDB 集群进行装置部署和运维操作，极大水平的升高了 TiDB 集群的管控复杂度。然而 TiUP 作为一款命令行工具依然无奈齐全满足很多人的需要，能不能再简略点呀？能不能有个 UI 界面操作下呀？能不能有个图片看看集群状况呀？能不能一键就实现部署啊？能不能点点点就能主动数据迁徙和备份还原等等等？
甲方的需要总是那么的变态但又显得如同很正当的样子，终于 PingCAP 发表要推出一款 TiDB 治理的界面工具了 —— TiEM，上述的需要如同真的就实现了。
于是满怀好奇和期待的我，立马通过官网渠道收回了试用申请！很快啊，拉群，发安装包，手把手教学，几天不到，就实现了整个 TiEM 的试用体验。包含装置部署 TiEM 工具，导入配置，一键部署，集群操作，数据迁徙备份等等，体验还是相当不错滴！
所以上面给大家分享一下 TiEM 工具的体验过程。
TiEM 架构
TiEM 是反对在线和离线装置的，然而因为目前还没有凋谢相干的地址，所以试用版是发的 gz 压缩包，还包含配套文件。整个文件 900M 左右。
装置部署的具体过程这里就不一一截图详述了，间接看看部署后的 EM 架构。
TiEM 尽管只是一个可视化 TiDB 集群管理工具，然而自身的架构和 TiDB 相似，蕴含十分多的组件，治理 TiEM 就感觉像在治理 TiDB 集群一样。能够看进去 TiEM 的指标可远远不只是一个管理工具这么简略，将来必定会依据需要，增加越来越多的组件和服务。
目前 TiEM 集群一共蕴含 AlterManager，Cluster-Server，Elasticsearch，File-Server，Filebeat，OpenAPI-Server，Jaeger，Kibana，Nginx，Grafana 和 Prometheus 等 11 个组件，看名字都是十分眼生的一些组件。
能够将其划分成三个次要局部：
- Cluster-Server，File-Server 和 OpenAPI-Server 组成的 TIEM 自身的主体服务，能够了解成用于对其余组件进行封装集成，对立治理的服务。
- Elasticsearch，Filebeat 和 Kibana 组成的一套日志文件收集和剖析的性能。
- 监控告警三件套，Grafana，Prometheus 和 AlterManager。
最初还有一个 Jaeger 是用于整体服务调用链路的追踪和剖析，毕竟服务太多了。对于这些组件如果感兴趣能够独自去理解一下，而由这些组件组成的 TiEM 整体架构大抵如下：
最上层是 TiEM UI，可视化界面，通过 OpenAPI-Server，和 File-Server 来获取数据，而两头 Business Model 也就是实现 TiEM 治理层面，将上层的基础设施，进行对立封装和治理，当然这外面也包含本身的治理，例如用户，主机，集群的治理等等。TiEM 同时也会封装 TiUP 的所有操作，能够简略了解成将 TiUP 操作可视化，而 TiUP 那一套这里也不做赘述了。
最上层的基础设施中除了咱们刚刚在下面看到的一些组件外，还蕴含有 Sqlite（轻量级数据库）和一个 ETCD（高可用数据库），代表上层也是会做肯定的高可用。其中 Sqlite 我了解是用于存一部分的辅助数据，目前还不分明具体是怎么进行数据的分类和寄存。
整个架构是十分清晰明了的四层架构，根底设置 —> 服务集成和封装 —> 公开接口 —> 前端展现。
TiEM 功能模块
来到大家最关怀的局部，就是 TiEM 的应用。在应用之前，因为目前 TiEM 的局部性能没有具体实现，所以在部署实现后，须要间接拜访 OpenAPI 来进行初始化，初始化的过程中有两步比拟重要。第一步导入主机的规格模板，不便于前期部署的时候，能够给每个 TiDB 节点抉择相应的规格，例如 CPU 和内存等。第二步是增加 TiDB 产品，配置每个组件的相干参数的范畴，同样是为了创立 TiDB 集群的时候能够抉择部署的组件。
实现初始化后，就能够应用内置默认的账号密码登录主页。整个页面格调相似 Dashboard，从右边的菜单栏，能够看到整个零碎一共具备四个功能模块：Resources Management，Clusters Management，Work Task Management 和 System Management.
Resources Management
主机资源管理，用于所有的虚拟机和物理机治理，能够视作为资源池。通过导入性能，将现有的机器资源导入到资源池中，那么前面在一键部署 TiDB 集群的时候，会通过现有的资源池中，抉择适合的机器用于部署相应的节点。
抉择适合的机器，次要依附的是导入主机时给每个主机所定义的标签（Purpose），有三种标签，别离是 Compute（TiDB-Server），Storage（TiKV or TiFlash），Schedule（PD）。
Clusters Management
TiDB 集群治理的功能模块。上面有三个子页面，别离是 Clusters，Import\&Export 和 Parameter Groups。
Clusters 能够创立并治理集群，下图是我通过下面的三台主机搭建的一个测试集群。在这个页面，你能够看到该集群的根本信息，同时还集成了 TiDB Dashboard 和 Grafana 的性能进来。整体性能大略有这些：
1. 集群根本状态和配置查问；
2. 集成 Dashboard 的性能剖析，慢查问和日志剖析等；
3. Grafana 的监控告警配置；
4. 集群参数的对立查看和批改（这个性能我真的是期待太久了，始终认为会先上 Dashboard）；
5. 数据备份和同步工具应用；
6. 克隆集群。
7. 集群扩缩容操作。
终于，我再也不必在运维的时候，去 Dashboard，Grafana 和 Terminal 之间重复横跳。另外还有两个页面，一个是数据的导入导出，一个是参数组。
参数组能够设置多套自定义参数模板间接利用到部署的 TiDB 集群中，这个性能是相当的赞！毕竟 TiDB 集群和零碎参数太多了，而且每个版本还都有差别。在参数组中曾经内置了 TiDB 多个版本的默认参数，比起翻文档可来的快多了！
WorkFlow Task Management
在这个页面，会将所有的工作流进行记录，所谓工作流，就是咱们在 TiEM 外面的操作工作，例如导入物理机，创立集群，删除集群等等都会作为一个工作流去执行。所以咱们在这个页面可能晓得历史的操作记录，还有每个工作的执行详情，是否胜利。如果有工作失败了，能够点进去查看工作运行的每一步，具体是到哪一步的时候失败的，不便于咱们进行问题排查。
在本次测试集群部署的时候遇到的很多问题，都是通过工作流记录来排查的，很实用的一个性能。
Systems Management
最初一个大模块是系统管理，这个模块和 TiDB 集群没有关系，而是针对于 TiEM 自身的一个治理模块。
很直观就能看到，有三个子页面，System Monitor，Systems Logs 和 System Tracer。用户能够通过系统监控，日志剖析和调用链路追踪三个维度去查看整个 TiEM 零碎目前的运行状态，根本是全方位的工具都用上了。如果 TiEM 零碎层面呈现任何问题，通过这些来进行排查会十分的不便。
那么作为一个 DBA 也能够简略的将 TiEM 作为一个非凡的 “TiDB Cluster” 来进行日常运维和问题排查。
体验感想
体验 TiEM 平台，尽管还有局部高级性能没有测试到，然而根本的性能都走了一遍（这里很感激 PingCAP 的技术支持人员，十分急躁的解答了很多问题）。抛开外部性能的具体实现不说，单纯就集成 TiDB 泛滥周边工具的对立平台，其实意义曾经十分大了。何况 TiEM 的性能实现根本也都满足了我的预期，局部性能甚至超出了我的预期，例如像工作流和参数组的性能。
大抵的一些性能在上文都给大家介绍了一遍，上面谈谈 TiEM 这个平台目前 1.0.0 版本还有那些有余和我的小倡议。
- 初始化集群时的页面操作，这一块目前是 curl 手动调 OpenAPI 实现的，前期应该会很快就补上前端页面；
- TiEM 自身的用户组模块，目前只有内置管理员，通过交换理解，曾经设计了一套基于 RBAC 模型的权限治理，下个版本应该会推出；
- 在资源管理页面中，对于导入的主机配置无奈进行批改，只能导入和删除，如果机器发生变化或者导入失败，只能删除再从新导入；
- 一键部署时无奈为 TiDB 节点抉择指定机器，只能设置 Purpose 标签，零碎主动依照 Purpose 抉择机器。同时一个挂载盘只容许一个节点，也就是一台机器上如果你想要多个节点，必须给每个节点配置一个挂载盘。这两点在部署时比拟生硬，很难满足各种部署场景；
- 工作流中，没有重放或者重试的性能，例如我某一系列操作，两头呈现问题失败了，解决这个问题之后，我须要从新操作一遍。如果对于这个工作流，可能间接重放或者重试会好很多；
- 倡议在主机治理页面，减少一个连贯到服务器终端的性能，通过这个性能能够在页面对服务器进行一些指令操作。不便前面如果排查出服务器相干问题，可能间接登上去操作。
当然除此之外，还有遇到了一些小 bug，都曾经反馈给技术人员了，帮忙他们欠缺 TiEM 产品。在这一波体验之后，我对 TiEM 这个平台的正式公布能够说是相当期待的，同时更期待的是，会不会进行开源呢？让咱们也能给这个 TiEM 平台添砖加瓦。
