如何驯服事件驱动的微服务

现代的微服务架构是事件驱动的，响应式的和编排的（与通过协调器进行集中控制相反）。这使得它们松散耦合并且易于更改。对？

TL; DR：不太容易！您将在理解和管理事件流程方面面临挑战。

[编程艺术发展Swift。 InfoWorld可以帮助您导航正在运行的东西和正在运行的东西。 | 通过InfoWorld的App Dev Report新闻通讯了解编程方面的热门话题。 ]

在本文中，我总结了我在编排微服务方面的经验，并探讨了这种方法的各种后果和挑战。我使用了客户入职的典型业务示例（取决于行业，您在开设帐户时可能会很熟悉）。我在下面的图片中使用Apache Kafka表示事件总线，但是如果您运行其他堆栈，请不要担心。相同的概念仍然适用。

精心设计的微服务

假设以下服务和事件构成了您的编排系统：

以下问题说明了该方法的主要挑战：

如何改变事件的流程？
如何避免忘记流程？您如何保持对此的理解？
如何管理SLA和总体流程的弹性？您如何识别出卡住的东西？您如何重试？您如何升级？
如何避免有线耦合（例如，信用检查必须了解客户注册信息）？

让我们研究前两个挑战，并在适当的时候解决后两个挑战。

改变事件流

假设您需要添加一张犯罪记录支票。编排系统的想法通常是，您可以添加微服务而无需更改其他任何内容。实际上，您可以添加对某些事件做出反应的刑事检查服务。但是为了理解结果，您还必须至少调整客户服务：

因此，您的编排系统没有像您期望的那样松散耦合。

通常，人们认为上述事件流是有缺陷的，因此您必须对其进行改进以解决该问题。因此，让我们尝试另一种流程：

现在，所有服务并行运行，并且客户服务负责接管所有事件。但是仍然要更改两个服务，因为您要在客户服务中处理刑事检查的结果。

不要误会我的意思。我认为不可避免地会有这些变化。我的意思是，您无法避免架构中的某种程度的耦合。构建事件驱动的系统不会神奇地消除这些要求。

看不见流程

下一个挑战是了解架构中正在发生的事情。事件驱动的系统将具有“新兴行为”，只有在运行时才会出现。您无法通过执行静态代码分析来了解此行为。 Stefan Tilkov将这种行为命名为“到底发生了什么”， Josh Wulf写道： “我们正在替换的系统使用了复杂的对等编排，需要对多个代码库进行推理才能理解。” 对此挑战的最好描述来自马丁·福勒（Martin Fowler）， “您所说的“事件驱动”是什么意思？” ：

事件通知很不错，因为它意味着耦合程度很低，并且设置起来非常简单。但是，如果确实存在运行各种事件通知的逻辑流程，则可能会出现问题。问题在于，很难看到这样的流程，因为它在任何程序文本中都不是明确的。通常，找出此流程的唯一方法是监视实时系统。这会使调试和修改此类流程变得困难。危险在于，很容易用事件通知来使系统很好地分离，而又没有意识到您不会注意到更大的流程，因此将来会遇到麻烦。该模式仍然非常有用，但是您必须小心陷阱。

在有关InfoQ的最新文章（请参阅“跨协作微服务的监视和管理工作流” ）中，我总结了一些获得监督的选项：

分布式跟踪（例如Zipkin或Jaeger）
数据湖或分析工具（例如，Elastic）
流程挖掘（例如ProM）
使用工作流自动化（例如Camunda）进行过程跟踪

正如本文所讨论的那样，分布式跟踪太技术性了，错过了业务角度，并且不能告诉您有关流程中下一步的任何信息。因此，您可能不知道手头的错误阻止了什么以及如何继续进行下去。弹性和类似的工具很棒，但是需要付出一些努力才能建立，并付出额外的努力才能提供正确的业务视角。流程挖掘通常专注于日志文件分析，而不关注事件驱动的体系结构。流程跟踪值得在这里进行讨论。

使用工作流自动化进行流程跟踪

您可以附加自己的组件以读取所有事件并跟踪某些行为。

行为可能意味着单个服务的“状态更改”：

此时，跟踪整个事件流可能很有意义：

这已经使您可以使用工作流引擎中的工具来监视SLA，例如：

但是流程跟踪的另一个巨大优势是您可以开始对某些行为（例如超时）采取行动：

现在，这提出了一个有趣的问题：如何触发重试？在上述架构中，这可能意味着重新发送启动流程的事件（需要地址检查）。但是没有上下文，这很难说。

如果我们着眼于跟踪整个事件流，那么我们将开始理解上下文，并可能对重试有更好的了解：

如果花费太长时间，您甚至可以添加一些整体超时来取消注册：

在2018年旧金山卡夫卡峰会上有关流程跟踪的讨论中（请参阅“使用卡夫卡和Zeebe进行微服务环境的监视和编排” ），我演示了这种零售流程的具体示例，该示例也可以通过代码获得。

取消甚至可能需要更复杂的逻辑，例如撤销某些活动。我在“佐贺：如何在没有两阶段提交的情况下实现复杂的业务交易”中谈到了这种情况。

这些是业务流程的第一步，因为此工作流程会积极发送事件，我们将在第二步进行调查。

管理SLA，弹性和总体流程

但首先让我们看一下此跟踪工作流程的治理。谁拥有它，并将其部署在哪里？

人们认为工作流引擎是集中的，重量级的工具。但是，这不再总是正确的。在微服务架构中，工作流引擎是一个微服务中使用的库。（我在QCon London的“分布式系统中的复杂事件流”中谈到了这一点；另请参阅“避免BPM整体。” ）

我在“微服务集成的3个常见陷阱 ”演讲中给出了一个示例（Java和Spring Boot），在该演讲中，我仅使用Camunda工作流引擎进行有状态重试（ GitHub上的源代码）。它真的很轻巧，易于使用。不需要与微服务领域相关的中央引擎或“编排”流程。

为了确定谁可以拥有这样的跟踪工作流，您需要在组织中找到某人，该人拥有入职客户的端到端业务能力。您的公司实际上应该有这个人！想要顺利进行的入职流程，关心满足SLA或要求的人，并且知道等待某些重试的时间可以接受多长时间，以及错过SLA会发生什么情况。

在我们的示例中，我可以看到客户微服务承担了该责任，或者您引入了一些入门微服务：

通过事件和命令进行耦合

我想提出另一个重要的想法。在上面的示例中，我曾经使用一个名为“需要地址检查”的事件。我经常看到这样的事件。但是实际上，这不是事件！这是变相的命令。事件通常会让某人知道发生了什么事。这是广播，您不在乎是谁接听。

当您发出诸如“需要地址检查”之类的命令时，您并没有告诉世界发生了什么，而是您希望地址检查器为您检查一些事情。最好使用check address命令使之明确。

在我看来，命令没有什么坏处，不会增加耦合。两个服务之间的每个通信都需要某种程度的耦合才能生效。根据当前的问题，在一侧而不是另一侧实现耦合可能更合适。

微服务内的编排

当您向混音中添加命令时，最终客户拥有一些编排逻辑的入职服务。但这很自然，因为该服务已经负责整个流程的重要决策，例如对超时和错误的反应。

图13.在微服务中包含业务流程以在适当的时候正确使用命令可以使我们在业务流程和编排之间取得平衡。

重要的是要认识到，这与“旧的” SOA和BPM时代截然不同。没有中央工作流引擎，也没有分离的业务流程逻辑。相反，我们仅定义具有明确业务责任的微服务。有时，这种责任涉及状态处理，因此工作流引擎派上了用场。有时命令是一种更合理的耦合方法，因此在这种情况下，微服务也会进行一些编排。同样，可以在GitHub上找到源代码中这种方法的示例。

比较耦合度

让我们回顾一下针对不同方法引入额外的犯罪记录检查的更改：

在精心设计的场景中，您可以独立于任何其他更改添加和部署刑事检查。例如，它将监听“请求注册”事件。但是在您的客户服务等待该结果并将其用于最终决定之前，将不会使用该结果。这意味着您也将不得不更改和重新部署该服务。

在精心设计的方案中，您可以独立于任何其他更改添加和部署刑事检查。检查服务不需要了解任何注册信息；只需提供适当的API，即可使用。为了使用它，您必须调整客户的入职服务，例如通过命令消息来调用它，然后等待结果事件。

这些变化非常相似，并且耦合程度实际上是相同的。作为奖励，对我而言，精心设计的方法似乎更自然，因为刑事支票现在实际上就像内部服务提供商一样，不一定了解其所有客户。

一个好的架构需要平衡编排和编排。这并非总是容易做到的，特别是因为编排通常被认为是构建灵活系统时应避免的事情。但是，具有编排系统的经验清楚地表明了这些系统的两个主要挑战：难以理解其行为以及难以更改其行为。我希望上面勾画出的示例可以帮助您理解我的思路，到目前为止，这种思路已经在围绕现代微服务架构的许多实际客户项目中运行良好。

伯恩德·鲁克（Bernd Ruecker）是卡蒙达（Camunda）的联合创始人兼首席技术专家。 他目前专注于围绕分布式系统，微服务，域驱动的设计，事件驱动的体系结构和响应系统创建新的“大工作流”范例。 在15多年的软件开发过程中，Bernd在包括T-Mobile，汉莎航空和Zalando在内的全球公司中实施了高效且可扩展的核心工作流程。 他还共同创建了各种开源工作流引擎。 在 https://medium.com/@berndruecker 上的Medium上 或在@berndruecker的Twitter上 关注他 。

新技术论坛提供了一个以前所未有的深度和广度探索和讨论新兴企业技术的场所。 选择是主观的，是基于我们对InfoWorld读者认为最重要和最感兴趣的技术的选择。 InfoWorld不接受发布的营销担保，并保留编辑所有贡献内容的权利。 将所有查询发送到 newtechforum@infoworld.com 。

From: https://www.infoworld.com/article/3391592/how-to-tame-event-driven-microservices.html