
课程咨询: 400-996-5531 / 投诉建议: 400-111-8989
认真做教育 专心促就业
微服务架构开发是目前大多数软件开发程序员都在使用的一种编程架构方式,而本文我们就通过案例分析来了解一下,微服务架构事务模型类型分析。
与编排方案相比,统筹方案的服务之间的耦合更少。这是因为工作流是被协调服务驱动的,特定时刻的完整状态是在那个服务本身持有的。但是,这里的服务也不是完全独立的,因为它们的请求和响应是绑定到特定的队列的,固定的生产者和固定的消费者使用这些队列。因此,现在更难使用这些服务作为通用服务。
当我们的操作数量比较少时,基于编排的协调是可行的。对于复杂的操作,基于统筹的方案在对操作进行建模时更灵活。
在实现这种策略时,在开发框架中抽象出通信、状态机的持久化等细节是很重要的。否则,开发者将写更多代码来实现事务处理,而不是核心业务逻辑。另外,如果一个的开发人员总是从头实现这种模式,会更容易出错。
在我们实现事务时使用的任何技术中,我们需要明确每种方案给出的数据一致性保证。然后我们必须与我们的业务需求交叉检查,看看什么是适合我们的。下面可以用作一般指南。
2PC:如果微服务是使用不同的编程语言/框架/数据库以及来自不同公司的开发团队创建的,那就不可能将所有操作组合到单个服务中。另外,它还要求严格的数据一致性,在这种情况下,任何数据隔离问题(如脏读)都不能与业务需求相关。
基于补偿的事务:这是使用一个事务协调机制来跟踪事务中的每一个步骤,如果出现故障,执行补偿操作来回滚动作。这通常应该会使用幂等的数据操作或交换式更新,来处理消息重复场景。你的业务需求应该能够处理终一致性行为(如脏读)。
整合服务:由于这种方案的性能问题和可伸缩性,在2PC中使用这种方案是不能容忍的,但业务需要严格的数据一致性。在这种情况下,我们应该将相关的功能一起放到它们各自的单个服务中并使用本地事务。
【免责声明】:本内容转载于网络,转载目的在于传递信息。文章内容为作者个人意见,本平台对文中陈述、观点保持中立,不对所包含内容的准确性、可靠性与完整性提供形式地保证。请读者仅作参考。更多内容请加danei0707学习了解。欢迎关注“达内在线”参与分销,赚更多好礼。