远程通信|「微服务架构」微服务集成中的3个常见缺陷-以及如何避免它们( 二 ) 微服务风靡一时。他们有一个

虽然这开始非常简单，但通常会导致很多意外的复杂性。您不仅需要数据库表，还需要一些调度程序组件来进行重试。您可能需要一些监视组件来查看或编辑等待作业。如果整体业务逻辑发生变化，您仍需要进行版本控制，而您仍想进行重试。等等等等。
这种思路导致许多开发人员如上所述跳过正确的故障处理，导致整个架构的复杂性增加 - 以及糟糕的客户体验。
相反，我建议利用轻量级工作流引擎或状态机。
构建这些引擎是为了保持持久状态并处理围绕流语言，监视和操作的后续要求，扩展以处理高容量等等。
市场上有几个轻量级工作流引擎。他们中的许多人使用ISO标准BPMN来定义流，其中许多是开源的。在这里，我将使用Camunda的开源工作流引擎来说明基本原则（快速免责声明：作为该项目背后的公司的共同创始人，我明显偏向于我的工具选择，但这是我最熟悉的工作流引擎）。对于前面描述的简单用例，可以使用Java DSL轻松创建工作流：
另一种选择是在BPMN中以图形方式建模工作流程：
文章插图
这些工作流引擎在架构方面非常灵活。许多开发人员认为工作流引擎是一个集中组件，但事实并非如此。没有必要引入集中组件！如果不同的服务需要工作流引擎，则每个服务都可以运行自己的引擎来维护服务的自治和隔离。本博文中有关架构选项的更多细节将对此进行详细讨论。
文章插图
另一个误解是工作流迫使开发人员切换到异步处理。这也不是真的。在上面的示例中，当一切顺利运行时，登记组件可以同步返回登机牌。只有在出现错误时才会回退到异步处理。这可以很容易地反映为HTTP返回码， 200表示“一切正常，这是你的结果” ， 202表示“得到它，我会给你回电话。 ”有一些具体的示例代码来处理这个，它利用了一个简单的信号。
文章插图
我将工作流引擎视为工具箱的重要组成部分，用于正确的故障处理，这通常涉及长期运行的行为，如状态重试。
2.异步性需要注意
文章插图
这导致我们进行异步通信，这通常意味着消息传递。异步性通常被认为是分布式系统中的最佳默认值，因为它提供了解耦，尤其是时间解耦，因为任何消息都可以独立于接收器的可用性发送。一旦服务提供商可用，该消息将立即发送，而无需额外的魔力。
因此，重试的问题已经过时，但会出现类似的问题：您必须担心超时问题。假设航空公司在登记方案中使用异步通信。登记组件向条形码生成服务发送消息，然后等待响应。您无需关心条形码生成器的可用性，因为消息总线将在适当的时候传递消息。
但是，如果请求或响应因任何原因而丢失怎么办？您是否会在办理登机手续时遇到困难，未能在没有注意到的情况下将登机牌发送给客户？我打赌很多公司这样做，这再次导致我，客户监控响应并采取行动，如果没有登机牌在超时内到达。同样，我必须利用我的个人调度基础设施（日历）。
文章插图
更好的方法是让服务监控超时本身，并在条形码未能及时到达时执行回退。可能的后备是重新发送消息，这实质上是重试。
您也可以利用工作流自动化技术来处理此用例。BPMN中的工作流可能如下所示：
文章插图
作为奖励，您可以免费报告重试次数，典型响应时间以及无法及时处理的工作流程数量。操作员可以通过提供大量上下文来轻松检查和修复失败的工作流实例，例如消息中包含的数据以及消息发送的时间。纯粹的基于消息的解决方案通常会忽略这种级别的可见性和操作控制。
我甚至看到公司更进一步，使用工作流引擎而不是消息传递中间件来在微服务之间分配工作。如果工作流引擎不主动调用服务或发送消息（称为推送原则）但依赖于工作者要求工作（称为拉取原则），则这是可能的。现在，工作流引擎中的工作队列就像一个消息队列。当我问他们为什么喜欢工作流引擎时，他们说消息传递解决方案缺乏相同的可见性和工具质量，他们希望避免构建自己的操作工具。