分解单块系统

关键是接缝

接缝 -> 限界上下文

分解单块系统的原因

• 改变的速度

• 团队结构

• 安全

• 技术

杂乱的依赖

数据库

• 打破外键关系

• 共享静态数据

• 共享数据

• 共享表

事务边界

• 再试一次

• 终止整个操作

• 分布式事务

分布式事务很容易出错,而且不利于扩展。这种通过重试和补偿达成最终一致性的方式,会使得定位问题更加困难,而且有可能需要其他的补偿措施来修复潜在数据的不一致。

如果你遇到的场景确实需要保持一致性,那么尽量避免把它们放在不同的地方,一定要尽量这样做。如果实在不行,那么要避免仅仅从纯技术(比如数据库事务)的角度考虑,而是显式地创建一个槪念来表示这个事务。你可以把这个槪念当作一个句柄或者钩子,在此之上,能够相对容易地进行类似补偿事务这样的操作,这也是在系统中监控这些复杂概念的一种方式。举个例子,你可以创建一个叫作“处理中的订单”的概念,围绕这个概念可以把所有与订单相关的端到端操作(及相应的异常)管理起来。

报表

• 周期同步

• 通过服务调用来获取数据

事件数据导出

转载请注明：转载自srzyhead的博客(https://srzyhead.github.io)

本文链接地址: 微服务设计 (5-分解单块系统)