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

导语

针对每一个微服务所拥有的数据库发生变更时所产生的事件,要如何做出相对应的动作, 以维护其所拥有的数据库或数据仓储中的数据的时效性; 这确实不是件容易的事, 本文提供了四种架构方案。

前言

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

本文

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

A. Database Pull Model (Shared DataIntegration Style):

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

图一: Database Pull Model

  

B. Http Pull Model (RPC IntegrationStyle):

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

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

图二: Http Pull Model

C. Batch Pull Upload (Shared DataIntegration Style):

在夜间执行批处理至各微服务所拥有的数据库中获取数据, 并写至负责生成报表的服务所拥有的数据库或数据仓储中。

此设计方案因为同样是属于 Shared Data IntegrationStyle, 所以, 也存在著破坏了原微服务的边界上下文 (Bounded Context) 的问题; 使得原微服务无法独立自主的修改自身所拥有的数据表结构。原微服务若有任何数据表结构上的修改, 将会影响到生成报表的服务所拥有的数据库或数据仓储。

当然, 此设计方案的另一个问题便是: 数据的时效性; 生成报表的服务所拥有的数据库或数据仓储, 将无法获得实时的各微服务所拥有的数据库中的数据。

图三: Batch Pull Upload

D. Event-Based Push Model (MessageBased Integration Style):

当各微服务所拥有的数据库发生变更时, 便会产生一个事件。此事件便会使得生成报表的服务去处理此事件; 至发生数据库变更的微服务获取所变更的数据, 并写入其所拥有的数据库或数据仓储中。

此设计方案不仅维持了各微服务的边界上下文 (Bounded Context), 更使得生成报表的服务所拥有的数据库或数据仓储, 获得实时的各微服务所拥有的数据库中的数据; 拥有数据的时效性。

图四: Event-Based Push Model

结论

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

边界上下文

数据的时效性

Database Pull Model

Http Pull Model

Batch Pull Upload

Event-Based Push Model

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

原创声明,本文系作者授权云+社区发表,未经许可,不得转载。

如有侵权,请联系 yunjia_community@tencent.com 删除。

编辑于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏FreeBuf

FireHost发布2013年第二季度排名前四的攻击方法

本周二,云托管公司FireHost公布了2013年第二季度排名前四的攻击方法,分别是跨站脚本攻击(XSS)、目录遍历、SQL注入、跨站请求伪造(CSRF)。 F...

1876
来自专栏腾讯移动品质中心TMQ的专栏

【穿山甲系列】找出后台偷偷耗电的元凶

如图所示,在浏览器用户反馈中,耗电一直是头部问题之一,用户对于电量是非常敏感的,特别是那种类似“我明明就没用,怎么还在耗电?”的后台耗电问题,更容易引起用户的抱...

2416
来自专栏PingCAP的专栏

捕获和增强原生系统的可观测性来发现错误

在对 TiDB 进行 Chaos 实践的时候,我一直在思考如何更好的发现 TiDB 整个系统的故障。最开始,我们参考的就是 Chaos Engineering ...

310
来自专栏about云

hadoop3.0 Yarn支持网络资源:network原理设计文档说明【中文】

问题导读 1.网络作为Yarn的资源,有什么好处? 2.Yarn是否只支持调度和强制执行“传出流量”? 3.Yarn是否支持入口流量? 4.Distribut...

3275
来自专栏WeTest质量开放平台团队的专栏

https大势已来?看腾讯专家如何在高并发压测中支持https

用epoll编写一个高并发网络程序是很常见的任务,但在epoll中加入ssl层的支持则是一个不常见的场景。腾讯WeTest服务器压力测产品,在用户反馈中收到了不...

933
来自专栏EAWorld

微服务编排之道

目录: 一、微服务需要编排吗? 二、微服务编排的流程 三、微服务编排的一致性 四、微服务编排的监控工具支撑 一、微服务需要编排吗? 微服务是一种新的软件架构风格...

5446
来自专栏程序你好

微服务和传统中间件平台

微服务与部署在中间件平台(esb、应用服务器)上的传统服务有何不同?什么是微服务体系结构模式,它解决了什么问题?本文将讨论所有这些重要的主题,并描述如何管理、管...

772
来自专栏芋道源码1024

【追光者系列】HikariCP连接池监控指标实战

6134
来自专栏SDNLAB

【连载-5】数据中心网络虚拟化 网关及服务接入

1 网络虚拟化网关技术 虚拟网络中的虚拟机与外部网络通信的需求催生了网络虚拟化中网关(Gateway)技术的出现。现有虚拟化平台网关产品有:IBM SDN VE...

2578
来自专栏SDNLAB

【连载-5】数据中心网络虚拟化 网关及服务接入

网络虚拟化网关技术 虚拟网络中的虚拟机与外部网络通信的需求催生了网络虚拟化中网关(Gateway)技术的出现。现有虚拟化平台网关产品有:IBM SDN VE G...

3198

扫码关注云+社区