前言
微服务技术框架中的多层数据架构设计
数据架构设计中的要点
要点 1: 数据易用性
要点 2: 主副数据及数据解耦
要点 3: 分库分表
要点 4: 多源数据适配
要点 5: 多源数据缓存
要点 6: 数据集市
为了容易理解, 本文用一个简化的销售模型来阐述, 如下图图 1 显示了客户卖家商品定价订单的关系(这里省略支付物流等其他元素)
图 1 销售模型
在这个销售模型中, 卖家提供商品制定价格, 客户选择产品购买形成销售订单根据微服务的理念设计, 可以划分为客户服务卖家服务商品服务定价服务订单服务, 以及公共服务(比如认证权限通知等), 如图 2 所示
图 2 微服务功能
微服务架构中的多层数据架构设计
分布式架构一般把系统分为 Saas(Software-as-a-Service)Paas(Platform-as-a-Service)Iaas(Infrastructure as a Service )三层其中 Saas 层负责对外部提供业务服务, Paas 层提供基础应用平台, Iaas 层提供基础设施微服务垂直嵌入这三层服务之中, 相互独立因此数据架构设计时需要考虑三层服务对数据的关注点, 又要考虑微服务的独立性
数据架构的分层设计
图 3 微服务技术框架
如图 3 所示, Iaas 层提供程序运行的物理基础环境(这边涉及很多硬件. 网络内容, 在本文中省略)Pass 层细分为三层, 基础服务层, 主要负责数据存储处理; 事务框架层, 主要负责微服务的注册. 调度管理分布式事务处理; 应用服务层主要实现各个微服务的 API, 供其它微服务直接调用以及 Saas 层的服务调用 Saas 服务就是公开对外提供的业务服务全文中架构技术运用到的知识点可以在群 619881427 免费获取感兴趣的可以加入进来
数据架构自下向上相应的分为 Raw Data 层 Logic Data(inner)层和 Logic Data(outer)层 (Iaas 中主要以基础硬件环境为主, 在本文中省略)Raw Data 层是基于数据库文件或者其他形式数据内容 Logic Data(inner) 层是微服务 API 使用的逻辑数据, 比如客户数据订单数据等等 Logic Data(outer)层是对外服务提供数据, 比如客户订单数据因此, 我们的数据架构的分层结果如图 4 所示
图 4 数据分层架构
除此之外, 很多情报会以画面或报表的形式展现出来因此在 Logic Data(outer) 之上, 可以构建 Information Block(常用的信息块)通过 View type(显示模式)的设定后, 最终 View 展现出来
如图 4 所示, 越靠近对外服务层, 客户对设计者的影响度越大, 越需要从使用性易用性适用性等考虑反之, 越远离对外服务层, 设计上更关心数据的存储
数据三层架构的好处是实现数据从系统实现到业务实现的逐层过渡, 实现业务数据和系统数据间的松耦合同时实现业务的灵活扩展和系统的灵活扩展
数据架构设计中的要点
上面讲述了数据架构的分层设计, 下面讲述数据架构设计中的要点
要点 1: 数据易用性
数据无论用什么方式实现, 其最终目的都是为业务 (或者是客户) 使用的因此, 在对外提供服务的时候, 数据的易用性非常关键
图 5 数据易用性
如图 5 所示, 客户信息在 Logic Data(inner) 层中为了数据的柔软性和非冗余, 把人员信息拆成若干子表来存储比如, 人员地址表可以无限多的存储客户地址信息这样的好处在于每次人员地址更新时, 不用直接更新人员地址, 而是生成一个新的地址数据, 原有的地址信息作为历史数据得到保存, 易于数据快速恢复和历史信息追踪但在 Logic Data(outer)层提供外部数据的时候, 首先考虑的是一次性能提供足够用的信息(毕竟查询的操作大大高于修改的操作), 减少业务场景中不需要的信息比如对一般客户只提供三个常用地址的时候, 数据设计中地址 1 地址 2 和地址 3 放在一张表中
要点 2: 主副数据及数据解耦
每个微服务 API 的数据完全独立是不太现实的, 比如订单中需要有商品客户 (包括收货者) 卖家以及价格等数据如果这些数据都在订单服务 API 中管理, 那么客户情报的变更价格调整等信息都要同步给订单 API 中数据, 数据的耦合度就会变得非常高在数据设计的时候, 需要考虑降低数据间的相互依赖性因此, 首先需要确定每个微服务 API 的主数据和副数据主数据指微服务 API 的核心数据, 这种数据的增删改主要集中在某个微服务 API 中, 比如订单服务 API 中的订单数据副数据指参照或者映射其他微服务 API 的数据, 比如订单服务 API 中的商品数据价格数据等其次, 为了降低数据之间的耦合度, 用数据关联表来表征数据间的关系如果想去掉数据间的关联关系, 直接去掉关联表即可, 对数据本身的没有任何影响具体如图 6 所示
图 6 主副数据及数据解耦
要点 3: 分库分表
随着业务数据量不断增加, 单一数据库或单一数据表中会积累大量的数据, 比如订单数据, 随着时间推移和客户数量的增加, 产生的订单数据也会越来越多当数据累积到一定程度后, 数据操作的性能会大幅下降, 也就是我们常说的数据库带不动了所以, 在数据架构设计阶段就应该考虑数据的分库分表
如图 7 所示, 分库, 即我们把订单数据分为当前数据应用库历史数据库历史归档数据库当前数据应用库用来支持新订单的生成以及执行中订单的增删改查历史数据库 (这里举例分为最近 3 个月和最近 1 年) 当客户想看过往订单的时候才使用历史归档数据 (按年间归档) 原则上不直接对客户公开, 用于备查统计分析对于当前数据应用库, 可以继续再分库, 按客户号范围来分库这样每个数据库的大小都能得到有效控制分表, 即把一条信息分别存储在两张或多张表中比如把订单信息按基本信息和详细信息分表, 就可以适用于订单的基本信息查询和订单详细信息查询总之, 分库分表的核心就是控制单一数据库的负荷(数据量和数据信息量), 通过多表多库来应对业务数据量的增长
图 7 分表分库
要点 4: 多源数据适配
传统的关系型数据库之外, 有多种多样的数据源, 比如图像声音视频等多媒体数据文件或数据流, CSVTXTDocExclePDFXML 等各种异构数这些数据都需要做相应的处理, 转换成可管理的数据信息因此在数据架构设计的时候, 需要给不同性质的数据源配置相对应的读写适配器, 同时也需要有统一调度的地方, 如图 8 所示全文中架构技术运用到的知识点可以在群 619881427 免费获取感兴趣的可以加入进来
图 8 多源数据适配
要点 5: 多源数据缓存
数据处理的性能除了处理逻辑的复杂度以外, 还有很大一部分是目标数据的操作时长 (含对硬件磁盘设备的读写以及网络的传输) 网络速度特别是光纤的使用后已经大幅度提高, 但机器磁盘的读写效率并没有显著提高, 因此减少磁盘读写是提高效率的一个重要途径数据缓存就是把常用的数据 (不会经常更改的数据) 最近使用数据放到内存中这样就可以大幅降低系统对硬件磁盘设备的操作开销, 提高整个数据系统的性能, 如图 9 所示
图 9 数据缓存
要点 6: 数据集市
数据集市是一个很大的话题当现有的数据不能简单地通过几个表数据关联以及简单加工后就可以供业务使用的时候, 就需要考虑构建数据集市数据集市以数据运用的观点来分析加工数据, 通过多源数据的导入清洗加工视图做成等一系列的数据操作后, 为业务提供可用的稳定的数据源例如, 对销售分析中什么样的客户喜欢什么样的商品价格对销售金额的影响销售金额跟地区日期的关联关系等多维度分析, 就要用数据集市的概念, 如图 10 所示
图 10 数据集市
数据承载着信息, 好的数据架构设计会使业务系统变得更加流畅更加容易理解和维护本文只是总结一些在实际工程中的体会, 供大家分享如果有不足之处也请大家补充赐教
来源: http://www.92to.com/bangong/2018/03-29/33493370.html