大家好，欢迎swamamp。欢迎来到我的办公室，我很高兴今天能在这里谈论我感到兴奋的事情，我希望你们也会感到兴奋。所以，今天我将讨论事件、流，以及DevOps、开发人员和组织速度的所有事情。我的名字是Victor Gamov，我是Confluent的一名开发人员。这是一家基于Apache Kafka开发事件流媒体平台的公司。Apache Kafka是一个开源项目，我们积极为Apache Kafka做贡献。此外，我们还与客户合作，帮助他们建立并采用赛事流媒体平台。今天，我要讲的就是这个。
我想非常感谢我的朋友尼尔·艾弗里，感谢他对这次演讲的贡献。好的，那么我将开始解释为什么我一直在流媒体，以及我们在事件流的有用性方面的立场。世界正在改变，有些事情对我们中的一些人来说可能很明显，但对其他人来说却不那么明显。这就是为什么有些事情，我们过去是怎么做的，它们不是现在发生的，比如，事情是这样不断变化的。同样的事情也发生在我们的业务上，在过去，IT技术是业务的支持功能。这是一些，你知道的，帮助企业运营的东西。为了发展，就需要一些创新，因为很多企业都参与了一些实体互动，足够好就足够好了。今天，技术就是商业，我们看到很多公司都在发展自己的核心竞争力。就像JFrog组织的swampp一样。我在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，这个系统就可以全天候运行，它需要具有成本效益。为了完成这项业务，我们显然希望获得利润。我们不希望只是实时地烧钱敏捷，我们需要对那里正在发生的事情或世界的状态有一些确定性。这是系统的目标。但是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的业务连续性。滚动升级——绿色和蓝色部署——这些类型的场景。提供一些弹性外观。比如，如果负载在上升，我们是否可以增加服务实例的数量来满足这个负载，等等?所以这些目标是由商业决定的，需要从技术的角度来实现。现在，有几件事我想建议你们从技术的角度来看，从特定的框架来看，允许我们在不同的开发阶段实现这些测试。
大部分时间或者说大部分业务逻辑的开发对于这种微服务来说，尤其是用Kafka的Java来谈实现的框架叫做Kafka流。Kafka streams是一个嵌入式框架，是Apache Kafka的一部分，它实际上包含了一些电池。例如，对于单元测试，这包括[听不清]驱动程序，它不需要任何可用的环境来执行这个测试。为了进行实时测试，有几件事可以做。有一个框架——嵌入式Kafka——它代表了应用程序可以与Kafka通信的实时协议。或者可以使用容器，来执行这个集成测试。具体来说，当我们进行环境集成测试时，测试容器实际上显示不连续。它们也像一个Java框架，允许您使用类似j-unit的语法，特别是j单元语法，通过编写集成测试，它将使用实际的容器和实际的软件。
它看起来不是假的或嵌入的版本。它是您可以用来测试应用程序与实际软件的实际容器。创建者的一些方面也可以用来启动另一个新环境，在那里你所有的东西都在那里，比如Helm，它允许你定义你的部署策略，或者部署和应用程序结构允许你快速滚动，引入一些故障注入框架，允许你测试那些业务感兴趣的情况，业务持续，一些回归和性能测试可以来自于[听不清]操作符，它允许某些组件的自平衡和自修复，如Kafka。现在，在理想的情况下，我们想看看我们是否能自动交付这几件事一旦管道中的所有这些步骤都成功执行，但就像我们如何扩展它，就像我们如何在一个世界中实现它-我们如何在生产中实现它?所以，在这里，我想快速地谈谈建立一个可生产的发明平台的四个架构原则。第一个是核心业务功能。在这种情况下，这实际上是那些实现业务功能的微服务。这就像你的流处理器，数据通过流系统，有一个核心处理器做一些处理。
比如，实现支付系统，我们得到关于支付的事件我们做一些处理之后我们发送另一个事件说事件已处理。下一件事是我们需要改进所谓的信任平面。信任平面允许收集业务业务感兴趣的指标例如，在这段时间内处理了多少支付。这些指标可能对业务有直接的影响，这是我们也可以通过集成的结果，例如核心业务功能，可以作为输入发送到核心业务处理器。此外，数据质量，比如如果一些付款没有及时处理，比如对业务的影响，所以我们需要收集这些指标，并以某种方式呈现它们。控制平面…可能最难实现的事情之一就是控制平面，因为它不仅允许我们交付，而且还允许我们执行系统的日常操作方面。这些微服务将如何协调其服务发现将如何实现。这些节拍将如何从你的CI/CD管道到达等等。底层组件的一些编排，比如供应，操作系统供应，也许，你知道一些容器或pod谈论细节，我们正在谈论像[听不清]这是。通常[听不清]这些天成为一个平台，为你的业务流程构建控制平面。和运维平面,如操作飞机,允许执行和创建系统的可观测性:健康检查,错误日志,他们执行审计不同,我不知道,像监管等等等等原因,执行数据血统,我们知道数据从何而来,这些数据如何进化之类的东西,还有处理坏数据发送这些到那封信问:那么,这是一个例子,这是如何实现的。 So, core business function in this particular case is like a payment processing.
我们有一个事件流，涉及到一个支付主题，我们做一些性能计算，这个结果将在另一个主题中得到。所以。如果我们有另一个依赖于这些数据的系统，它们将从库存中消费。下一个是信任平面。在信任平面的例子中，我们需要有一些关于已确认事件数量的业务度量，在这个特定的情况下，核心业务功能的输出将被这个信任平面使用。下一件事是，对于控制平面来说，为了执行部署，比如更新规则，溢价处理是如何发生的，将有另一个处理器或另一个流应用程序，通过状态主题获取信息，然后执行关于状态的内部应用程序，并连接来自某些支付系统的数据。例如，我们看到新付款的消息负载增加了。因此，我们需要启动支付处理器的另一个实例。因此，在这种情况下，控制平面会做出反应而在这种特殊情况下，操作平面会执行整个系统的可观察性，并在出现问题时报告和警报。
因此，有点接近于操作平面这是我们进入处理一些权重数据的世界的地方我们如何捕捉应用程序登录和创建的提供商登录，你知道仪表板，所有东西都在那里。错误提示，如果在一些坏的进程中发生了一些坏的数据，我们也需要记录这个，我们不能只是把它转到控制台上，然后继续。之后，我们需要抓取日志文件，找到它在哪里。审计日志提供这种保留信息和类似的东西。所有这些事情都可以通过这个操作平面来完成。最重要的是，就像这里的要点一样，所有这些微服务都是在某种意义上实现的，控制平面的那些元素是单个微服务的元素。它们是钢铁中代表个体微服务的元素，Kafka事件流平台提供了这个主干，它存储了整个历史，就像世界的所有状态一样，就像真相的来源。
因此，在这种情况下，事件携带来自一个地方的不同信息事件进化，它们允许您的系统进化。因此，这次演讲的几个关键要点是:事件正在成为一种自我描述事物方式的API，它允许系统以领域驱动设计的风格建模，并考虑这些事件如何发展。将系统解耦到事件中以提供事件流而不是将数据记录隔离在数据记录中插入一些表，然后更新这个表，现在我们不知道历史是什么以及事件是如何在这里结束的。使用这种策略，需要考虑业务目标;不仅是技术方面，还有业务目标和一些业务感兴趣的事情，最重要的是，将这些事情自动化。并应用现代测试技术。测试容器非常神奇。
总的来说，继续意识到技术改变我们处理软件的方式，不仅在生产中，而且在测试和开发中。因此，那些——有界上下文——小的个体工作，小的个体微服务可以更大，或者一个大的整体系统可以被分解成具有自己的小有界上下文的小微服务。通过实现信任平面，控制平面，操作平面，当然还有基础评分函数来寻找这些模式。这些模式可以让你成功地实现流媒体平台。所以，如果你想在事件流的世界里更多地了解Kafka，有一个叫做developer。conference的网站。io，在那里我们有一套工具和例子，以及不同的播客，视频，一切-为了帮助你学习Kafka。如果你对开发事件驱动的微服务感兴趣，你可以阅读一些书籍，改变你的视角，你想如何思考你的数据和组织中的数据，等等。非常感谢你的时间。我真的很喜欢。和你谈谈事件流媒体平台。现在进入问答环节。 Thank you.
