语言 Chinese, Simplified

SEO Title

Panel: Event Driven Architectures of Scale

赖斯：欢迎来到我们关于架构的专题小组，你们一直想知道轨道。该专题小组称为事件驱动的大规模架构。当您思考事件驱动架构时，您会想到什么？这是规模、性能和灵活性的好处吗？也许你想到了一个你可能经历过的特殊问题。也许你从技术的角度来考虑，比如说无服务器，或者流处理，比如Kafka？不管您如何看待事件驱动的架构，您可能有一些问题。我们将深入探讨事件驱动系统的主题，我们将与一个专家小组进行讨论，他们一直在大规模地操作这些系统，并且拥有丰富的经验。

我和三位软件领域的杰出领导者一起工作。他们来自操作当今软件中一些最大和最知名系统的地方。

背景

我叫韦斯·赖斯。我是VMware的平台架构师，在Tanzu上工作。我主持QCON旧金山软件会议。我很幸运能成为InfoQ播客的共同主持人之一。

格温，我想让你做的是自我介绍，也许可以谈谈你建立的系统。那么，您是如何在事件驱动上着陆的？什么风把你吹来了？

沙皮拉：基本上，我是一名软件工程师，是Confluent的首席工程师。我领导云端本地Kafka团队。我们将Kafka作为一项面向客户的大规模服务。在那之前，我是一名工程师，是阿帕奇·Kafka的提交人。

Confluent是如何在事件驱动架构上实现的

基本上，在我们尝试了所有其他方法之后，我们以事件驱动的方式着陆。不是那样的。我花了很多时间与已经在使用Kafka进行事件驱动的客户在一起。我必须与我的客户一起学习模式，以及他们如何解决问题。它解决了什么问题。它创造了什么。然后当我开始管理云中的Kafka时，我们发现自己有一块巨石(monolith)，我们知道我们必须解决它。你总是从一块巨石开始。他们写得很快。我们知道我们想要更好的东西，我们有很多不同的选择。真正让我们成为事件驱动型的是，它让我们避免了团队之间的指责，因为一切都是通过事件进行的。它永远被记录下来。如果需要，您可以在登台环境中查看发送了哪些消息，并重构系统的整个逻辑流。如果您在生产中看到了一些东西，而不是您所期望的，那么您实际上可以了解整个事件主题，并了解在另一个系统中发生了什么。对我们来说，这是巨大的。这不是我的责任，你的责任。我们必须非常明确，这是你拥有的。这些是你对事件的反应，我们可以从中吸取教训。

赖斯：不过，这也带来了很多其他问题，比如事情对所有这些事件的实际反应以及它们是如何编排的。伊恩，你呢？

背景，以及PokerStars sports是如何在事件驱动架构上实现的

托马斯：我是一名高级首席工程师，在弗利特(Flutter )国际公司工作，这是我七年前开始的一份工作的化身，在天空投注公司工作。我从事博彩业。这些年来，我一直致力于天空投注，投注，现在横向扑克明星体育。从事件驱动的角度来看，我有几个不同的角度。我很有兴趣了解更多关于我自己的一个方面是PokerStars多年来的发展，因为这是最大的实时事件驱动系统之一，我认为可能存在于这个地方。

我在2014年加入了天空赌局(Sky Bet back)。当时我们采用的主要方式是从一个单片系统（一个庞大的Informix数据库）中提取数据，并将其分发给组织内的工程团队，以允许他们控制数据，然后他们可以构建可扩展的前端。从那以后，我一直致力于各种其他系统的化身，包括一些由Kafka支持的系统，这些系统非常成功。看看我们如何实际使用它来管理自己的状态，这是一个非常有趣的旅程。有很多不同的角度。我最近一直在做的一件事是研究我们如何在前端使用实时事件，并将扑克传统应用到体育博彩和游戏中。

背景，以及BBC是如何在事件驱动架构上着陆的

克拉克：我是马修。我是英国广播公司的架构主管。我相信大家都知道BBC。我们有几十个网站和应用程序，有了这些，我们就有了数百项服务。这是一个相当广泛的事情。保持领先是很有趣的，但是有很多微服务思维和基于云的思维，所以基于事件的架构必须属于这一类。这不是教条式的事情。并不是说我们在任何地方都使用它。基于大量时间请求的系统是更好的解决方案。一直以来都有这些优点和缺点。基于事件的方法必须在它有很多优势的地方发挥作用。从根本上说，如果你有一个搜索引擎或推荐引擎之类的东西，它不会自己填满。您需要这些事件进入并填充它，因此它成为一个好的服务。

使用事件驱动系统时了解域模型的重要性

Reisz：我首先想问的问题之一，可能只是一些你进入事件驱动系统时没有想到的事情，一些让你大吃一惊的事情。这是你旅程的早期。我将从我自己的角度给你举一个例子。我发现当我使用事件驱动系统时，它有点难。在我参与之前，我必须非常了解这个领域，才能真正理解正在发生的舞蹈编排。格温，你谈了一些舞蹈和编曲。例如，当您使用事件驱动系统时，真正了解域模型的重要性是什么？

夏皮拉：尤其是作为一个试图为其他团队提供建议的架构师，你还必须知道你不知道的东西。你的很多工作就是划清这件事的界限，然后说，这是你所拥有的，不要走出去。如果你想在你发送的信息之外做点什么，别人会拥有它。相信他们做正确的事情，他们拥有自己的领域。文化和架构是如何协同工作的，这很有趣，因为如果你试图编写一个协调的系统而不是编舞，你实际上必须了解每个人的逻辑。你就是那个，我会打电话给你，这会发生的。然后我们再叫另一件事。如果这失败了，我就不得不称之为另一件事。我觉得，在很多方面，舞蹈文化意味着你是你领域的专家，你定义了界限。那么你就不必担心其他领域了。还有其他专家，你可以相信他们。我认为这是一种良好的公司文化。

事件驱动系统带来的惊喜

Reisz:Ian，当你从一个更经典的单片系统开始使用事件驱动系统时，有哪些事情让你感到惊讶？

托马斯：我认为大的一次似乎一次又一次地出现，从这个同步的东西到有时间轴的东西也要考虑。特别是当您有可能不同的数据源，或不同的数据生产者，并且思考，这是否真的发生在这之前？我该怎么处理？然后，从这一点开始思考，如果我看到这个事件两次会发生什么？如果我从未见过它会发生什么？我如何协调时间过后的一致性？如果你仅仅从人们从同步编程模型到异步编程模型的角度来看待它，你可以看到到处都是这种情况，就在一个整体中。你也有类似的情况。当这些数据也分布在不同的系统中时，您需要了解，我如何去检查这些数据，或者如何在另一个系统中看到这些数据，或者如何回放日志？这很有挑战性。我会说是的，可能是时间因素。

瑞兹：马修，有什么想法吗？

克拉克：是的，我同意你所说的。是的，了解事物的状态，你是否失去了什么，你是否有比赛条件，这些事情变得非常困难，非常坚毅，绝对。我们谈论无状态是一个多么美妙的范例。您可以通过无服务器功能实现这一点。你需要关心，你只需要担心当下的时刻。然而在一个事件驱动的世界里，你有你的微服务，它有很多状态。它收到了很多活动。如果你失去了一些，你就有麻烦了。它可能不得不把它传给其他东西。如果失败了，或者需要重新部署或其他什么，会发生什么？突然间，你看了看，这不是一个小问题。这不是梦想。当我从我非常满意的经典restapi转移过来时，它非常简单，突然间这不是灵丹妙药，是吗？它有各种各样的挑战。

如何处理无序事件

Reisz：人们想学习的一个问题是如何处理那些无序事件。伊恩，你说了一点关于必须处理不同时间发生的不同事件。您如何处理这样一种想法，即该事件可能不一定以这种同步事件顺序出现？你怎么处理这样的事情？

托马斯：对我们来说，当我们看到这一点时，最重要的地方是下注的位置，也就是说，有人真的在你身上花了一些钱。被抛来抛去的关键词是幂等性，确保你的事件可以在没有严重后果的情况下重演，特别是财务方面。这是一个真正的教育案例，所以要理解这是一种可能性，并在设计系统时牢记这一点，就像大多数事情一样。我们有很多事情需要考虑，如果我们多次遇到这个事件，我们如何丢弃这些东西？如果我们没有看到它，我们如何回放或将新事件推送到系统中，以尝试获得正确的一致性？然后，我们的一些运营人员对我们最大的一个阻碍是，在生产中这样做是对还是错，或者你做了什么。你自己决定吧。如果您有一个数据库，并且您的数据不一致，那么您至少有能力进入并调整它。您可以运行一些SQL命令。“我可以解决这个问题。”当你依靠回放的事件日志时，你必须考虑控制平面是什么样的？我用什么方法使自己恢复良好状态？

回到一个好的，已知的状态

瑞兹：格温，你有什么建议让人们考虑让自己回到一个众所周知的状态？

沙皮拉：我非常相信确保一切都是幂等的。你再往回走一点，相信如果你重播，它不会让你陷入更糟糕的状态。在我看来，真正做异步事件的最大障碍，并不是异步事件真的那么难，而是人们在内心深处没有接受这是唯一的方法。做一些同步的事情，做一些可扩展的事情，做一些性能好的事情，基本上你不会得到这三个。它可以是同步的、高性能的，但不能扩展。您可以同步并尝试扩展，但您将拥有非常大的队列。它不会有太多的表现。如果您想要性能和可扩展的东西，您必须是异步的。一旦你开始走，我就得走了。那么，真的，有一个幂等事件有那么难吗？通常没那么难。只是你必须，我在一个新的世界里，我不想用新的工具创造我的旧世界。事实上，我现在身处一个新世界。

编舞与精心编曲（Choreography vs well-defined orchestration）

Reisz:Nandip问了一个关于定义良好的业务流程的问题。当我看到这篇文章时，我读到的是编舞与配器，回到我们之前讨论的内容。是否总是有这样一种情况，即一切都应该是编舞，或者是否有这样一种情况，即我们需要有单独步骤的定义良好的编排？马太福音？

克拉克：从来没有一个正确的答案。我们有两种方法。有时您可以使用编排设置来操作它，有时则不能。我们之前说过的是，假设您在某个时候会被重放，无论您使用什么，您都会在事件驱动的消息中发现bug，例如，您需要重放内容的地方。即使您的技术非常擅长在正确的位置发布正确的内容，并保证至少一次一致性，您也必须在某个时候处理内容的重复，因为这只是您工作的一部分。

瑞兹：伊恩，格温，有什么想法吗？

托马斯：我真的很喜欢燕翠，他在这一点上做出了妥协，这是在一个有界的背景下，编曲可能是正确的选择。当你观察不同环境之间的交流时，事件驱动的编舞才真正开始发挥作用，而且它很强大。当然，这还不是一个完全的扣篮。我认为这可能是一个很好的定义起点。

赖斯：那是个好主意。燕翠，这也正是我的想法。他有一篇很好的博文，如果你想更多地了解这两者之间的区别的话，可以深入探讨这一点。

在Kafka架构上分离事件和创建主题

格温，这里有一个问题是关于分离事件，以及你如何真正开始思考你的话题。当有人走到你面前，问你关于分离事件和创建Kafka架构主题的问题时，你如何与他们谈论这一点？你让他们想些什么？你告诉他们要考虑什么？

夏皮拉：这很有趣，因为我过去常常回答数据库的问题，这个积分应该是什么，什么应该是分离维度。感觉就像是同样的事情不断重演。首先，就像得到一本关于数据建模的好的、非常古老的书一样，基本上不会有什么伤害，就像建模就是建模一样。你有一本领域驱动的设计书。另一方面，您有一个老式的数据仓库建模或数据建模系统。在Kafka中，您需要考虑的是一些规模要求。这就是它所做的稍微不同的事情。如果某个事件非常常见，那么您可能希望将主要度量和度量主题与稍微不常见的内容分开。因为它们可能会被单独处理，你会希望在不同的时间内对它们做出反应。另一件重要的事情是排序保证，这在数据库中是不会发生的。如果内容在不同的主题中，那么您将无法控制它们的顺序。它们可以按任何顺序处理，你需要对此表示同意。如果你想让事情有一个顺序，你把它们放在同一个分区的同一个主题上，你就有了这个完整的顺序，它就在那里。那么很多只是业务逻辑。我看到一个关于一个事件应该有多大的问题经过。这就像一个函数应该有多大。如果它变得过大，可能是一种气味。一天结束时，你的模型有好的边界吗？在您的企业中，事件是真实世界的事件吗？它是否与正在进行的某项业务保持一致？这是主要考虑因素。你不想用不同的方式人为地把东西切碎吗？

托马斯：我们曾经与工程师们进行过很多对话，他们专门关注Kafka和Kafka流，了解主题设计如何影响他们的流，因为有很多长期影响。特别是，如果您使用它来存储状态和压缩主题。人们从一开始就设置了错误数量的分区。

Shapira：有一件事我要提醒周围的人，也要提醒内部和我的云管理者，你们不想把暂时的限制变成一种宗教。如果你认为某件事是正确的商业行为，但你必须做出妥协，因为技术迫使妥协，你想非常清楚地记录我们想要做X，但实际上这是不可能的。因为那时你不知道，也许一年后X将成为可能，你可以回到它。例如，Kafka过去的分区数量是有限的。它早就消失了，而且正在变得更加消失。人们围绕它设计了整个世界的意识形态，很难说，你这样做是因为它是正确的，还是因为你相信事实上已经不存在的局限性。

赖斯：伊恩，我想让你双击一下。你说你的主题设计的长期影响，比如什么？再多描述一下？

Thomas：有时候，考虑到根据事实改变事情是多么容易，并考虑到您可能需要的吞吐量，这有点幼稚。对于Gwen在那里提到的事件大小，如果您的事件太大，那么您想要的复制模型以及在代理之间要发送的通信量就会出现问题。对我们来说，最主要的是，如果我们把状态保存在一个压缩的主题中，然后你突然意识到，等等，我们没有足够的分区来支持我们现在所拥有的吞吐量，因为这已经增加了。如果您尝试扩展，则所有这些以前的事件都将位于错误的分区上。你必须和这样的人一起玩，如果你将来需要的话，你打算如何扩大规模？您知道您现在选择的约束条件是什么吗？

我们倾向于尝试在Amazon 1型和2型框架中建模。比如，这是你现在就可以做而不用担心的事情吗？它在未来很容易改变吗？我认为，如果你不一定对系统的工作原理或者你正在使用的实际技术有足够的了解，你就不可能在没有真正意义的情况下很容易地把一个2型的东西变成一个1型的东西。它可以确保人们意识到这是一个限制，在设计系统以及如何通过这项技术放置数据时，请记住这一点。

克拉克：事实上，我发现即使是伟大的1型，2型，这个想法，这是一个可逆的决定吗？这是我在事件驱动架构中遇到的挑战之一。它会把你锁在以后很难改变的事情里。一旦有多个客户机正在接受您的事件，更改事件格式就变得非常棘手了。您希望可以在客户不关心的情况下向JSON或其他任何内容添加新字段，但这样做总是让人感到非常紧张。我想我们还没弄清楚你是怎么处理的。

夏皮拉：这方面有一整本书。格雷格·杨的书。

瑞兹：让我们谈谈这个，格温，因为有一些问题出现了。你如何解决这样的问题？

格温，你说的是一本书？

夏皮拉：是的。这是格雷格·杨的作品。他写了一整本关于事件版本控制的书，这表明这不是一个容易的问题，我现在不打算在五分钟内为你们解决它。Kafka以其对稳定的狂热而闻名于世。你可以像一个0.8的经纪人、一个3.0的制作人和一个1.0的消费者那样，让一切都运转起来。它的代价是你进化的速度极其缓慢。如果每个客户端和每个应用程序都有一个大的，如果你得到版本1的事件，如果你得到版本2的事件，这是非常不神奇的。

第2天，与事件驱动系统相关的问题

Reisz：今天早上，Katharina Probst在她的主旨演讲中提到了一系列针对微服务的第二天操作。她列举了一些事情，比如负载测试、混沌工程、AIOps监控。当我们谈论事件驱动系统时，您需要考虑哪些第二天的问题？例如，您谈到了版本控制。什么是你需要思考的事情，也许你真的没有考虑过？

克拉克：我想到的是一对夫妇，斯凯尔绝对是其中之一。如果大量事件已重新发布，会发生什么情况？通常，你会发现，如果你是一个微服务所有者，你可能会发现你的一个攻击性玩家突然出于任何原因选择发布东西。也许他们有个臭虫什么的。你需要有能力处理这件事。或者，至少，您前面可能有一个队列，您可以从中处理积压工作。您不希望积压工作持续很长时间。你有一个有趣的规模挑战，从任何地方，所有的交通可以来自所有这些事件。事实上，你正在存储状态，你是如何存储状态的？如果你重新部署自己会怎么样？你确定在这些时刻你没有掉东西吗？

赖斯：伊恩，你的想法是什么？

托马斯：我完全同意这两个观点。也许随着时间的推移，我注意到的其中一个问题是第二天过去了，但更像是第600天，当构建系统的人继续前进时，人们害怕新的人进来，试图弄清楚这件事是如何运作的，无法改变事情，并且感到担忧。很多都像你在开始时提到的，领域，以及它是如何记录的？人们是如何改变事情的？实际上，冷淡地尝试采用这个系统，并使其适应公司当前的需求是什么样的？

瑞兹：格温，你有什么想法吗？

夏皮拉：是的，我觉得我的第二天活动，我们应该在第0天完成，诸如此类的事情。测试框架，您拥有所有这些微服务，您将独立升级它们。人们都在谈论建立信心，所以你真的要做一个改变，你想有一个测试框架，运行时间不会太长，也许一两个小时，但不会太长。B、大多数情况下都会通过。它每天应该很少有绿色建筑。第三，相当容易使用、发展和诊断。我在第二天发现，实际上升级和发布都很困难，因为我们没有一个很好的测试框架，现在我们必须基本上停止一系列生产项目，重新开始。我们有50，60个服务，我们甚至没有那么大，我们如何实际测试不断发展的场景，所有这些场景，以确信我们没有破坏其他任何东西？

事件驱动系统的监测和可观测性

赖斯：这里有一大堆关于可观察性、监控和诸如此类的问题。我想换个话题，给你们每个人一个机会谈谈可观察性、监控事件驱动系统和任何工具的重要性。我想，伊恩，当我们交换一些电子邮件时，你谈到了第二天的想法，实际上是在你正在使用的东西中加入一些监控类型的工具。我很想知道，你们每个人关于监控事件驱动系统的一些提示、技巧和想法。

托马斯：其中一些给我们带来最大价值的东西是添加跟踪，以便在消息和记录通过系统的各个部分时能够看到它们的生命周期。再加上Kibana这样的工具，可以非常强大地准确地理解事物是如何在X应用程序上移动的。我们经常被问到的一个问题是，我们看到了吗？有一件事你并不总是有奢侈的是，你是制片人，这是事件的来源。对于我们来说，我们从第三方供应商那里获取了大量数据，这些供应商在足球比赛中有球探并发布更新，我们只是不太知道，这种情况发生了吗？我们应该看到这场足球赛的比分达到了3-0，或者别的什么，但是我们没有那种状态，所以我们看到了什么比赛，什么顺序？我们构建了一些工具，使我们能够真正快速地进入生产箱并回放一些事件。

在我们花时间围绕这一点构建内部工具之前，总是让我们绊倒的事情是，我们希望在代理和客户之间建立TLS。这是Kafka特有的。这强制了我们的ACL，所以您可能没有查看特定主题的权限，您必须考虑一下，您在那里做什么。如果您确实有一些调试工具，请确保您不会干扰实际的生产客户，这样他们就不会到处乱打，并且确保您正在考虑它实际上会如何影响工作系统。然后，如果我们需要提取数据，通常情况下，我不知道每个人的系统是否都不同，因此我们有多个级别的跳转帖子来联系实际的Kafka经纪人。然后你会想，我如何从中提取有用的信息，然后把它拿走，在PIR中分类，或者类似的东西？归根结底是这样的，直到你需要它们，你才真正发现你的需求，这就是确保你已经把时间放在一边，把精力放在构建你需要的东西上。

赖斯：你的里程数可能会有所不同。绝对地Matthew，你们在可观察性方面学到的任何东西都可能是对其他人的好建议。

克拉克：正如伊恩所说，追踪真的很好，不是吗？我们在Amazon X-Ray上做了很多工作，效果非常好。然后，在每一个微服务级别上，您都能正确地记录日志，以便能够诊断哪里存在问题。只要你在每一个微服务之间都有一些经纪人，不管是Kafka，还是动情，或者其他什么，那么你就有希望发现并分离出让你失望的微服务，并尽快解决它。

瑞兹：格温，你有什么消息吗？

沙皮拉：我要补充的唯一一件事可能是采样的想法，你可以有一个外部系统来对一些事件进行采样，特别是如果正在进行的一切都是非常大规模的。然后，在后台仔细检查是否存在异常值，并确保没有任何意外情况，比如事物不会过大。伊恩刚刚对它说，你知道你的数据的形状应该是什么样的。这就是你如何检测我们是否应该看到它，而它不在这里，诸如此类的事情。我们也知道，我们不应该期望一秒钟内有许多授权尝试。如果我们明白了，可能是出了严重的问题。我们已经建立了这个系统，它在后台运行，并对样本的一些规则进行了双重检查。我认为这对我们很有帮助。

从战争故事中吸取的教训

瑞兹：格温，我要从你开始谈这件事，因为我想你已经提到了一件。对于不同的战争故事有很多要求，这让你学到了一些不同的课程。你从一些战争故事中学到了什么教训？告诉我们关于战争的故事，也许还有教训？

Shapira：我认为这与前面的版本控制讨论有关。我们基本上想升级很多东西。我们有大约1000个单一服务类型的实例，我们只想升级它们。这是一个无状态的服务，这使它变得简单。我们刚刚通过我们的管道推送了大约1000个升级事件，希望所有事件都能得到处理，其中997个能够随着时间的推移自行升级，而3个不会。我们甚至不知道为什么。活动即将开始，一切看起来都很好。我们有痕迹。我们到处都有原木。最终，我们发现这是我们最古老的三项服务，基本上就像我们拥有的前三个客户一样，可以追溯到2017年。他们有一些不同的授权密钥，阻止他们下载这些他们需要下载的东西来升级自己。甚至没有人确切记得钥匙是怎么到那里的。显然，这是一个不同类型的事件。才三点。我们最终野蛮地强迫他们。这类事情，即使你对进化非常小心，比如一步一步地进化成一个系统，它将与2017年发生的任何事情完全不兼容，甚至没有人记得。我认为这里的主要教训就是不要有任何悬而未决的东西。每三个月、六个月都要升级一次，如果你在做什么项目时没有太多的变动，那么可能还要再升级一点。

瑞兹：伊恩，你呢，告诉我们一些战争故事？

托马斯：当你问这个问题时，我突然想到了一对夫妇。他们都是几年前的人，所以我不认为我说这些话伤害了任何人的感情。其中一个是关于事件的大小，或者更确切地说是与事件相关的事物的大小。在Sky Bet上，构建页面的方法之一是，从Informix流出的信息流经过各种rabbitmq，然后由节点处理，最终存储在Mongo文档中。由于更新发生的方式，我们倾向于从Mongo读取文档，找出这对文档意味着什么，然后将其写回。这种逻辑中存在一个缺陷，这意味着我们从未真正从Mongo文档中删除过内容。因为它是一个主页，我想它是网站上的赛马主页，它只是逐渐变大了。虽然这并不明显，但不幸的是，当该网站在节礼日（在英国，这是一个体育博彩的大日子）宕机时，所有这些事情都出了问题。我们不知道为什么。这基本上是因为我们频繁地从Mongo中提取文档，从而使我们的网络饱和，以至于我们无法再实际处理它。那是非常有趣的一天。

我能想到的另一个问题是，很难解决，可能涉及到与Kafka合作的最佳实践，那就是我们有两个制作人的情况非常奇怪，所以这很简单。我们有两个制作人编写一个主题，但具有相同密钥的记录最终出现在不同的分区上。其中一个基本上是一个节点应用程序，另一个是用Kotlin编写的。密钥的使用方式和用于生成实际分区散列的数据类型意味着整数在Kotlin中使用，因此溢出。它实际上是在生成与Node.js不同的散列。那是一个相当不错的一天，寻找它。

夏皮拉：你是怎么发现的？

托马斯：我不记得了。那是几年前的事了。我们只是在这些节目中逐行播放，有什么不同？我们最后得出的唯一结论是这一个是节点，而那一个基本上就是JVM。实现中可能有什么不同？这只是一个数字。

夏皮拉：你是怎么发现的？

第二天，关于操作事件驱动系统的建议

Reisz：我想把重点放在第二天，如果你能和某人坐下来，就第二天或事件驱动系统的长期运行给他们一点建议。我们一直在谈论Kafka。你有什么建议？不一定非要和Kafka在一起？你有什么建议吗？

克拉克：尽你最大的努力让事情尽可能简单，因为这些事情变得如此复杂真是不可思议。如果我们有时间的话，我会说的故事是，我们如何有一个时刻，所有这些不同的系统在做所有这些不同的事件，如果我们将这些事件标准化，并将它们放在一起，并将所有事件作为一个超级主题，这不是很好吗？当然，那是个糟糕的主意。因为它们都有不同的属性，以不同的方式扩展，以不同的方式需要。就像微服务的概念一样，让事情分开，让事情简单。不要以为事件驱动就是答案，因为它是一个很好的解决方案，但并不总是正确的解决方案。请注意，它可能不像最初看起来那么简单。

不是事件驱动系统的最佳系统

Reisz：对于事件驱动系统，哪些系统可能不是最好的？你有什么想法吗，马修？

克拉克：从根本上说，如果你是一个面向用户的东西，它会以一个请求结束，不是吗？一个用户出现了，给我一个东西。在某个时刻，您的事件必须转变为请求。这一切都是为了找出它在哪里。在英国广播公司，我们更喜欢有它，所以实际上我们会根据用户的到来做很多请求，这样我们就可以回应他们是谁。我们希望在这方面充满活力。这是一个例子。你不能现实地提前准备，因为你想对当下做出反应。

对于事件驱动系统和第二天推荐来说，不太好的事情

赖斯：伊恩，哪些东西不是伟大的事件驱动系统？那么，第二天你对某人的建议是什么？

托马斯：不好的事情？我认为考虑它的一个好方法是，如果我有一个工作流，你希望能够识别该工作流中的所有步骤，并将其作为一个深思熟虑的实体加以关注。这是一种很好的编排方式，而不是事件驱动。我的建议与此类似，不要强制在不需要的地方安装它，但在设计数据时也要非常慎重，以允许其不断发展。请记住，您选择的实现方式。你需要SNS、SQS还是运动？考虑一下您正在使用和设计的实际代理和系统的约束，而不是针对它们。

什么时候不使用事件驱动？我几乎可以这样说，从节点开始，寻找需要这种可靠性水平或重放能力的地方，以及真正强大的大规模解耦。基本上，请注意什么时候需要事件驱动而不是启动程序，因为我确实觉得它增加了一层复杂性，可能你永远都无法实现，谁知道呢？也许你的创业不会那么成功。

就第二天而言，我会稍微为自己着想，并说你确实可以选择不以自己的身份排名。它只是消除了一系列的痛苦，然后把它交给一个实际上相当兴奋和乐意照顾它的人。我认为这在总体上是正确的，就像我们不做自己的监控一样。我们有一群第三方提供商为我们进行监控。我们不经营我们自己的Kubernetes，我们用AKS，EKS，GKE来做这些。是的，基本上，偶尔有一些你不必担心的事情是很好的。

原文：https://www.infoq.com/presentations/eda-scale-panel/

本文：http://jiagoushi.pro/node/1535