自动化交付计划布局
TDSQL 是基于一个分支来实现多场景、简单关系下的自动化交付的，其实也能够说是基于三个分支去做的——TDSQL 内核包，以后有三个分支：基于 CPU 的多分支进行公布，以后反对 X86、arm、power。TDSQL 对客户的公布包中，一个包主动集成了不同 CPU 版本的 TDSQL packet——以 ansible 组件为根底，加上了条件检测、操作系统调优、环境依赖的解决、平安标准、兼容性问题，是 TDSQL 规范公布包，可针对于客户不同的场景和不同的环境做适配。
TDSQL 的组件分为四个角色，疾速交付 TDSQL 集群，打个比方说就是把不同的鸡蛋放到不同的篮子里。鸡蛋是指这些组件；篮子就是咱们筹备的机器，能够是虚拟机，也能够是物理机。
首先集体体验的环境：集体体验环境更重视的是较低门槛，在这里咱们只须要一台虚拟机的配置就能够达到目标。而后能够把治理节点、DB 节点、数据节点和其余的节点都部署在这台机器上。当然在体验的环境下，数据节点和其余的节点这两个性能能够不进行部署。
测试环境：该环境下重视的是性能、性能。首先从治理节点来看，治理节点提供的是元数据的治理和工作的散发性能，要求的是稳定性和容灾能力。在测试环境能够略微弱化这个要求，比方能够筹备一台或者三台虚拟机、配置 4C/8G 一般磁盘；在测试环境下要做 DB 节点的话，要思考到 TDSQL 的性能问题，这里举荐应用物理机；进行性能测试的时候要求肯定是 SSD 盘，否则性能数据没有任何参考性——这也是由数据库的场景决定的，因为 SSD 和一般的磁盘，一方面次要体现在随机读写能力上的差距会比拟大；数据节点和其余的节点方面，如果有一些客户对测试的性能要求没有那么强，就能够不部署这些节点的性能，而如果想体验残缺的 TDSQL 的性能，则须要筹备这些机器，以体验残缺的 TDSQL 的性能；如要部署数据节点，能够抉择一台机器或者三台虚拟机，以及筹备较大容量的磁盘做数据节点；其余的节点，比方负载平衡和日志剖析平台，TDSQL 的负载平衡比拟灵便，位于 SQL 引擎层上的上一层，这里举荐开源的 LVS，当然也有很多客户会应用 F5。最初，以上环境咱们的举荐是部署两节点来实现容灾能力。总体而言，为了保障测试的性能，测试环境要求最多的是 DB 节点模块。
生产环境：生产环境中要求治理节点能够部署在三台或者五台虚拟机，但最好是跨三个机房，比如说“1+1+1”的模式或者“2+2+1”的模式，因为元数据集群是基于少数选举的机制来保障高可用，如果只有两个机房则会失去了自身容灾的意义，因而咱们倡议生产环境中部署三个机房；DB 节点生产环境更举荐的是 NVME 接口的 SSD，因为传统的 SSD 和 NVME 的 SSD 在接口性能上会有比拟大的差距，而数量上举荐的是 3 * N 台——事实上这个要去评估生产环境 TDSQL 集群的数据量，TDSQL 是一个分布式数据库，数据量级能够依据用户机器数量实现程度拓展。
举个例子假如客户有 3T 数据，如果单台物理机是 1T、一个 set 内做的是一主两备三个节点，咱们此时须要三个 set，三个 set 能够承当 3T 数据量，同时会有两个正本的冗余，DB 节点的这些数就须要 9 台这样的机器，这三个 set 会组成 group shard；数据节点的机器也是举荐物理机，同时在生产环境须要思考容灾能力，因而举荐是三台机器以上。此外，须要一个高性能磁盘来保障回档和备份的效率；最初，拜访链路上接入层是十分重要的一层，咱们强烈推荐物理机来进步稳定性。
TDSQL 自动化交付特色与要求
在 TDSQL 真正交付过程中，为了保障交付品质，联合金融级场景的平安合规、高可用容灾思考，咱们积淀出一些根本要求和个性：
网络：离线部署无外网依赖，机器互通；
存储：反对单磁盘、多磁盘和 raid；
冷备核心：反对 hdfs 和挂载式分布式存储 (如 ceph)；
机器散布：反对跨机架和跨机房上架服务器，反对多种机器分布模式下的高可用容灾；
CPU：在国产化趋势下，目前机器 CPU 除了适配 x86，还包含 arm、power，而且首要举荐以上其中一款；
操作系统：适配反对 centos、ubuntu、以及包含国产化操作系统在内的诸多支流操作系统；
在交付过程中咱们只有理分明如何把鸡蛋放到对应的篮子里即可实现自动化交付：咱们先选出篮子，一组物理机就是一个篮子，随之把一组的组件 DB 节点放到这个篮子里。
灵便交付
当然这其中有很多细节，客户要做的，是自在决定模块的机器散布和集群规模，TDSQL 能够通过模块之间的数量差别，自适应地做出单点计划和多节点高可用容灾计划。这个过程用户在操作上是无感知的。举个例子，比方 TDSQL 是反对 HDFS 作为冷备核心，如果 HDFS 选的是一个节点，零碎会做一个 HDFS 的单点计划。如果是三节点的配置布局，它会主动感知到要做的是一个高可用容灾计划。HDFS 用的高可用容灾计划是基于 QJM 的形式。
简略高效：整个部署过程最快仅需 9 分钟
做完部署布局，第二件事件是解决各个组件之间的一些关系，包含兼容性等问题。举个例子，如果部署的 TDSQL 环境是基于 ARM 国产服务器的操作系统的国产化环境。咱们如何通过一个交付物料包去适配不同的环境？其实机密就在这个配置文件里：
用户无需关注 TDSQL 较为简单的各模块的相互依赖和配置管理问题，只须要依据理论，填写变量文件配置即可；
用户填写一个机器规格配置文件、一个变量配置文件，填写后能够适配操作系统和 CPU 实现一键自动化交付
操作简略用户可独立实现，自动化部署命令可反复执行，在北京信通院机构现场对 TDSQL 产品化的测试显示，整个部署过程最快仅需 9 分钟
适配与集成：国产化、全栈式
以后国产化曾经成为一个趋势，TDSQL 在国产化适配方面也做了很多工作，从底层的服务器到存储器、操作系统、CPU、行业软件、数据库软件等，都在相干部门领导下进行了与各个厂商单干实现从上层到下层全方位的国产化适配。在国产化的浪潮下，TDSQL 作为一个腾讯自研分布式数据库，咱们也是责无旁贷的担当了国产化的责任。包含腾讯外部的操作系统 tlinux，以及中标麒麟、河汉麒麟、UOS 等支流国产化操作系统，TDSQL 都实现了适配。除了适配全系国产操作系统，TDSQL 同时已相继实现对全系国产芯片，全系列国产服务器等的兼容适配工作。而在实现适配工作的同时，腾讯也提供了对应的技术服务，帮忙行业用户更好地迁徙到国产根底技术生态当中。这些是咱们国产化方面的工作。
技术服务生态方面，TDSQL 不仅可作为一个独立公布的产品，在 TDSQL 倒退的历程中，也被其余很多平台厂商和合作伙伴接收，包含腾讯外部的 TCE、Tstack、MDB 架构等。TCE 是腾讯云金融级平台，TDSQL 和 TCE 在部署计划、告警、用户权限等等各种维度和 TCE 进行了深度的集成，可为金融政务机构提供全方位的 PaaS 根底技术服务，在实现高性能的分布式架构转型降级的同时保障金融级稳固高可用。除了外部的平台，TDSQL 许多合作伙伴的行业解决方案中也集成了 TDSQL，把 TDSQL 的能力输出到他们本人的平台。
平安保障：秒级监测
TDSQL 在倒退中对交付场景做了许多优化：
条件检测：首先会主动对布局的 TDSQL 集群下的所有机器做前置检测，包含机器工夫同步、时区统一、端口占用、零碎默认 sh、机器规格等做检；
环境优化：针对关系型数据库场景，对系统 50 处左右进行针对性调优，并解决一些根底的依赖；
机器秒级监控：大部分的监控平台都是基于分钟级的，对于金融级数据库这种敏感场景，分钟级的监控是不够的，所以咱们针对这样的场景提供了秒级监控，包含针对机器的 IO、CPU、网络、内存等多个维度。