如何在微服务中实现分布式事务的变通? -Talentica

20-05-01 banq

传统单体架构下的分布式事务概念并不适合微服务,面临的挑战很多(挑战问题点击标题见原文),想在微服务中进行分布式事务处理?需要改变思路和视角:

  1. 组合,如果您认为您应该合并几个微服务或将事务集成到一个服务中,那么进行此练习永远不会晚。(banq注:根据DDD有界上下和聚合的概念将需要事务的操作聚合起来:https://www.jdon.com/54023
  2. 为事务构建一致且有用的审核,并确保您始终捕获审核,即使服务超时也是如此。一个简单的示例,比如有事务ID,实体ID的结构化日志以及定义策略的能力,这些策略使您能够跟踪失败的事务并由数据操作团队进行修复(这是非常关键的)。您需要使他们能够解决这些问题,如果涉及工程团队,则您的审核设置将失败)
  3. 重新设计过程以进行混乱测试。不要用假设的场景进行测试(例如杀死服务,然后查看其他组件的行为),而是尝试生成可能导致服务终止或超时的情况或数据或序列,然后查看弹性/重试在其他服务中的工作方式。
  4. 对于新需求,请始终根据测试时间而不是开发时间进行估算,影响分析并制定行动计划(因为现在您将花费大部分时间进行测试)。
  5. 将断路器集成到您的生态系统中,以便您能够检查所有服务(即将参与这些交易的服务)是否都处于健康状态。这样,您甚至可以在开始交易之前就避免半成品交易。
  6. 采用批处理,其中您可以批量和脱机转换一些关键事务,以使系统更加稳定和一致。例如,在电子商务中,您在供应商和消费者数据库中都有产品。在这里,您不必先编写分布式事务在两个数据库中来创建新产品,而是首先只能在供应商数据库中编写并运行批处理以挑选100个新产品并将其插入到消费者数据库中。对于订单微服务和库存微服务之间需要实现分布式事务,您可以使用以下设计以批处理替代:在这里,您仍然可以进行扩展,隔离和独立部署,但是批处理过程将使其更加一致。
  7. 不要尝试构建两阶段提交,而要使用一种仲裁器模式,该模式本质上支持弹性,重试,错误处理,超时处理和回滚。这也适用于PUB-SUB,使用此方法,您无需使每个服务都强大,只需确保仲裁员能够处理大多数情况。
  8. 为了提高性能,您可以使用IPC,跨进程的内存共享和TCP,(如果有闲聊的微服务检查gRPC或websocket)作为其余API的替代方法。
  9. 如果处理不当,配置将成为噩梦。如果您的应用由于缺少配置而导致生产失败,并且您正忙于回滚,修复和重新部署,则此处还需要其他内容。很难精简每个微服务配置,并且在交付生产之前您永远无法弄清所有缺失的配置。

                   

2
猜你喜欢