事件、流、DevOps和速度!

我要非常感谢我的朋友尼尔·艾弗里，感谢他对这次演讲的贡献。好的，那么我将开始解释为什么我一直在流式处理，以及我们在事件流的有用性方面所处的位置。世界正在改变，有些事情对我们有些人来说可能很明显，但对其他人来说却不那么明显。所以这就是为什么有些事情，我们过去做事情的方式，它们不是现在事情发生的方式，例如，事情是不断变化的。同样的事情也发生在我们的业务中，在过去，IT技术是业务的支持功能。这是一些，你知道，帮助企业运转的东西。为了发展，需要一些创新，因为很多业务都涉及到一些物理互动，所以足够好就是足够好。今天，技术就是商业，我们看到很多公司都在发展自己的核心竞争力。就像JFrog组织的SwampUp一样。我在Confluent工作，我们把技术开发作为我们的核心业务，很明显，因为我们是一家软件公司，但对于其他公司，像银行、金融机构或一些物流公司，配送技术现在是他们的核心业务。 Without implementing proper logistics and proper processes they will not exist, so this is why these days technology is all about business survival and real time is not something that is a conversation of the future or is not something that we’re not capable of doing. So real time is now. So, we were implementing these real time use cases today.
预先存在的条件。这是我们过去的组织结构图，我们可能有多个不同的业务线，多个不同的小部门，他们使用不同的软件来自动化他们的流程。为了交流，他们可能会建立一些API或者提供对数据的访问，我不知道，甚至可能访问正确的数据库之类的。这些东西都是直接或间接的沟通之前发明的海湾风险平台和允许他们沟通的东西是通过主干的，这个组织结构可能是这样的因为我们的组织中有很多链接，很多沟通发展起来以便从多个地方获取数据以便积极有效地沟通。
这不是今天的我认为,很多人意识到……他们试图分解,解开这其中一个范例是合适的——解决这个还是不解决但至少帮助使某种意义上的噪音——是事件流模式从本质上讲,允许或者改变我们的思考方式发生了事件,系统通过思考事件不像一些存储记录,而是不断更新的事件流。这个不断更新的流将包含一些关于历史的信息关于过程的进展等等。我来举个例子。所以，事件本质上是关于某些商业或某些领域的共同叙述事件可以是任何东西事件是让我们思考的事情当你思考的是一个人时，你可以更容易地思考事件而不是数据库记录，例如，因为发生了一些事情，存在事实，这个事实是不可改变的，因为你不能改变未来，即使你想，记得和你的另一半的谈话，你说了一些不该说的话。但是你不能做任何事情来改变它，只能发送新的事件。我们身边发生的事情也是如此。有一些销售发生了。开了一些发票，客户付款。
一些客户注册或介绍其他客户。因此，这些事情每天都在发生，它们与业务一起发生，我们需要捕获这些事件，以便执行一些业务操作。事件是按时间顺序排列的，就像在现实生活中，你总是可以从你的记忆中恢复这些事件的顺序，就像这些事件的顺序可以从流媒体平台上恢复一样。从历史上看，订购对我们来说是很重要的对于业务产品流程来说。举个例子，如果我们谈论信用卡交易。是的，信用卡交易的顺序很重要。所以，这是我们想要在流媒体平台中保留的东西，它允许我们这样做。
现在，在事件中思考在事件范式中允许简化或不简化架构，也许简化或不，它不会从一开始就看起来像一个简单的事情。因为，你知道，很明显，在一个整体中，当它们很小的时候，总是很容易在一个地方放很多东西。当你开始发展这个系统开始发展这个小的道德系统时，要把系统的所有架构都放在一个人的手里是不容易的，你需要有很多人他们知道系统的很多细节。但是有了流媒体平台，我们可以在微服务之间建立通信，这样我们就可以把这个单一的应用程序分解成一组服务。这是可以进化和发展的。而事件流平台将为这些服务的通信提供骨干。他们可能，你知道，对世界有着相同的看法。因此，在这种情况下，它不仅是主干，而且是服务的单一事实来源，它们可以重用这些数据并将其应用于不同的方面。比如说，我们可能有一个用户注册的事件这可以触发多个服务对某件事做出反应，会有一个发送问候邮件的电子邮件服务可能是一些分析服务，它会为新用户提供一些开始和完成的一些积分，比如如果用户做得更多，买得更多，我们可以为他的忠诚度计划积累更多积分。现在，事情变得更复杂了。 So when we start looking to this kind of system, we need to develop the practices how to develop and going forward for this system.
所以，让我们来分析一下我在谈到风险平台时想要谈论的一些事情，以及开发者如何开始这一旅程。这里有两件事，它们不一定相互矛盾，但有两件事需要考虑。我并不是说他们是两极的，但是因为你知道，很明显，为了成功地经营这项业务，有一些商业目标。从DevOps的角度来看，我们想要实现一些目标。一旦你有了CTO，这个系统就可以24小时运行了，它需要具有成本效益。为了做成这笔生意，我们显然想要获得利润。我们不想就像实时地快速烧钱一样，我们需要对那里正在发生的事情或世界的状态有一些确定性。这是系统的目标。但是DevOps，它更多的是在技术方面，架构方面和一些文化方面进行操作。那么如何有效地实现流程以及如何应用工具使流程高效呢? So, integrate with multiple tools integrate with the frameworks that allow you to scale certain applications more efficiently.
但是当我们讲到工具和策略的时候。答案是，总是取决于我们需要考虑很多很多的事情。我们运行的是什么样的平台?这是云还是婴儿车?我们依赖于供应商还是不依赖于标准?某些技术是否有标准?我们是否应该更少地使用服务器，既然我们谈论的是频带，就有能力查看这些事件，并将这些事件标准化，比如云事件，这是[CNCF]倡议标准化云事件，以便获得传输数据的标准信封。所以，这就是事情是如何运作的，比如，带来一些工具，让事情发生。不是在DevOps中作为一种类似的技术。但也有一些东西来自卡夫卡的世界。 So Kafka is an event streaming platform that provides this backbone to storing this events and there are certain patterns and anti patterns that people need to also take into account while implementing this Kafka event streaming platform. So essentially, the Kafka is really agnostic on the data that you put in there. However, the business applications, these microservices, they might be very much dependent on the nature of this data – so this is why I was talking about the format of this, like when I was talking about things like cloud events. Cloud events define a schema.
因此，在这种情况下，模式需要公开给多个工具、多个组件。因此，可能用不同语言编写的多个服务需要访问相同的模式。所有服务的编排，以及服务如何知道它们需要在编排之上执行某些操作，比如编排。因此，使用传统的类似工作流的工具，总是需要编排和/或有人来控制这些东西。这些服务需要是不可知论的。所以，在这种情况下，它更像是一种编排。它们将根据特定服务的特定需求协同工作。错误处理和处理一些坏数据。这也是人们需要考虑如何实现的一些模式，因为Kafka是一个流媒体平台，这并不容易。它并没有为你提供特定的方法。然而，某些事情需要牵涉进来。 We are running this in a distributed world, in a synchronous world, this is something that needs to be taken into account.
在同步总线上实现同步通信接口，可以将其视为某些依赖项。所以，例如，当我们试图做一个请求响应，并在Kafka这样的队列结构上实现它时，也许这不是正确的事情。以及在Kafka代理的基础设施中提供这些的能力，也需要一定的自动化步骤，因为你想要一个微调的机器，你不想花时间做手动的事情，因为到最后，Kafka正在成为一个中央神经系统，如果没有适当的自动化和适当的自我调整，在现实世界中使用和操作这个工具将是非常困难的。那么，这些东西如何在CI/CD中发挥作用以及应用程序如何从开发阶段交付到生产阶段呢?所以，当我们谈论传统的测试生命周期时，通常是功能端单元测试，这些是开发人员在开发过程中产生的部分，对吧?这是第一阶段。
这就是我们所说的以开发者为中心的测试，开发者在开发某些特性的同时开发这些测试。当我们运行这个复杂的多微服务系统时，作为单元测试单独测试的多个方面需要在集成中进行测试。一旦完成了集成测试的第一阶段，我们通常需要转移到我们可以使用非常接近生产的数据测试系统的阶段。因此，我们正在经历不同的环境，我们得到的数据流接近于我们在环境中的数据流。最后但并非最不重要的是，性能测试，确保新特性不会引入回归，不会损失任何实质性的性能和其他一些东西。这就像典型的测试生命周期。现在，商业实际需要的一些东西，我们在之前的幻灯片中提到的东西可能不是100%的技术要求，但是，它们是现代商业的要求。那么，系统将如何在前所未有的负荷下工作。
我们正在为黑色星期五推出新的支付系统，我们希望确保系统中用户活动的高峰不会干扰业务流程。如何在没有停机时间的情况下执行24 * 7的业务连续性。所以滚动升级——绿色和蓝色部署——这些类型的场景。提供一些弹性的外观。比如，如果负载增加了，我们能不能增加服务实例的数量来满足这个负载，等等?这些目标是由业务决定的，需要从技术的角度来实现。现在，有几件事我建议你们从技术的角度来看，从允许我们在不同的开发阶段实施这些测试的特定框架的角度来看。
大多数时候或者大多是开发这种微服务的业务逻辑，特别是Java中谈到的Kafka实现用的框架叫做Kafka流。Kafka streams是一个嵌入式框架，是Apache Kafka的一部分，它实际上包含了一些电池。例如，对于单元测试，包括[听不清]驱动程序，它不需要任何可用的环境来执行该测试。为了进行实时测试，有几件事可以做。有一个框架——嵌入式Kafka——它代表了应用程序可以与Kafka通信的实时协议。也可以使用容器来执行集成测试。具体来说，当我们进行环境集成测试时，测试容器实际上显示为不连续的。它们也类似于Java框架，允许您通过编写集成测试来使用类似j-unit的语法，尤其是j-unit语法，并且它将在实际软件中使用实际容器。
它看起来不像假的或嵌入的版本。它是实际的容器，您可以使用它来针对实际软件测试应用程序。创建者的一些方面也可以用来启动另一个新环境，在那里你所有的东西都在那里，比如，你知道，Helm，它允许你定义你的部署策略，或者部署和应用程序结构，允许你快速地运行它，引入一些错误注入框架，允许你测试那些业务感兴趣的情况，业务持续，一些回归和性能测试可以来自[听不清]操作符，它允许某些组件(如Kafka)的自平衡和自修复。现在，在一个理想的世界里，我们想看看我们是否能在管道中的所有步骤都成功执行后自动交付这些东西，但是我们如何扩展它，我们如何在生产中实现它?所以，在这里，我想快速地谈谈关于建立一个生产就绪的发明平台的四个架构原则。第一个是核心业务功能。在这种情况下，本质上是那些实现业务功能的微服务。这就像你的流处理器，数据通过流系统，有一个核心处理器做一些处理。
例如，实现支付系统，我们获得关于支付的事件，我们做一些处理，然后我们发送另一个事件，说事件已处理。接下来我们需要改进的就是所谓的信任平面。因此，信任平面允许收集业务感兴趣的指标，例如，在此期间处理了多少付款。这些指标可能会对业务产生直接影响，我们也可以通过集成这些指标或结果，例如核心业务功能，将其作为输入发送到核心业务处理器中。此外，数据质量，比如如果有些付款没有及时处理，比如会对业务产生什么影响，所以我们需要收集这些指标，并以某种方式呈现出来。控制平面…可能最难实现的事情之一就是控制平面，因为它不仅允许我们交付，还允许我们执行系统的日常操作方面。这些微服务将如何与其服务发现的实现方式进行协调。这些节拍如何从你的CI/CD管道到达等等。一些底层组件的编排，比如配置，操作系统配置，也许，你知道一些容器或pod谈论细节，我们谈论的是像[听不清]这是。通常[听不清]这些天正在成为一个为你的业务流程构建控制平面的平台。和运维平面,如操作飞机,允许执行和创建系统的可观测性:健康检查,错误日志,他们执行审计不同,我不知道,像监管等等等等原因,执行数据血统,我们知道数据从何而来,这些数据如何进化之类的东西,还有处理坏数据发送这些到那封信问:那么,这是一个例子,这是如何实现的。 So, core business function in this particular case is like a payment processing.
我们有一个进入支付主题的事件流，我们做一些性能计算，这个结果将在另一个主题中可用。所以。如果我们有另一个系统，它将依赖于这些数据，他们将从库存中消费。接下来是信任平面。在信任平面的示例中，我们需要一些关于已确认事件数量的业务度量，在此特殊情况下，核心业务功能的输出将由此信任平面使用。下一件事是，对于控制平面，为了执行部署和更新规则，比如溢价处理是如何发生的，将有另一个处理器或另一个流应用程序将通过状态主题获取信息，然后执行关于状态的内部应用程序，并与来自某些支付系统的数据连接。例如，我们看到新付款的消息负载增加。因此，我们需要启动支付处理器的另一个实例。所以，在这种情况下，控制平面会做出反应在这种特殊情况下，操作平面，会执行整个系统的可观察性，并在出现问题时报告和警报。
因此，对于更接近操作平面的地方这就是我们进入处理一些权重数据的世界的地方我们如何捕获应用程序登录和提供商登录创建，你知道仪表板，所有东西都在那里。错误提示如果在一些糟糕的进程中发生了一些糟糕的数据，我们也需要记录这一点，我们不能只是把它放在控制台上，然后继续。之后，我们需要去获取日志文件，找到它在哪里。审计日志提供这种保留信息和类似的东西。所有这些都可以通过这个操作平面来完成。最重要的是，就像这里的要点一样，所有这些微服务都是在某种意义上实现的，即这个控制平面的那些元素是单个微服务的元素。它们是代表单个微服务的元素，Kafka事件流平台提供了这个支柱，在那里它存储了整个历史，就像世界上所有这些状态一样，就像真相的来源。
所以，在这种情况下，事件从一个地方携带不同的信息事件进化，它们允许你的系统进化。所以，这次演讲的几个关键要点是:事件正在成为一个自我描述事物方式的API，它允许系统按照领域驱动设计的风格建模，并考虑如何发展这些事件。将系统解耦成事件是为了提供事件流而不是有数据记录的竖井这些数据记录要插入一些表，然后，我们更新这个表，现在我们不知道历史是什么以及这个事件是如何在这里结束的。使用此策略时，需要考虑业务目标;不仅是技术方面，还有业务目标和一些业务将感兴趣的事情，最重要的是，这些事情也将自动化。并应用现代测试技术。测试容器很神奇。
总的来说，我们不断意识到技术改变了我们处理软件的方式，不仅在生产中，而且在测试和开发中。因此，这些——有界的上下文——小的单个工作片段，小的单个微服务可以更大，或者一个更大的单体系统可以被分解成具有自己的小的有界上下文的小微服务。通过实现信任平面，控制平面，操作平面，显然还有基本得分函数来寻找这些模式。这些模式可以让你成功地实现流媒体平台。所以，如果你想了解Kafka在事件流世界中的更多知识，有一个名为developer.conference的网站。在这里，我们有一套工具和例子，以及不同的播客，视频，一切——为了帮助你学习Kafka。如果你对开发事件驱动的微服务感兴趣，你可以读一些书，总的来说，改变你的视角，你想如何看待你的数据和你的组织中的数据，等等。所以非常感谢你的时间。我真的很喜欢。跟你聊聊直播平台。现在让我们进入问答环节。 Thank you.