海科融通数据中心技术架构演进

在海科融通第四代平台开发过程中，数据中心项目作为新平台的核心项目之一，经历了从无到有到发展的一系列过程。在这个过程中，数据中心在技术架构上也进过了一些列演进。此文简要揭露一下数据中心技术架构演进过程。

背景

技术是服务于业务的，没有业务需求的技术架构是无源之水。数据中心项目也是在新平台业务平台的需要而产生的。

海科新平台是根据微服务化设计思想来设计的。业务系统根据业务模型拆分出几十个服务系统提供服务，为了配合为微服务化设计，数据库也是根据微服务化系统来设计的，每个基础服务对应专属数据库。为了满足大数据量高并发的需要，在部分微服务化数据库中，用到了分库分表的设计思想。

在数据库分裂的同时，业务系统不能按照微服务化思想设计，业务模式需要保持不变，旧系统中需要的多维度数据查询依然是必要的查询需求，实时性也不能有太大的改变。

基于以上需求，数据中心孕育而生

探索期

数据中心调研

如上图所示：

在当前主流数据仓库产品中，数据加工速度和数据管理能力是不可兼得的

每一中数据存储产品都有自己特定的应用场景

流计算在处理海量数据实时处理最佳的选择

结合初步数据调研，HBase和MongoDB在当前在性能上是满足我们最初需求最佳选择

HBase初探

列存储模式，基于HDFS文件存储，使用列蔟概念，单条数据更新性能相对比较弱

有唯一主键RowKey,原生不支持索引，可以使用第三方索引

数据模型设计困难，根据列查询缓慢，rowkey难于设计，无法预测查询维度

使用成本比较高，部署成本较高，集成第三方索引复杂，学习曲线比较陡峭，开发成本比较高

基于以上原因，HBase未作为业务数据主仓库作为存储介质

MongoDB选择

面向文档存储，基于Bson存储，支持多种数据类型

支持索引，支持自建索引，支持组合索引

热点数据缓存，数据查询性能强，更新性能不弱，支持分片模式横向扩展

数据运维方便，具备完善的运维工具，支持可视化客户端工具

数据模型灵活，支持子文档和数组文档，支持聚合查询方法多样

使用成本较低，集群搭建简单稳定，功能开发简单，学习曲线平缓

基于以上数据对比，我们最终选择mongDB作为业务数据主仓库

成型期

消息队列数据同步

在最初的技术架构中，采用业务消息数据同步的方式，如下图：

在各种业务系统埋点，监控数据变动

在数据变动是，发送变动数据到RabbitMq消息中

启动系统监听RabbitMq消息并解析

保存数据到MongoDB数据库

这种架构结构简单，但并部可靠。原因如下

对业务系统侵入性强，每次数据变动都需要发送MQ消息

无法保证数据一致性，业务系统变更，系统稳定性等因素都会影响数据一致性

消息中间件压力比较大，数据量大是消息中间件压力大，数据量不可控

基于以上原因，我们有了下面的解决方案(BINLOG事件同步)

BINLOG事件同步(canal)

启动 canal server,模拟数据库从库

提取Mysql数据库BinLog数据并解析DML消息

启动canal client,订阅DML消息

将DML消息数据转换成MongoDB入库数据

保存数据到MongoDB数据库中

这种技术架构结构完美解决了上一个方案所有的问题

数据同步与平台业务完全解耦，零依赖

数据最终一一致，BinLog数据是事务执行成功后的数据

数据模型灵活，元数据与Mysql数据1:1复制，整合数据模型灵活

数据模型建立

为什么要建立数据模型?

由于非关系型数据库基本都不支持数据表关联查询，MongoDB也不支持，所以需要在使用之前建立数据模型，以满足各种业务需求

如何建立数据模型呢?

数据模型的作用就是满足各种运营需求。所以我们第一版的数据模型是完全依赖运营系统建立起来的，运营系统的数据查询维度最多。为了兼容后续需求变更，数据模型是以mysql元数据(行数据)为基本单位，数据冗余比较多，但胜在兼容性强，模型组合简单

数据模型要求

由于随着数据规模的变大，更新数据模型会越来越困难，所以对于数据模型的第一版数据模型有一个硬性要求，要满足90%业务需求

发展期

数据同步工具(canal)优化

在基本数据模型建立完成以后，就需要考虑优化的问题。优化方式如下图：

如图所示，优化的方式如下：

将旧的server-client模式的系统集成成一个系统

将三组集群改成两组

这样做的原因是：

1.由于Binlog的日志属性，数据都是有时间顺序的。canal集群模式服务端和客户端节点都只会有一个节点在运行

2.合并server和client 可以将部署工作量减半，服务器资源使用减半，并且省去了服务端可客户端传输过程

优化后每开一条业务线需要部署的系统从6个变成2个，一个主节点，一个备份节点

数据多线同步

随着业务线扩展，数据消息同步也同时跟进进行了扩展，如下图

得益于对数据同步工具的优化，在公司业务扩展时，数据同步项目对服务器消耗并没有对公司服务器资源做过多的消耗，部署工作也方便了很多，极大的节省了公司的人力物力

未来

HBase实时数据线

在满足基本业务需求的同时，我们并没有满足当下，正在积极部署新的数据线，以实现对数据的实时流计算

启动canal-kafka 服务，模拟数据库从库获取数据

发送数据消息到kafka中

使用Spark Stream接收数据消息

实时分析数据到HBase指标库中

保存数据到HBase历史库中

实时流数据计算在风险管控，合规管理，反洗钱等方面都有得天独厚的优势。在实时流数据计算完成以后必然会推动海科融通业务实力的进步

数据增值服务

海科融通在收单支付行业已经有十多年的历史了，有着巨大的历史数据。对于大数据蓬勃发展的今天，这些数据是一个并未被开发的金矿，如何让这些数据产生额外的价值是我们以后工作的重点

结术语

满足运营需求不是终点

对技术的追求没有止境

想象力有多大，数据价值就有多大