搭建公司网站需要多少钱,网站修改解析怎么做,内蒙古建设工程社保中心网站,丹东网站网站建设事件驱动架构(Event-Driven Architecture)是一种基于事件和事件处理的软件架构#xff0c;它的核心思想是将系统的行为和逻辑抽象成一系列事件#xff0c;这些事件在系统中按照一定的规则和顺序产生和传播#xff0c;并被相应的处理器处理。事件驱动架构具有高度的灵活性、可…事件驱动架构(Event-Driven Architecture)是一种基于事件和事件处理的软件架构它的核心思想是将系统的行为和逻辑抽象成一系列事件这些事件在系统中按照一定的规则和顺序产生和传播并被相应的处理器处理。事件驱动架构具有高度的灵活性、可扩展性和可维护性因此在现代软件系统中广泛应用。
事件驱动架构模式是常见的分布式异步架构模式通常被用来创建具备高扩展性的应用。其适应性也很强即可用于小型应用也可用于大型复杂应用。事件驱动架构由高度解耦、单一用途的事件处理器组成这些组件异步接收和处理事件。
事件驱动架构模式包含两种拓扑结构调解器mediator拓扑和代理broker拓扑。当我们需要通过中央调解器在事件中编排多个步骤时通常使用调解器拓扑而当您希望在不使用中央调解器的情况下将事件链接在一起时则使用代理拓扑。具体可参考其中博客
事件驱动架构模式 | 众里千寻
下面是几种常用的事件驱动的架构模式
1、消费与投影
针对那些使用非常广泛、已经成为瓶颈的服务
当有遗留服务存储着大型域对象的数据这些数据使用又非常广泛使得该遗留服务成为瓶颈时此模式可以提供帮助。
在 WixMetaSite 服务就面临着这样的情况它为 Wix 用户创建的每个站点保存了大量的元数据比如站点版本、站点所有者以及站点上安装了哪些应用程序——已安装应用上下文The Installed Apps Context.。
这些信息对于 Wix 的许多其他微服务团队很有价值比如 Wix Stores、Wix booking、Wix Restaurants 等等。这个服务被超过 100 万 RPM 的请求轰炸它们需要获取站点元数据的不同部分。
从服务的各种 API 可以明显看出它处理了客户端服务的太多不同的关注点。 MetaSite 服务处理大约 1M RPM 的各类请求
想要回答的问题是如何以最终一致的方式将读请求从该服务转移出来
使用 Kafka 创建“物化视图”
负责这项服务的团队决定另外创建一个服务只处理 MetaSite 的一个关注点——来自客户端服务的“已安装应用上下文”请求。
首先他们将所有数据库的站点元数据对象以流的方式传输到 Kafka 主题中包括新站点创建和站点更新。一致性可以通过在 Kafka Consumer 中进行 DB 插入来实现或者通过使用CDC产品如Debezium来实现。
其次他们创建了一个有自己数据库的“只写”服务反向查找写入器该服务使用站点元数据对象但只获取已安装应用上下文并写入数据库。即将站点元数据的某个“视图”已安装的应用程序投影到数据库中。 已安装应用上下文消费与投影
第三他们创建了一个“只读”服务只接受与已安装应用上下文相关的请求通过查询存储着“已安装应用程序”视图的数据库来满足请求。 读写分离
效果
通过将数据以流的方式传输到 KafkaMetaSite 服务完全同数据消费者解耦这大大降低了服务和 DB 的负载。
通过消费来自 Kafka 的数据并为特定的上下文创建一个“物化视图”反向查找写入器服务能够创建一个最终一致的数据投影大幅优化了客户端服务的查询需求。
将读服务与写服务分开可以方便地扩展只读 DB 副本和服务实例的数量这些实例可以处理来自全球多个数据中心的不断增长的查询负载。
2、端到端事件驱动
针对简单业务流程的状态更新
请求-应答模型在浏览器-服务器交互中特别常见。借助 Kafka 和WebSocket就有了一个完整的事件流驱动包括浏览器-服务器交互。
这使得交互过程容错性更好因为消息在 Kafka 中被持久化并且可以在服务重启时重新处理。该架构还具有更高的可伸缩性和解耦性因为状态管理完全从服务中移除并且不需要对查询进行数据聚合和维护。
考虑一下这种情况将所有 Wix 用户的联系方式导入 Wix 平台。
这个过程涉及到两个服务Contacts Jobs 服务处理导入请求并创建导入批处理作业Contacts Importer 执行实际的格式化并存储联系人有时借助第三方服务。
传统的请求-应答方法需要浏览器不断轮询导入状态前端服务需要将状态更新情况保存到数据库表中并轮询下游服务以获得状态更新。
而使用 Kafka 和 WebSocket 管理者服务可以实现一个完全分布式的事件驱动过程其中每个服务都是完全独立工作的。 使用 Kafka 和 WebSocket 的 E2E 事件驱动
首先浏览器会根据开始导入请求订阅 WebSocket 服务。
它需要提供一个 channel-Id以便 WebSocket 服务能够将通知路由回正确的浏览器 打开 WebSocket 通知“通道”
第二浏览器需要向 Jobs 服务发送一个 HTTP 请求联系人信息使用 CSV 格式并附加 channel-Id这样 Jobs 服务和下游服务就能够向 WebSocket 服务发送通知。注意HTTP 响应将立即返回没有任何内容。
第三Jobs 服务在处理完请求后会生成并向 Kafka 主题发送作业请求。 HTTP Import 请求和生成的 Import Job 消息
第四Contacts Importer**服务消费来自 Kafka 的作业请求并执行实际的导入任务。当它完成时它可以通知 WebSocket 服务作业已经完成而 WebSocket 服务又通知浏览器。 工作已消费、已处理和已完成状态通知
效果
使用这种设计在导入过程的各个阶段通知浏览器变得很简单而且不需要保持任何状态也不需要任何轮询。
Kafka 的使用使得导入过程更具弹性和可扩展性因为多个服务可以处理来自同一个原始导入 http 请求的作业。
使用 Kafka 复制很容易将每个阶段放在最合适的数据中心和地理位置。也许导入器服务需要在谷歌 DC 上以便可以更快地导入谷歌联系人。
WebSocket 服务的传入通知请求也可以生成到 Kafka然后复制到 WebSocket 服务所在的数据中心。
3、内存 KV 存储
针对 0 延迟数据访问
有时需要动态对应用程序进行持久化配置但不想为它创建一个全面的关系数据库表。
一个选择是用HBase/Cassandra/DynamoDB为所有应用创建一个大的宽列存储表其主键包含标识应用域的前缀例如“store_taxes_”。 这个解决方案效果很好但是通过网络取值存在无法避免的延迟。它更适合于更大的数据集而不仅仅是配置数据。
另一种方法是有一个位于内存但同样具有持久性的键/值缓存——Redis AOF提供了这种能力。
Kafka 以压缩主题的形式为键/值存储提供了类似的解决方案保留模型确保键的最新值不会被删除。
在 Wix将这些压缩主题用作内存中的 kv-store在应用程序启动时加载消费来自主题的数据。这有一个 Redis 没有提供的好处这个主题还可以被其他想要获得更新的用户使用。
订阅和查询
考虑以下用例——两个微服务使用压缩主题来做数据维护Wix Business Manager帮助 Wix 网站所有者管理他们的业务使用一个压缩主题存放支持的国家列表Wix Bookings允许安排预约和课程维护了一个“Time Zones”压缩主题。从这些内存 KV 存储中检索值的延迟为 0。 各内存 KV 存储以及相应的 Kafka 压缩主题
Wix Bookings 监听“国家Countries”主题的更新 Bookings 消费来自压缩主题 Countries 的更新
当 Wix Business Manager 将另一个国家添加到“国家”主题时Wix Bookings 会消费此更新并自动为“时区”主题添加一个新的时区。现在内存 KV 存储中的“时区”也通过更新增加了新的时区 South Sudan 的时区被加入压缩主题
Wix Events供 Wix Users 管理事件传票和 RSVP也可以使用 Bookings 的时区主题并在一个国家因为夏令时更改时区时自动更新其内存 kv-store。 两个内存 KV 存储消费同一个压缩主题
4、调度并遗忘
当存在需要确保计划事件最终被处理的需求时
在许多情况下需要 Wix 微服务根据某个计划执行作业。
Wix Payments Subscriptions 服务就是一个例子它管理基于订阅的支付例如瑜伽课程的订阅。
对于每个月度或年度订阅用户必须通过支付提供程序完成续订过程。
为此Wix 自定义的 Job Scheduler 服务调用由 Payments Subscription 服务预先配置好的 REST 端点。
订阅续期过程在后台进行不需要人类用户参与。这就是为什么最终可以成功续订很重要即使临时有错误——例如第三支付提供程序不可用。
要确保这一过程是完全弹性的一种方法是由作业调度器重复请求 Payment Subscriptions 服务续订的当前状态保存在数据库中对每个到期但尚未续期的订阅进行轮询。这将需要数据库上的悲观/乐观锁定因为同一用户同一时间可能有多个订阅续期请求来自两个单独的正在进行的请求。
更好的方法是首先生成 Kafka 请求。为什么因为请求的处理将由 Kafka 的消费者顺序完成对于每个特定的用户所以不需要并行工作的同步机制。 此外一旦消息生成并发送到 Kafka就可以通过引入消费者重试来确保它最终会被成功处理。由于有这些重试请求调度的频率可能就会低很多。
在这种情况下希望可以保持处理顺序这样重试逻辑可以在两次尝试之间以“指数退避”间隔进行简单地休眠。 Wix 开发人员使用自定义的Greyhound消费者因此他们只需指定一个 BlockingPolicy并根据需要指定适当的重试间隔。 在某些情况下消费者和生产者之间可能会产生延迟如长时间持续出错。在这些情况下有一个特殊的仪表板用于解除阻塞并跳过开发人员可以使用的消息。
如果消息处理顺序不是强制性的那么 Greyhound 中还有一个使用“重试主题”的非阻塞重试策略。 当配置重试策略时Greyhound 消费者将创建与用户定义的重试间隔一样多的重试主题。内置的重试生成器将在出错时生成一条下一个重试主题的消息该消息带有一个自定义头指定在下一次调用处理程序代码之前应该延迟多少时间。
还有一个死信队列用于重试次数耗尽的情况。在这种情况下消息被放在死信队列中由开发人员手动审查。
这种重试机制是受 Uber这篇文章的启发。
Wix 最近开放了 Greyhound 的源代码不久将提供给测试用户。要了解更多信息可以阅读 GitHub 上的自述文件。
总结Kafka 允许按顺序处理每个键的请求例如使用 userId 进行续订简化工作进程逻辑
由于 Kafka 重试策略的实现大大提高了容错能力续期请求的作业调度频率大大降低。
5、事务中的事件
当幂等性很难实现时
考虑下面这个典型的电子商务流程。
Payments 服务生成一个 Order Purchase Completed 事件到 Kafka。现在Checkout 服务将消费此消息并生成自己的 Order Checkout Completed 消息其中包含购物车中的所有商品。
然后所有下游服务Delivery、Inventory 和 Invoices将消费该消息并继续处理分别准备发货、更新库存和创建发票。 如果下游服务可以假设 Order Checkout Completed 事件只由 Checkout 服务生成一次则此事件驱动流的实现会简单很多。
为什么因为多次处理相同的 Checkout Completed 事件可能导致多次发货或库存错误。为了防止下游服务出现这种情况它们将需要存储去重后的状态例如轮询一些存储以确保它们以前没有处理过这个 Order Id。
通常这是通过常见的数据库一致性策略实现的如悲观锁定和乐观锁定。
幸运的是Kafka 为这种流水线事件流提供了一个解决方案每个事件只处理一次即使当一个服务有一个消费者-生产者对例如 Checkout它消费一条消息并产生一条新消息。
简而言之当 Checkout 服务处理传入的 Payment Completed 事件时它需要将 Checkout Completed 事件的发送过程封装在一个生产者事务中它还需要发送消息偏移量使 Kafka 代理能够跟踪重复的消息。
事务期间生成的任何消息将仅在事务完成后才对下游消费者Inventory Service可见。 此外位于 Kafka 流开始位置的 Payment Service Producer 必须转变为幂等Idempotent生产者——这意味着代理将丢弃它生成的任何重复消息。 6、事件聚合
当想知道整个批次的事件已经被消费时
在上半部分描述了在 Wix 将联系人导入到 Wix CRM 平台的业务流程。后端包括两个服务。一个是作业服务提供一个 CSV 文件它会生成作业事件到 Kafka。还有一个联系人导入服务它会消费并执行导入作业。 假设 CSV 文件有时非常大将工作负载分割成更小的作业每个作业中需要导入的联系人就会更少这个过程就会更高效。通过这种方式这项工作可以在 Contacts Importer 服务的多个实例中并行。但是当导入工作被拆分为许多较小的作业时该如何知道何时通知最终用户所有的联系人都已导入 显然已完成作业的当前状态需要持久化否则内存中哪些作业已完成的记录可能会因为随机的 Kubernetes pod 重启而丢失。
一种在 Kafka 中进行持久化的方法是使用 Kafka 压缩主题。这类主题可以看成是一种流式 KV 存储。
在示例中Contacts Importer 服务在多个实例中通过索引消费作业。每当它处理完一些作业就需要用一个 Job Completed 事件更新 KV 存储。这些更新可以同时发生因此可能会出现竞态条件并导致作业完成计数器失效。
原子 KV 存储
为了避免竞态条件Contacts Importer 服务将完成事件写到原子 KV 存储类型的 Jobs-Completed-Store 中。
原子存储确保所有作业完成事件将按顺序处理。它通过创建一个“Commands”主题和一个“Store”压缩主题来实现。
顺序处理
从下图可以看出原子存储如何生成每一条新的 Import-job-completed“更新”消息并以[Import Request Id][total job count]作为键。借助键就可以总是依赖 Kafka 将特定 requestId 的“更新”放在特定的分区中。
接下来作为原子存储的一部分消费者-生产者对将首先侦听每个新的更新然后执行 atomicStore 用户请求的“命令”——在本例中将已完成作业数量的值加 1。 端到端更新流示例
回到 Contacts Importer 服务流。一旦这个服务实例完成了某些作业的处理它将更新 Job-Completed KVAtomicStore例如请求 Id 为 YYY 的导入作业 3 已经完成 Atomic Store 将生成一条新消息到 job-completed-commands 主题键为 YYY-6值为 Job 3 Completed。
接下来Atomic Store 的消费者-生产者对将消费此消息并增加 KV Store 主题中键 YYY-6 的已完成作业计数。 恰好一次处理
注意“命令”请求处理必须只发生一次否则完成计数器可能不正确错误增量。为消费者-生产者对创建一个 Kafka 事务如上文的模式 4 所述对于确保统计准确至关重要。
AtomicKVStore 值更新回调
最后一旦 KV 最新生成的已完成作业计数的值与总数匹配例如 YYY 导入请求有 6 个已完成作业就可以通知用户通过 WebSocket参见本系列文章第一部分的模式 3导入完成。通知可以作为 KV-store 主题生成动作的副作用即调用用户提供给 KV 原子存储的回调。 注意事项
完成通知逻辑不一定要在 Contacts Importer 服务中它可以在任何微服务中因为这个逻辑完全独立于这个过程的其他部分只依赖于 Kafka 主题。
不需要进行定期轮询。整个过程都是事件驱动的即以管道方式处理事件。
通过使用基于键的排序和恰好一次的 Kafka 事务避免作业完成通知或重复更新之间的竞态条件。
Kafka Streams API 非常适合这样的聚合需求其特性包括 groupBy按 Import Request Id 分组 reduce 或 count已完成作业计数和 filter (count 等于总作业数)然后是副作用 Webhook 通知。对于 Wix 来说使用现有的生产者/消费者基础设施更有意义这对微服务拓扑影响更小。
总结
这里的一些模式比其他的模式更为常见但它们都有相同的原则。通过使用事件驱动的模式可以减少样板代码以及轮询和锁定原语增加弹性减少级联失败处理更多的错误和边缘情况。此外微服务之间的耦合要小得多生产者不需要知道谁消费了它的数据扩展也更容易向主题添加更多分区和更多服务实例即可。
