关于sql:TDSQL交付要求和挑战-快速灵活安全

45次阅读

共计 1373 个字符,预计需要花费 4 分钟才能阅读完成。

1.1 简单产品组件交付

首先咱们想讲的是 TDSQL 的交付挑战,咱们也是以三个方面去开展,第一个咱们遇到的挑战是咱们 TDSQL 产品架构所带来的特点 :一是产品化不断完善带来的特点——组件多,包含领有数据库内核,工作散发、冷备核心、平台告警、性能诊断等;二是组件之间相互依赖关系比较复杂。

首先从档次上把这些组件进行划分: 赤兔、监控采集、OSS、metacluster、扁鹊、onlineddl 等能够划分为一个角色,叫治理节点。对业务来说,理论拜访数据库的过程是,先是负载平衡层,而后到 SQL 引擎层,而 SQL 引擎层会间接拜访底层 DB,DB 上会部署 Agent。图中左侧列这些叫做治理节点;右侧列如冷备核心、音讯队列、多源同步等,个别划分为数据节点。而日志剖析平台其实是一个其余模块,可划分为其余的节点。

这些节点之间的依赖关系比较复杂。 比方治理节点,其次要负责元数据管理,元数据包含比方以监控采集模块为外围的监控数据、以工作散发零碎为外围的工作节点数据;第二是 DB 模块,DB 会和治理节点有一些交互——除了 DB 节点,还有其余的节点都会向治理节点发送监控信息;而治理节点也会下发工作,比方客户在前台进行的垂直扩容、程度扩容、主备切换等变更动作,也会到理论的 DB 进行交互;数据节点会向治理节点发送数据,和 DB 节点做一些交互……

所以其实各个组件之间的依赖关系比较复杂,这对于交付带来肯定的难处。

1.2 多场景适应性交付

第二个挑战来自于 TDSQL 多个场景。

TDSQL 多个场景次要来源于应用 TDSQL 的对象是不同的,包含集体、企业、第三方平台。不同的对象应用 TDSQL 的需要和场景也不同。集体应用可能更想低门槛疾速上手产品。企业应用最次要是 POC 测试和生产场景,关注的是整个产品的性能和性能,包含高可用性、容灾能力、国产化适配等。

不同场景的需要如何高效满足?是要做多个分支去适配不同的场景,还是用一个分支去适配不同的场景?当然咱们是用一个分支去适配不同的场景。

1.3 TDSQL 交付品质保障:平安、合规、多层级扫描

第三个挑战是,因为工夫的推移,负责 TDSQL 交付的人产生了变动。晚期 TDSQL 由产品研发团队、DBA 同学去现场给客户做交付。产品研发团队和 DBA 团队,大家都是一个团队,团队内因为长期的单干协同造成了规范和品质牢靠。而随着 TDSQL 产品化做大做强,用户规模不断扩大当前,交付人员会发生变化。不同的交付施行方,他们的操作和应用如果不够标准化,则容易带来隐患,体现在几个方面:

第一个是平安。 比如说环境的平安,咱们晓得数据库场景是对内存、CPU、硬盘、IO 等能力都是要求比拟高的场景,包含对 TCP 的内核参数优化等这些工作都是作为潜在危险来对立思考。

第二个是监控。 对整个集群、过程、机器的监控,以及主动拉起,即机器级别故障之后,疾速复原的能力,这些都要作为欠缺的体系来思考。其余比方定时工作,包含定时清理一些日志,清理一些历史数据,否则磁盘就会撑满,这在生产的环境上也是危险很大。最初是如何保障整个集群的高可用性、容灾能力;如何杜绝潜在旧版本带来的隐患,检测这些版本的破绽等方面,都是交付质量体系中须要解决的问题。

其实 TDSQL 交付品质服务和保障就是围绕着上述的各方面问题,实现由不同的施行人、施行方去交付 TDSQL 产品,都能保障 TDSQL 的投产品质。这是咱们在做的事件。

正文完
 0