微服务开发中的数据架构设计

资讯频道 → 行业应用

4顶
0踩

2018-03-20 10:03 by 副主编 jihong10102006 评论(4) 有12618人浏览

微服务架构设计

引用

GitChat 作者：陈伟荣
原文：微服务开发中的数据架构设计
关注微信公众号：「GitChat 技术杂谈」一本正经的讲技术

前言

微服务是当前非常流行的技术框架，通过服务的小型化、原子化以及分布式架构的弹性伸缩和高可用性，可以实现业务之间的松耦合、业务的灵活调整组合以及系统的高可用性。为业务创新和业务持续提供了一个良好的基础平台。本文分享在这种技术架构下的数据架构的设计思想以及设计要点，本文包括下面若干内容。

微服务技术框架中的多层数据架构设计
数据架构设计中的要点

为了容易理解，本文用一个简化的销售模型来阐述，如下图。图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 服务就是公开对外提供的业务服务。

数据架构自下向上相应的分为 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：多源数据适配

传统的关系型数据库之外，有多种多样的数据源，比如图像、声音、视频等多媒体数据文件或数据流，CSV、TXT、Doc、Excle、PDF、XML 等各种异构数。这些数据都需要做相应的处理，转换成可管理的数据信息。因此在数据架构设计的时候，需要给不同性质的数据源配置相对应的读写适配器，同时也需要有统一调度的地方，如图8所示。

图8 多源数据适配

要点5：多源数据缓存

数据处理的性能除了处理逻辑的复杂度以外，还有很大一部分是目标数据的操作时长（含对硬件磁盘设备的读写以及网络的传输）。网络速度特别是光纤的使用后已经大幅度提高，但机器磁盘的读写效率并没有显著提高，因此减少磁盘读写是提高效率的一个重要途径。数据缓存就是把常用的数据（不会经常更改的数据）、最近使用数据放到内存中。这样就可以大幅降低系统对硬件磁盘设备的操作开销，提高整个数据系统的性能，如图9所示。

图9 数据缓存

要点6：数据集市

数据集市是一个很大的话题。当现有的数据不能简单地通过几个表数据关联以及简单加工后就可以供业务使用的时候，就需要考虑构建数据集市。数据集市以数据运用的观点来分析加工数据，通过多源数据的导入、清洗、加工、视图做成等一系列的数据操作后，为业务提供可用的、稳定的数据源。例如，对销售分析中、什么样的客户喜欢什么样的商品、价格对销售金额的影响、销售金额跟地区日期的关联关系等多维度分析，就要用数据集市的概念，如图10所示。

图10 数据集市

数据承载着信息，好的数据架构设计会使业务系统变得更加流畅、更加容易理解和维护。本文只是总结一些在实际工程中的体会，供大家分享。如果有不足之处、也请大家补充、赐教。

查看图片附件

来自: gitbook

分享到：

4
顶

0
踩

评论共 4 条请登录后发表评论

4 楼一眉道人77 2018-03-26 21:13

3 楼 longguojiu 2018-03-23 16:04

2 楼 sxdtzhaoxinguo 2018-03-23 09:35

1 楼 Leoxiaogang 2018-03-21 16:36

发表评论

您还没有登录,请您登录后再发表评论

相关推荐

微服务开发中的数据架构设计.docx

基于DDD和微服务中台架构与实现

DDD面向对象设计，数据行为绑定，告别贫血模型；降低复杂度，分而治之；优先考虑领域模型，而不是切割数据和行为；准确传达业务规则，业务优先；代码即设计；欢迎有需求的朋友下载。

微服务架构下的分布式数据存储

开发企业事务往往牵涉到多个服务，要想做到多个服务数据的一致性并非易事，同样，在多个服务之间进行数据查询也充满挑战。我们以一个在线B2B商店为例，客户服务包括了客户的各种信息，例如可用信用等。管理订单，...

微服务架构的数据设计模式

最近参与公司项目研发，在其中发现对于数据的管理存在一些小问题...微服务架构中的服务是松耦合的，可以独立开发、部署和扩展。每个微服务都需要不同类型的数据和存储方式，也因为这样每个微服务都有自己的数据库。...

基于SpringCloud微服务架构社交系统的设计与实现

阅读建议：此资源以开发SpringCloud微服务架构社交系统学习其原理和内核，不仅是代码编写实现也更注重内容上的需求分析和方案设计，所以在学习的过程要结合这些内容一起来实践，并调试对应的代码。

微服务架构下的分布式数据管理

在微服务架构中，每个微服务都有自己私有的数据集。不同微服务可能使用不同的SQL或者NoSQL数据库。尽管数据库架构有很强的优势，但是也面对数据分布式管理的挑战。第一个挑战就是如何在多服务之间维护业务数据一致性...

微服务架构：数据一致性问题全景解析

微服务架构数据一致性分析：分布式事物+CAP&BASE+可靠事件模式+补偿模式+Sagas模式+TCC模式+最大努力通知模式+人工干预模式

SpringCloud微服务架构开发——01微服务架构与SpringCloud

一个典型的单体应用就是将所有业务场景的表示层、业务逻辑层和数据访问层放在一个工程中，最终经过编译、打包，部署在一台服务器上。以一个进存销系统的单体应用为例，架构如下图所示。单体架构的缺点：单体...

八大流行的微服务架构设计模式探究

有需要的伙伴请点㊦方】↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓...在微服务架构中，一个事务涉及调用多个服务，如果下游微服务发生故障，它会继续调，并耗尽所有其他服务的网络资源。

一张图搞懂微服务架构设计

当前，微服务架构在很多公司都已经落地实施了，下面用一张图简要概述下微服务架构设计中常用组件。不能说已经使用微服务好几年了，结果对微服务架构没有一个整体的认知，一个只懂搬砖的程序员不是一个好码农!在上图...

毕业设计选题 -未来生鲜运输车设计.pptx

基于樽海鞘算法优化的极限学习机回归预测及其与BP、GRNN、ELM的性能对比研究

内容概要：本文详细探讨了基于樽海鞘算法（SSA）优化的极限学习机（ELM）在回归预测任务中的应用，并与传统的BP神经网络、广义回归神经网络（GRNN）以及未优化的ELM进行了性能对比。首先介绍了ELM的基本原理，即通过随机生成输入层与隐藏层之间的连接权重及阈值，仅需计算输出权重即可快速完成训练。接着阐述了SSA的工作机制，利用樽海鞘群体觅食行为优化ELM的输入权重和隐藏层阈值，从而提高模型性能。随后分别给出了BP、GRNN、ELM和SSA-ELM的具体实现代码，并通过波士顿房价数据集和其他工业数据集验证了各模型的表现。结果显示，SSA-ELM在预测精度方面显著优于其他三种方法，尽管其训练时间较长，但在实际应用中仍具有明显优势。适合人群：对机器学习尤其是回归预测感兴趣的科研人员和技术开发者，特别是那些希望深入了解ELM及其优化方法的人。使用场景及目标：适用于需要高效、高精度回归预测的应用场景，如金融建模、工业数据分析等。主要目标是提供一种更为有效的回归预测解决方案，尤其是在处理大规模数据集时能够保持较高的预测精度。其他说明：文中提供了详细的代码示例和性能对比图表，帮助读者更好地理解和复现实验结果。同时提醒使用者注意SSA参数的选择对模型性能的影响，建议进行参数敏感性分析以获得最佳效果。

2025年中国生成式AI大会PPT（4-1）

无刷直流电机双闭环调速系统的Simulink建模与参数优化

内容概要：本文详细介绍了基于Simulink平台构建无刷直流电机（BLDC）双闭环调速系统的全过程。首先阐述了双闭环控制系统的基本架构，即外层速度环和内层电流环的工作原理及其相互关系。接着深入探讨了PWM生成模块的设计，特别是占空比计算方法的选择以及三角波频率的设定。文中还提供了详细的电机参数设置指导，如转动惯量、电感、电阻等，并强调了参数选择对系统性能的影响。此外，针对PI控制器的参数整定给出了具体的公式和经验值，同时分享了一些实用的调试技巧，如避免转速超调、处理启动抖动等问题的方法。最后，通过仿真实验展示了系统的稳定性和鲁棒性，验证了所提出方法的有效性。适用人群：从事电机控制研究的技术人员、自动化工程领域的研究生及科研工作者。使用场景及目标：适用于需要深入了解和掌握无刷直流电机双闭环调速系统设计与优化的人群。主要目标是帮助读者学会利用Simulink进行BLDC电机控制系统的建模、仿真和参数优化，从而提高系统的稳定性和响应速度。其他说明：文章不仅提供了理论知识，还包括了许多实践经验和技术细节，有助于读者更好地理解和应用相关技术。

西门子S7-1200 PLC与施耐德变频器Modbus通讯实现及调试技巧

内容概要：本文详细介绍了西门子S7-1200 PLC与施耐德ATV310/312变频器通过Modbus RTU进行通讯的具体实现步骤和调试技巧。主要内容涵盖硬件接线、通讯参数配置、控制启停、设定频率、读取运行参数的方法以及常见的调试问题及其解决方案。文中提供了具体的代码示例，帮助读者理解和实施通讯程序。此外，还强调了注意事项，如地址偏移量、数据格式转换和超时匹配等。适合人群：从事工业自动化领域的工程师和技术人员，尤其是那些需要将西门子PLC与施耐德变频器进行集成的工作人员。使用场景及目标：适用于需要通过Modbus RTU协议实现PLC与变频器通讯的工程项目。目标是确保通讯稳定可靠，掌握解决常见问题的方法，提高调试效率。其他说明：文中提到的实际案例和调试经验有助于读者避免常见错误，快速定位并解决问题。建议读者在实践中结合提供的代码示例和调试工具进行操作。

基于FPGA的Verilog实现IIC主从机驱动及其应用

内容概要：本文详细介绍了如何使用Verilog在FPGA上实现IIC（Inter-Integrated Circuit）主从机驱动。主要内容包括从机和主机的设计，特别是状态机的实现、寄存器读取、时钟分频策略、SDA线的三态控制等关键技术。文中还提供了详细的代码片段，展示了从机地址匹配逻辑、主机时钟生成逻辑、顶层模块的连接方法以及仿真实验的具体步骤。此外，文章讨论了一些常见的调试问题，如总线竞争、时序不匹配等，并给出了相应的解决方案。适合人群：具备一定FPGA开发基础的技术人员，尤其是对IIC协议感兴趣的嵌入式系统开发者。使用场景及目标：适用于需要在FPGA平台上实现高效、可靠的IIC通信的应用场景。主要目标是帮助读者掌握IIC协议的工作原理，能够独立完成IIC主从机系统的开发和调试。其他说明：文章不仅提供了理论讲解，还包括了大量的实战经验和代码实例，有助于读者更好地理解和应用所学知识。同时，文章还提供了一个思考题，引导读者进一步探索多主设备仲裁机制的设计思路。

4顶0踩