微服务风靡一时。 他们有一个有趣的价值主张，即在与多个软件开发团队共同开发的同时，将软件快速推向市场。 因此，微服务是在扩展您的开发力量的同时保持高敏捷性和快速的开发速度。

简而言之，您将系统分解为微服务。 分解并不是什么新鲜事，但是通过微服务，您可以为团队提供尽可能多的自主权。

例如，专用团队完全拥有该服务，可以随时部署或重新部署。 他们通常也会使用devops来控制整个服务。 他们可以做出相当自主的技术决策并运行他们自己的基础设施数据库。 被迫操作软件通常会限制有线技术选择的数量，因为当人们知道他们将来必须操作它时，往往会更频繁地选择无聊技术。

 

Microservices are about decomposition, but giving each component a high degree of autonomy and isolation (微服务是关于分解，但为每个组件提供高度自治和隔离)

微服务架构的一个基本结果是每个微服务都是与其他微服务远程通信的独立应用程序。 这使得微服务环境成为高度分散的系统。 分布式系统有其自身的挑战。 在本文中，我将向您介绍我在最近的项目中看到的三个最常见的陷阱。

1.沟通很复杂

远程通信不可避免地要尊重分布式编程的8个谬误。 隐藏复杂性是不可能的，并且许多努力（例如Corba或RMI）已经失败了。 一个重要原因是您必须在服务中设计失败，以便在失败是新常态的环境中取得成功。 但是有一些共同的模式和框架可以帮助你。 让我们从一个例子开始 - 我经常遇到的真实情况。

我想飞往伦敦。 当我收到办理登机手续的邀请时，我去了航空公司的网站，选择了我的座位，然后按下按钮取回我的登机牌。 它给了我以下回应：

 

让我们假设航空公司使用微服务（可能不是这种情况，但我知道有其他航空公司这样做）。

 

我注意到的第一件事：错误返回得相当快，网站的其他部分表现正常。所以他们使用了重要的失败快速模式。条形码生成中的错误不会影响整个网站。我可以做其他一切;我无法获得登机牌。快速失败非常重要，因为它可以防止本地错误导致整个系统崩溃。该领域众所周知的模式是断路器，隔板和维修网。这些模式对分布式系统的生存至关重要。

快速失败是不够的

但快速失败是不够的。它将故障处理卸载到客户端。在这种情况下，我个人不得不重试。在上述情况下，我甚至要等到第二天，直到问题得到解决，我才能拿到登机牌！对我而言，这意味着我必须使用自己的工具来坚持重试（我的日历），以确保我没有忘记。

 

为什么航空公司不自行重试？他们知道我的联系数据，并且可以在准备好时异步发送登机牌。更好的反应是：

 

这不仅会更方便，而且还会降低总体复杂性，因为需要查看故障的组件数量会减少：

 

您可以将相同的原则转移到服务到服务通信。每当服务本身可以解决故障时，它就会封装重要的行为。这使得所有客户的生活更加轻松，API更加清洁。解决故障可能是有状态的（有些人称之为长时间运行）。我认为状态处理是微服务中故障处理的关键问题。

当然，上面描述的行为并不总是你想要的，将故障移交给客户端就可以了。但这应该是根据业务需求做出的有意识的决定。

我观察到大多数情况下，另一个原因导致人们避免有状态重试：它伴随着状态处理的复杂性。该服务必须重试几分钟，几小时或几天。它必须可靠地执行此操作（请记住：即使系统重新启动，我也希望登机牌），这涉及处理持久状态。

如何管理持久状态？

我看到两种处理持久状态的典型方法：

存储在数据库中的实体等持久性事物。

虽然这开始非常简单，但通常会导致很多意外的复杂性。您不仅需要数据库表，还需要一些调度程序组件来进行重试。您可能需要一些监视组件来查看或编辑等待作业。如果整体业务逻辑发生变化，您仍需要进行版本控制，而您仍想进行重试。等等等等。

这种思路导致许多开发人员如上所述跳过正确的故障处理，导致整个架构的复杂性增加 - 以及糟糕的客户体验。

相反，我建议利用轻量级工作流引擎或状态机。

构建这些引擎是为了保持持久状态并处理围绕流语言，监视和操作的后续要求，扩展以处理高容量等等。

市场上有几个轻量级工作流引擎。他们中的许多人使用ISO标准BPMN来定义流，其中许多是开源的。在这里，我将使用Camunda的开源工作流引擎来说明基本原则（快速免责声明：作为该项目背后的公司的共同创始人，我明显偏向于我的工具选择，但这是我最熟悉的工作流引擎）。对于前面描述的简单用例，可以使用Java DSL轻松创建工作流：

另一种选择是在BPMN中以图形方式建模工作流程：

 

这些工作流引擎在架构方面非常灵活。许多开发人员认为工作流引擎是一个集中组件，但事实并非如此。没有必要引入集中组件！如果不同的服务需要工作流引擎，则每个服务都可以运行自己的引擎来维护服务的自治和隔离。本博文中有关架构选项的更多细节将对此进行详细讨论。

 

另一个误解是工作流迫使开发人员切换到异步处理。这也不是真的。在上面的示例中，当一切顺利运行时，登记组件可以同步返回登机牌。只有在出现错误时才会回退到异步处理。这可以很容易地反映为HTTP返回码，200表示“一切正常，这是你的结果”，202表示“得到它，我会给你回电话。”有一些具体的示例代码来处理这个，它利用了一个简单的信号。

 

我将工作流引擎视为工具箱的重要组成部分，用于正确的故障处理，这通常涉及长期运行的行为，如状态重试。

2.异步性需要注意

 

这导致我们进行异步通信，这通常意味着消息传递。异步性通常被认为是分布式系统中的最佳默认值，因为它提供了解耦，尤其是时间解耦，因为任何消息都可以独立于接收器的可用性发送。一旦服务提供商可用，该消息将立即发送，而无需额外的魔力。

因此，重试的问题已经过时，但会出现类似的问题：您必须担心超时问题。假设航空公司在登记方案中使用异步通信。登记组件向条形码生成服务发送消息，然后等待响应。您无需关心条形码生成器的可用性，因为消息总线将在适当的时候传递消息。

但是，如果请求或响应因任何原因而丢失怎么办？您是否会在办理登机手续时遇到困难，未能在没有注意到的情况下将登机牌发送给客户？我打赌很多公司这样做，这再次导致我，客户监控响应并采取行动，如果没有登机牌在超时内到达。同样，我必须利用我的个人调度基础设施（日历）。

 

更好的方法是让服务监控超时本身，并在条形码未能及时到达时执行回退。可能的后备是重新发送消息，这实质上是重试。

您也可以利用工作流自动化技术来处理此用例。 BPMN中的工作流可能如下所示：

 

作为奖励，您可以免费报告重试次数，典型响应时间以及无法及时处理的工作流程数量。操作员可以通过提供大量上下文来轻松检查和修复失败的工作流实例，例如消息中包含的数据以及消息发送的时间。纯粹的基于消息的解决方案通常会忽略这种级别的可见性和操作控制。

我甚至看到公司更进一步，使用工作流引擎而不是消息传递中间件来在微服务之间分配工作。如果工作流引擎不主动调用服务或发送消息（称为推送原则）但依赖于工作者要求工作（称为拉取原则），则这是可能的。现在，工作流引擎中的工作队列就像一个消息队列。当我问他们为什么喜欢工作流引擎时，他们说消息传递解决方案缺乏相同的可见性和工具质量，他们希望避免构建自己的操作工具。

3.分布式交易很难

 

事务是以全有或全无的方式执行的一系列操作。我们都从数据库中知道这一点。您开始一个事务，做一些事情，然后提交或回滚事务。这些事务称为ACID：原子，一致，隔离和持久。

在分布式系统中，您不能指望ACID事务。是的，有像XA这样的协议实现了所谓的两阶段提交。或WS-AtomicTransaction。或像Google Spanner这样复杂的实施。但目前的共识是，这些协议太昂贵，太复杂，或者根本无法扩展。 Pat Helland的“超越分布式交易的生活：Apostate的意见”是一个很好的背景阅读。

但当然，商业交易的要求并没有消失。在没有ACID的情况下解决业务交易的常见技巧是使用补偿。这意味着您可以对过去不正确执行的所有活动执行撤消活动。 BPMN具有此内置功能，因此您可以定义这些撤消活动，并且工作流引擎负责以正确的顺序可靠地执行它们。这次我将使用预订机票的例子：

 

这通常也被称为Saga模式，最近变得非常流行。我在“Saga：如何在没有两阶段提交的情况下实现复杂的业务交易”中写到了这一点，其中我还链接了其他来源和一些代码。

请注意，此方法与ACID事务不同，因为您可以具有不一致的中间状态。所以，我可以保留一个座位，但尚未预订有效的机票。或者我可以在没有付款的情况下买票。实际情况是，只要确保最终清理它们并使系统恢复到一致状态，通常可以忍受这些暂时的不一致。这称为最终一致性，这是分布式系统中的一个重要概念。 “在SoA网络中拥抱最终的一致性”指出它非常好：

最终的一致性通常会产生更好的性能，更简单的操作和更好的可伸缩性，同时要求程序员理解更复杂的数据模型。

好消息是工作流程自动化简化了补偿的处理。这是因为工作流引擎可以可靠地调用所有必要的补偿活动。

服务提供商 - 做好功课！

到目前为止，我已经提出了三种简单的补救措施来应对分布式系

1. 重试
2. 超时
3. 赔偿金

所有这些都可以使用轻量级工作流自动化技术实现。但是为了利用这些配方，每个服务提供商都必须做好功课。这意味着

1. 提供补偿活动和
2. 实现幂等性。

 

虽然第一个要求应该是显而易见的（如果有取消票证的服务，我只能取消票证），第二个 - 幂等性 - 需要更多解释。

幂等

我谈了很多关于重试的事情。一个常见的问题是，如果我通过重试两次调用服务怎么办？这个问题问得好！

首先要确保您了解每种形式的远程通信都会遇到此问题！无论何时通过网络进行通信，都无法区分三种故障情形：

1. 该请求尚未到达提供商
2. 请求已到达提供商，但在处理期间它已爆炸
3. 提供程序处理了请求，但响应丢失了

 

一种可能性是询问服务提供商是否已经看到此请求。但更常见的方法是使用重试并以允许重复调用的方式实现服务提供程序。这更容易设置。

我看到两种简单的方法来掌握幂等性：

1. 自然的幂等性。有些方法可以随意执行，因为它们只是翻转一些状态。示例：confirmCustomer（）
2. 商业幂等。有时，您拥有允许您检测重复呼叫的业务标识符。示例：createCustomer（email）

如果这些方法不起作用，您需要添加自己的幂等性处理：

1. 唯一身份。您可以生成唯一标识符并将其添加到呼叫中。这样，如果您在服务提供商端存储该ID，则可以轻松发现重复呼叫。如果您利用工作流引擎，您可能会让它完成繁重的工作（例如，当Camunda允许在启动期间对密钥进行重复检查时）。示例：charge（transactionId，amount）
2. 请求哈希。如果您使用消息传递，则可以通过存储消息的哈希值来执行相同的操作。您可以再次利用工作流引擎，或者您可以使用具有内置租赁功能的数据库（如Redis）。

长话短说：在您的服务中注意幂等性。这将带来巨大的回报。

给我看一下代码

您可以使用BPMN和开源Camunda引擎找到实现我在此描述的模式的源代码

Java或C＃。(需要的后台发消息)

摘要

在本文中，我介绍了三个常见的陷阱，我看到客户在整合微服务时踩到了：低估了远程通信的复杂性，忽略了异步性的挑战，忘记了商业交易。

通过重试，超时和补偿活动的状态模式引入处理这些情况的功能可以降低微服务基础架构的整体复杂性并增强其弹性。它还有助于：

1. 将重要的故障处理和事务行为封装在它所属的位置：在服务本身的上下文中。
2. 将故障或超时处理的工作量减少到更小的范围，从而降低整体复杂性。
3. 简化服务API，只发布对客户真正重要的故障。
4. 改善客户体验，客户可能是其他服务，内部员工，甚至是客户。

使用轻量级工作流引擎，您可以通过应用自行开发的解决方案来处理有状态模式，而无需投入大量精力或冒着意外复杂性的风险。随附的源代码提供了具体示例。