第 9 章. 工作流引擎与集成挑战
本作品已使用人工智能进行翻译。欢迎您提供反馈和意见:translation-feedback@oreilly.com
现代系统的设计方式通常是将组件安装在不同的计算机、虚拟机或容器上。连接这些组件需要远程通信,这就带来了许多新的挑战。
本章将介绍如何利用工作流引擎应对其中的一些挑战。在这方面,它
-
研究服务调用的通信模式,特别是长期运行和异步通信
-
探讨一致性问题和事务保证
-
强调幂等性对实现所有这些目标的重要性
即使你不打算使用微服务架构,阅读本章仍然会很有价值,因为几乎每个系统的某个地方都有一些远程调用。即使只是一个简单的 REST 调用,这里描述的概念也适用。
服务调用的通信模式
从进程中调用服务时,可能会有不同的通信模式。在深入研究异步通信之前,我们先来看看同步通信。
同步请求/响应
同步请求/响应的典型示例就是 REST 调用。为了在 BPMN 流程模型中调用这样的 REST 调用,我们需要利用一个服务任务,如第 3 章 "业务流程模型和符号(BPMN)"中介绍的那样。流程将在此服务任务中等待,直到 REST 调用返回响应(如图 9-1 所示)。
图 9-1. BPMN 可以处理与服务任务的同步通信
这种简单的服务调用可能隐藏着相当大的复杂性。远程通信本质上是不可靠的,Sun Microsystems 的 Peter Deutsch 等人所描述的分布式计算谬误就说明了这一点。远程服务可能不可用,或者响应非常缓慢。这就要求你必须让自己的服务长期运行,因为你必须等待这些服务可用或响应到达。这一点在现实中经常被遗忘,从而导致架构出现问题。
为了解释这一点,让我们从一个真实的例子开始。我准备飞往伦敦。当我收到值机邀请时,我访问了航空公司的网站,选择了我的座位,并点击按钮取回了登机牌。这在后台触发了一个同步 REST 调用。它给了我如下回复:"我们目前遇到了一些技术问题,请五分钟后再试。
我们暂且假设航空公司为这一流程的所有部分分别使用不同的服务,如图 9-2 所示。再假设这些服务通过 REST 调用进行通信。这意味着值机服务将阻塞其线程,等待条形码服务返回。但如果条形码服务没有响应,会发生什么情况呢?草图中的设计将失败处理卸载给了客户端;在本例中就是我。我必须亲自进行重试。事实上,我不得不等到第二天问题解决后才能拿到登机牌。这意味着我必须使用自己的工具来坚持重试(我的日历),以确保我不会忘记。
图 9-2. 错误通常会传播到链中第一个可以处理状态的服务;在签发登机牌的例子中,这就是人类提出的请求
航空公司为什么不自己重试呢?他们知道客户的联系数据,可以在登机牌准备就绪时异步发送登机牌。这样不仅方便得多,而且还能减少需要查看故障的组件数量,从而降低整体复杂性。
只要服务能够自行解决故障,它就封装了重要的行为。如第 7 章所述,这将使所有客户端的工作变得更轻松,API 也会变得更简洁。当然,将错误传递给客户端的行为在某些情况下也是可以的,但这应该是根据业务需求有意识做出的决定。
我在现实生活中观察到的情况并非如此。更常见的情况是,团队明白这种故障解决需要状态处理,他们不想引入这种复杂性,正如 ...
Become an O’Reilly member and get unlimited access to this title plus top books and audiobooks from O’Reilly and nearly 200 top publishers, thousands of courses curated by job role, 150+ live events each month,
and much more.
Read now
Unlock full access