共计 2299 个字符，预计需要花费 6 分钟才能阅读完成。
浙商银行股份有限公司（简称“浙商银行 ”）是 12 家全国性股份制商业银行之一，总部设在浙江杭州，全国第 13 家 ”A+H” 上市银行，致力于打造平台化服务银行，为客户提供凋谢、高效、灵便、共享、极致的综合金融服务。在英国《银行家》(The Banker) 杂志“2020 年寰球银行 1000 强 ” 榜单中，位列第 97 位。
浙商银行很早就开始全面推动数字化转型，2010 年浙商银行上线电子银行服务、手机银行业务，2017 年上线首个区块链服务平台，同年公布了直销银行品牌。2018 年浙商银行国标 A 级数据中心启用，并在 2020 年成立易企银金融科技子公司。
业务背景
浙商银行微服务可视化治理平台是基于 Java 体系自研的微服务治理监控平台，为行内基于对立的微服务框架开发的利用提供全面、实时的微服务治理监控性能，可能无效晋升云环境下的微服务可视化水平和服务管理控制的便捷度，缩小服务故障发现工夫，晋升故障定位效率，辅助应用程序优化。在这样的业务场景中，数据量大、监控指标繁冗成了咱们的次要挑战。
通过剖析监控数据，咱们发现它有以下特点：
- 数据高写入、低查问、不批改
对于按工夫程序插入的监控数据，会波及到大量的查问，没有批改数据的业务场景。 - 无需事务反对
如果数据模型设计得当，无需应用事务处理。 - 各监控指标之间互相独立，无需联结查问
- 数据时效性较强，超过肯定工夫的数据参考价值很小
外围诉求
针对这样的场景，咱们须要一款能高效解决时序数据的工具。在各种因素的影响下，咱们有如下几点需要：
- 开源可控，且最好是国产软件，且能反对国产化芯片
- 性能稳固
- 社区沉闷：开发者社区人员多，问答、探讨频繁且有稳固的开发团队反对
- 部署成本低：尽可能少的服务节点，运维成本低，占用 CPU、内存资源较少
- 性能弱小：反对万条数据秒级插入
时序数据库选型
在明确了外围诉求之后，咱们调研了几款典型的时序数据库产品，包含 Apache Druid、InfluxDB 和 TDengine。
具体比照如下：
- Apache Druid：Druid 是 Apache 基金会旗下的一款高性能的实时剖析数据库，反对工夫序列数据。功能强大、可自愈、自均衡、易操作、可进行无效的预聚合和预计算。不过对于时间跨度较大的查问不够灵便，而且架构较为简单，须要的计算资源多。
- InfluxDB：InfluxDB 是由 InfluxData 公司开发的一款开源的时序数据库，在业界十分风行。功能强大，部署简略，使用方便。不过集群性能没有开源。
- TDengine：能满足咱们的外围诉求，相干测试表明其性能优于 InfluxDB，而且开源了外围的集群性能。简略快捷、性能弱小；反对 JDBC 接口，能够使咱们利用疾速接入应用。还有一点十分重要，因为 TDengine 的外围研发团队在国内，很不便间接交换。
整体比照之后，咱们决定尝试 TDengine。
技术架构
可视化服务治理平台的一个外围性能就是实时的监控性能，监控数据通过微服务框架自带的埋点发送到数据接管模块，通过数据处理和格局转换之后发送到 Apache Kafka。数据处理模块会接管 Kafka 中的各类监控数据，依据不同的数据类型进行加工计算，存储到 Elasticsearch 和 TDengine 中。用户通过前端与后端的服务层对监控数据进行查问剖析。
到目前为止，存储于 TDengine 中的数据次要为时序类数据，如 CPU、内存使用率等零碎运行数据，微服务调用、分布式锁、数据库操作解决工夫，业务线程池、连接池等各类指标数据。
数据模型
目前收集的监控数据类型如下：
- JVMGC 相干指标
- JVMThread 相干指标
- JVMMemory 相干指标
- 零碎负载相干指标
- 数据库连接池监控数据
- Transaction 调用监控数据
- Dubbo 线程池监控数据
咱们针对每一个监控类型都采纳了超级表建表，以 JVMGC 为例，建表语句为：
create stable JVMGC (happentime timestamp, jvmUsedMemory bigint, jvmUsedMemoryyPercentage double, nonHeapMemoryUsed double, oldGenUsed bigint, oldGenUsedPercentage double , directBufferUsed bigint) tags (application NCHAR(300), host NCHAR(500), ip NCHAR(50)) 与此同时，对每一个监控节点都建设一张子表，这样解决的益处在于：
- 雷同指标在进行多表查问时，能够利用超级表在一个 SQL 语句中实现查问
- 超级表能够实现表与表之间的数据聚合
- 对于单节点的监控数据，查问只须要拜访繁多子表即可
应用体验
目前微服务可视化服务治理平台对并发要求较高，然而 TDengine 能够很好地满足需要，插入 / 查问均匀耗时均在 10ms 以内。
TDengine 的开源版本小而粗劣，开发测试人员能够本人搭建公有的 TDengine 集群进行测试，毋庸放心影响别人，十分不便。
TDengine 的社区十分沉闷，遇到问题在 GitHub 上提 issue，或间接在官网的微信交换群里探讨，都能够疾速失去响应。
总结
TDengine 很好地满足了咱们的需要，性能和稳定性都十分杰出，同时极大升高了部署和运维老本。
TDengine 的反对团队也十分踊跃热心，可能疾速解决咱们遇到的大部分问题，为咱们罢黜了后顾之忧。
作为一款为物联网场景设计的时序数据库，TDengine 以存储效率高、性能弱小、性能稳固等特点在传统互联网利用架构中同样有着相当杰出的施展，超级表的设计省去了不少联表查问逻辑，大大简化了业务层的开发工作。接下来，咱们也期待在行内挖掘出更多 TDengine 的利用场景。
