微服务架构设计(五):获取微服务数据, 生成报表

本文涉及的产品
云原生网关 MSE Higress,422元/月
注册配置 MSE Nacos/ZooKeeper,118元/月
任务调度 XXL-JOB 版免费试用,400 元额度,开发版规格
简介: 本文是微服务架构设计系列的第五篇。架构师在设计从多个微服务取数据, 而生成报表的架构设计方案时, 往往面临著需在边界上下文 (Bounded Context), 数据的时效性, 性能, 可靠性与开发的复杂度间作取舍。本文将分享从多个微服务取数据, 而生成报表的设计方案。

架构师在设计从多个微服务取数据, 而生成报表的架构设计方案时, 往往面临著需在边界上下文 (Bounded Context), 数据的时效性, 性能, 可靠性与开发的复杂度间作取舍。

从多个微服务取数据, 而生成报表的设计方案, 主要是参考: Enterprise Integration Patterns; Hohpe and Woolf。

A. Database Pull Model (Shared DataIntegration Style): 直接至各微服务所拥有的数据库中获取数据, 并写至负责生成报表的服务所拥有的数据库或数据仓储中。此设计方案主要的问题是: 破坏了原微服务的边界上下文 (Bounded Context), 使得原微服务无法独立自主的修改自身所拥有的数据表结构; 原微服务若有任何数据表结构上的修改, 将会影响到生成报表的服务所拥有的数据库或数据仓储。

B. Http Pull Model (RPC IntegrationStyle): 负责生成报表的服务, 经由各微服务所提供的REST API, 取得所需的数据, 并写至自身所拥有的数据库或数据仓储。此设计方案, 藉由 REST API, 维持了各微服务的边界上下文 (Bounded Context), 但, 却存在著其他的问题:

  1. 性能上的问题: 当负责生成报表的服务需同时向许多个 (上百个) 微服务获取数据时, 则就表示将会有上百个远程调用会发生。所以, 有可能负责生成报表的服务的某一个数据请求, 已经达到了 Time Out, 但有的微服务所提供的数据, 还尚未送至负责生成报表的服务。
  2. 数据量的问题: 当负责生成报表的服务向微服务获取大量的数据时; 例如: 整个月的股票买卖。则大量的数据将造成大量流量, 所以, 也有可能对负责生成报表的服务的某一个数据请求, 造成 Time Out。


C.Batch Pull Upload (Shared DataIntegration Style): 在夜间执行批处理至各微服务所拥有的数据库中获取数据, 并写至负责生成报表的服务所拥有的数据库或数据仓储中。
此设计方案因为同样是属于Shared Data IntegrationStyle, 所以, 也存在著破坏了原微服务的边界上下文 (Bounded Context) 的问题; 使得原微服务无法独立自主的修改自身所拥有的数据表结构。原微服务若有任何数据表结构上的修改, 将会影响到生成报表的服务所拥有的数据库或数据仓储。
当然, 此设计方案的另一个问题便是: 数据的时效性; 生成报表的服务所拥有的数据库或数据仓储, 将无法获得实时的各微服务所拥有的数据库中的数据。

D. Event-Based Push Model (MessageBased Integration Style): 当各微服务所拥有的数据库发生变更时, 便会产生一个事件。此事件便会使得生成报表的服务去处理此事件; 至发生数据库变更的微服务获取所变更的数据, 并写入其所拥有的数据库或数据仓储中。
此设计方案不仅维持了各微服务的边界上下文 (Bounded Context), 更使得生成报表的服务所拥有的数据库或数据仓储, 获得实时的各微服务所拥有的数据库中的数据; 拥有数据的时效性。


比较这四种设计方案在边界上下文 (Bounded Context) 、数据的时效性上的优、劣:

边界上下文

数据的时效性

Database Pull Model

Http Pull Model

Batch Pull Upload

Event-Based Push Model

 

当然, 天下没有白吃的午餐; Event-Based Push Model 虽然维持了边界上下文 (Bounded Context) 并提供了数据的时效性。但, 却增加了产品架构的复杂度。使得微服务与生成报表的服务间产生某种程度上的耦合。也就是说, 生成报表的服务必需知道:针对每一个微服务所拥有的数据库发生变更时所产生的事件,要如何做出相对应的动作, 以维护其所拥有的数据库或数据仓储中的数据的时效性; 这确实不是件容易的事。


本文作者:

方俊贤 (Ken Fang), 曾任职于 IJI, Rational, Telelogic, Borland◦ 有将近二十年在半导体, 电信产业与军事研究单位, 从事软件工程与精益敏捷开发相关咨询服务的经验。 主要专长是精益敏捷开发, 有价值的产品需求挖掘, 使用者行为场景分析, 动态注入框架设计, ROA, 既有软件架构优化, 探索式测试, 敏捷测试与持续集成。


本文转载自 方俊贤_Ken 的 CSDN 博客

原文链接:http://blog.csdn.net/featuresoft/article/details/52226297

目录
打赏
0
0
0
0
455
分享
相关文章
后端服务架构的微服务化转型
本文旨在探讨后端服务从单体架构向微服务架构转型的过程,分析微服务架构的优势和面临的挑战。文章首先介绍单体架构的局限性,然后详细阐述微服务架构的核心概念及其在现代软件开发中的应用。通过对比两种架构,指出微服务化转型的必要性和实施策略。最后,讨论了微服务架构实施过程中可能遇到的问题及解决方案。
AllData数据中台架构全览:数据时代的智慧中枢
杭州奥零数据科技有限公司成立于2023年,专注于数据中台业务,维护开源项目AllData并提供商业版解决方案。AllData提供数据集成、存储、开发、治理及BI展示等一站式服务,支持AI大模型应用,助力企业高效利用数据价值。
从单体到微服务:如何借助 Spring Cloud 实现架构转型
**Spring Cloud** 是一套基于 Spring 框架的**微服务架构解决方案**,它提供了一系列的工具和组件,帮助开发者快速构建分布式系统,尤其是微服务架构。
310 69
从单体到微服务:如何借助 Spring Cloud 实现架构转型
智慧工地云平台的技术架构解析:微服务+Spring Cloud如何支撑海量数据?
慧工地解决方案依托AI、物联网和BIM技术,实现对施工现场的全方位、立体化管理。通过规范施工、减少安全隐患、节省人力、降低运营成本,提升工地管理的安全性、效率和精益度。该方案适用于大型建筑、基础设施、房地产开发等场景,具备微服务架构、大数据与AI分析、物联网设备联网、多端协同等创新点,推动建筑行业向数字化、智能化转型。未来将融合5G、区块链等技术,助力智慧城市建设。
微服务引擎 MSE:打造通用的企业级微服务架构
微服务引擎MSE致力于打造通用的企业级微服务架构,涵盖四大核心内容:微服务技术趋势与挑战、MSE应对方案、拥抱开源及最佳实践。MSE通过流量入口、内部流量管理、服务治理等模块,提供高可用、跨语言支持和性能优化。此外,MSE坚持开放,推动云原生与AI融合,助力企业实现无缝迁移和高效运维。
探索微服务架构下的API网关设计
在微服务的大潮中,API网关如同一座桥梁,连接着服务的提供者与消费者。本文将深入探讨API网关的核心功能、设计原则及实现策略,旨在为读者揭示如何构建一个高效、可靠的API网关。通过分析API网关在微服务架构中的作用和挑战,我们将了解到,一个优秀的API网关不仅要处理服务路由、负载均衡、认证授权等基础问题,还需考虑如何提升系统的可扩展性、安全性和可维护性。文章最后将提供实用的代码示例,帮助读者更好地理解和应用API网关的设计概念。
109 8
深入解析微服务架构中的服务发现与负载均衡
深入解析微服务架构中的服务发现与负载均衡
176 7
后端架构演进:从单体到微服务####
本文将探讨后端架构的演变过程,重点分析从传统的单体架构向现代微服务架构的转变。通过实际案例和理论解析,揭示这一转变背后的技术驱动力、挑战及最佳实践。文章还将讨论在采用微服务架构时需考虑的关键因素,包括服务划分、通信机制、数据管理以及部署策略,旨在为读者提供一个全面的架构转型视角。 ####
66 1
后端架构优化:微服务与容器化的协同进化
在现代软件开发中,后端架构的优化是提高系统性能和可维护性的关键。本文探讨了微服务架构与容器化技术如何相辅相成,共同推动后端系统的高效运行。通过分析两者的优势和挑战,我们提出了一系列最佳实践策略,旨在帮助开发者构建更加灵活、可扩展的后端服务。
云原生架构下的微服务优化策略####
本文深入探讨了云原生环境下微服务架构的优化路径,针对服务拆分、通信效率、资源管理及自动化运维等核心环节提出了具体的优化策略。通过案例分析与最佳实践分享,旨在为开发者提供一套系统性的解决方案,以应对日益复杂的业务需求和快速变化的技术挑战,助力企业在云端实现更高效、更稳定的服务部署与运营。 ####