【架构】1019- 6种事件驱动的架构模式

淡淡的烟草味﹌ 2023-01-23 15:47 20阅读 0赞

![584906a74eade7a8f545cc461e26a510.png][]

在过去一年里，我一直是数据流团队的一员，负责 Wix 事件驱动的消息传递基础设施（基于 Kafka）。有超过 1400 个微服务使用这个基础设施。在此期间，我实现或目睹了事件驱动消息传递设计的几个关键模式，这些模式有助于创建一个健壮的分布式系统，该系统可以轻松地处理不断增长的流量和存储需求。

1消费与投影

**针对那些使用非常广泛、已经成为瓶颈的服务**

当有遗留服务存储着大型域对象的数据，这些数据使用又非常广泛，使得该遗留服务成为瓶颈时，此模式可以提供帮助。

在 Wix，我们的 MetaSite 服务就面临着这样的情况，它为 Wix 用户创建的每个站点保存了大量的元数据，比如站点版本、站点所有者以及站点上安装了哪些应用程序——已安装应用上下文（The Installed Apps Context.）。

这些信息对于 Wix 的许多其他微服务（团队）很有价值，比如 Wix Stores、Wix booking、Wix Restaurants 等等。这个服务被超过 100 万 RPM 的请求轰炸，它们需要获取站点元数据的不同部分。

从服务的各种 API 可以明显看出，它处理了客户端服务的太多不同的关注点。

![cf8266fa23de39cc1a7d22d14dd6ec0c.png][]

MetaSite 服务处理大约 1M RPM 的各类请求

我们想要回答的问题是，如何以最终一致的方式将读请求从该服务转移出来？

使用 Kafka 创建“物化视图”

负责这项服务的团队决定另外创建一个服务，只处理 MetaSite 的一个关注点——来自客户端服务的“已安装应用上下文”请求。

*  首先，他们将所有数据库的站点元数据对象以流的方式传输到 Kafka 主题中，包括新站点创建和站点更新。一致性可以通过在 Kafka Consumer 中进行 DB 插入来实现，或者通过使用 CDC 产品（如 Debezium）来实现。
 *  其次，他们创建了一个有自己数据库的“只写”服务（反向查找写入器），该服务使用站点元数据对象，但只获取已安装应用上下文并写入数据库。即将站点元数据的某个“视图”（已安装的应用程序）投影到数据库中。

![caae0dcb7355086d50e6bda593d88b6b.png][]

已安装应用上下文消费与投影

*  第三，他们创建了一个“只读”服务，只接受与已安装应用上下文相关的请求，通过查询存储着“已安装应用程序”视图的数据库来满足请求。

![4564f78bf68750272aa85892164e93ba.png][]

读写分离

效果

*  通过将数据以流的方式传输到 Kafka，MetaSite 服务完全同数据消费者解耦，这大大降低了服务和 DB 的负载。
 *  通过消费来自 Kafka 的数据，并为特定的上下文创建一个“物化视图”，反向查找写入器服务能够创建一个最终一致的数据投影，大幅优化了客户端服务的查询需求。
 *  将读服务与写服务分开，可以方便地扩展只读 DB 副本和服务实例的数量，这些实例可以处理来自全球多个数据中心的不断增长的查询负载。

2端到端事件驱动

**针对简单业务流程的状态更新**

请求 - 应答模型在浏览器 - 服务器交互中特别常见。借助 Kafka 和 WebSocket，我们就有了一个完整的事件流驱动，包括浏览器 - 服务器交互。

这使得交互过程容错性更好，因为消息在 Kafka 中被持久化，并且可以在服务重启时重新处理。该架构还具有更高的可伸缩性和解耦性，因为状态管理完全从服务中移除，并且不需要对查询进行数据聚合和维护。

考虑一下这种情况，将所有 Wix 用户的联系方式导入 Wix 平台。

这个过程涉及到两个服务：Contacts Jobs 服务处理导入请求并创建导入批处理作业，Contacts Importer 执行实际的格式化并存储联系人（有时借助第三方服务）。

传统的请求 - 应答方法需要浏览器不断轮询导入状态，前端服务需要将状态更新情况保存到数据库表中，并轮询下游服务以获得状态更新。

而使用 Kafka 和 WebSocket 管理者服务，我们可以实现一个完全分布式的事件驱动过程，其中每个服务都是完全独立工作的。

![9f7f586cc6c6804cfda7f984eae533a5.png][]

使用 Kafka 和 WebSocket 的 E2E 事件驱动

首先，浏览器会根据开始导入请求订阅 WebSocket 服务。

它需要提供一个 channel-Id，以便 WebSocket 服务能够将通知路由回正确的浏览器：

![2684420e5a7007855aeefab20d37a02b.png][]

打开 WebSocket 通知“通道”

第二，浏览器需要向 Jobs 服务发送一个 HTTP 请求，联系人信息使用 CSV 格式，并附加 channel-Id，这样 Jobs 服务（和下游服务）就能够向 WebSocket 服务发送通知。注意，HTTP 响应将立即返回，没有任何内容。

第三，Jobs 服务在处理完请求后，会生成并向 Kafka 主题发送作业请求。

![6eb3f8f3e93fe7cef9fda7c5bf61d478.png][]

HTTP Import 请求和生成的 Import Job 消息

第四，Contacts Importer\*\* 服务消费来自 Kafka 的作业请求，并执行实际的导入任务。当它完成时，它可以通知 WebSocket 服务作业已经完成，而 WebSocket 服务又通知浏览器。

![c1ff7826fa56d248585d4a83e4322282.png][]

工作已消费、已处理和已完成状态通知

效果

*  使用这种设计，在导入过程的各个阶段通知浏览器变得很简单，而且不需要保持任何状态，也不需要任何轮询。
 *  Kafka 的使用使得导入过程更具弹性和可扩展性，因为多个服务可以处理来自同一个原始导入 http 请求的作业。
 *  使用 Kafka 复制，很容易将每个阶段放在最合适的数据中心和地理位置。也许导入器服务需要在谷歌 DC 上，以便可以更快地导入谷歌联系人。
 *  WebSocket 服务的传入通知请求也可以生成到 Kafka，然后复制到 WebSocket 服务所在的数据中心。

3内存 KV 存储

**针对 0 延迟数据访问**

有时，我们需要动态对应用程序进行持久化配置，但我们不想为它创建一个全面的关系数据库表。

一个选择是用 HBase/Cassandra/DynamoDB 为所有应用创建一个大的宽列存储表，其主键包含标识应用域的前缀（例如“store\_taxes\_”）。

![ed9c4d7e0da27489fa44215da8e5223a.png][]

这个解决方案效果很好，但是通过网络取值存在无法避免的延迟。它更适合于更大的数据集，而不仅仅是配置数据。

另一种方法是有一个位于内存但同样具有持久性的键 / 值缓存——Redis AOF 提供了这种能力。

Kafka 以压缩主题的形式为键 / 值存储提供了类似的解决方案（保留模型确保键的最新值不会被删除）。

在 Wix，我们将这些压缩主题用作内存中的 kv-store，我们在应用程序启动时加载（消费）来自主题的数据。这有一个 Redis 没有提供的好处，这个主题还可以被其他想要获得更新的用户使用。

订阅和查询

考虑以下用例——两个微服务使用压缩主题来做数据维护：Wix Business Manager（帮助 Wix 网站所有者管理他们的业务）使用一个压缩主题存放支持的国家列表，Wix Bookings（允许安排预约和课程）维护了一个“（Time Zones）”压缩主题。从这些内存 KV 存储中检索值的延迟为 0。

![ed5277e1b9d79cd2415b3797195d3f91.png][]

各内存 KV 存储以及相应的 Kafka 压缩主题

Wix Bookings 监听“国家（Countries）”主题的更新：

![c02fdf757ae9e6906bf1a32399f6c215.png][]

Bookings 消费来自压缩主题 Countries 的更新

当 Wix Business Manager 将另一个国家添加到“国家”主题时，Wix Bookings 会消费此更新，并自动为“时区”主题添加一个新的时区。现在，内存 KV 存储中的“时区”也通过更新增加了新的时区：

![50639f3599d59bed9dd7c27c51aeaf6b.png][]

South Sudan 的时区被加入压缩主题

我们没有在这里停下来。Wix Events（供 Wix Users 管理事件传票和 RSVP）也可以使用 Bookings 的时区主题，并在一个国家因为夏令时更改时区时自动更新其内存 kv-store。

![8fb575d4ef18918f93cc4321f7f0cbbd.png][]

两个内存 KV 存储消费同一个压缩主题

4调度并遗忘

**当存在需要确保计划事件最终被处理的需求时**

在许多情况下，需要 Wix 微服务根据某个计划执行作业。

Wix Payments Subscriptions 服务就是一个例子，它管理基于订阅的支付（例如瑜伽课程的订阅）。

对于每个月度或年度订阅用户，必须通过支付提供程序完成续订过程。

为此，Wix 自定义的 Job Scheduler 服务调用由 Payments Subscription 服务预先配置好的 REST 端点。

订阅续期过程在后台进行，不需要（人类）用户参与。这就是为什么最终可以成功续订很重要，即使临时有错误——例如第三支付提供程序不可用。

要确保这一过程是完全弹性的，一种方法是由作业调度器重复请求 Payment Subscriptions 服务（续订的当前状态保存在数据库中），对每个到期但尚未续期的订阅进行轮询。这将需要数据库上的悲观 / 乐观锁定，因为同一用户同一时间可能有多个订阅续期请求（来自两个单独的正在进行的请求）。

更好的方法是首先生成 Kafka 请求。为什么？因为请求的处理将由 Kafka 的消费者顺序完成（对于每个特定的用户），所以不需要并行工作的同步机制。

![56c59e03edc3137d5e00b4ff7e53abf7.png][]

此外，一旦消息生成并发送到 Kafka，我们就可以通过引入消费者重试来确保它最终会被成功处理。由于有这些重试，请求调度的频率可能就会低很多。

在这种情况下，我们希望可以保持处理顺序，这样重试逻辑可以在两次尝试之间（以“指数退避”间隔进行）简单地休眠。

![d2226ca244d61e2f0d1a682739f079ce.png][]

Wix 开发人员使用我们自定义的 Greyhound 消费者，因此，他们只需指定一个 BlockingPolicy，并根据需要指定适当的重试间隔。

![ba36056359149b75cd7f00d4fad85044.png][]

在某些情况下，消费者和生产者之间可能会产生延迟，如长时间持续出错。在这些情况下，有一个特殊的仪表板用于解除阻塞，并跳过开发人员可以使用的消息。

如果消息处理顺序不是强制性的，那么 Greyhound 中还有一个使用“重试主题”的非阻塞重试策略。

![044b4887fdfb9491b99c32b73fa20329.png][]

当配置重试策略时，Greyhound 消费者将创建与用户定义的重试间隔一样多的重试主题。内置的重试生成器将在出错时生成一条下一个重试主题的消息，该消息带有一个自定义头，指定在下一次调用处理程序代码之前应该延迟多少时间。

还有一个死信队列，用于重试次数耗尽的情况。在这种情况下，消息被放在死信队列中，由开发人员手动审查。

这种重试机制是受 Uber 这篇文章的启发。

https://eng.uber.com/reliable-reprocessing/

Wix 最近开放了 Greyhound 的源代码，不久将提供给测试用户。要了解更多信息，可以阅读 GitHub 上的自述文件。

https://github.com/wix/greyhound\#greyhound

总结：

*  Kafka 允许按顺序处理每个键的请求（例如使用 userId 进行续订），简化工作进程逻辑；
 *  由于 Kafka 重试策略的实现大大提高了容错能力，续期请求的作业调度频率大大降低。

5事务中的事件

**当幂等性很难实现时**

考虑下面这个典型的电子商务流程。

Payments 服务生成一个 Order Purchase Completed 事件到 Kafka。现在，Checkout 服务将消费此消息，并生成自己的 Order Checkout Completed 消息，其中包含购物车中的所有商品。

然后，所有下游服务（Delivery、Inventory 和 Invoices）将消费该消息并继续处理（分别准备发货、更新库存和创建发票）。

![7630ed8312d590581e0f90c6d3ca70c8.png][]

如果下游服务可以假设 Order Checkout Completed 事件只由 Checkout 服务生成一次，则此事件驱动流的实现会简单很多。

为什么？因为多次处理相同的 Checkout Completed 事件可能导致多次发货或库存错误。为了防止下游服务出现这种情况，它们将需要存储去重后的状态，例如，轮询一些存储以确保它们以前没有处理过这个 Order Id。

通常，这是通过常见的数据库一致性策略实现的，如悲观锁定和乐观锁定。

幸运的是，Kafka 为这种流水线事件流提供了一个解决方案，每个事件只处理一次，即使当一个服务有一个消费者 - 生产者对（例如 Checkout），它消费一条消息，并产生一条新消息。

简而言之，当 Checkout 服务处理传入的 Payment Completed 事件时，它需要将 Checkout Completed 事件的发送过程封装在一个生产者事务中，它还需要发送消息偏移量（使 Kafka 代理能够跟踪重复的消息）。

事务期间生成的任何消息将仅在事务完成后才对下游消费者（Inventory Service）可见。

![71fd31eb46c90f2ef69aef71db9e458f.png][]

此外，位于 Kafka 流开始位置的 Payment Service Producer 必须转变为幂等（Idempotent）生产者——这意味着代理将丢弃它生成的任何重复消息。

![cad2509b7038a4a5effc2cc3beb5ade0.png][]

要了解更多信息，请观看我的视频“Kafka 中的恰好一次语义”。

https://www.youtube.com/watch?v=7O\_UC\_i1XY0

6事件聚合

**当你想知道整个批次的事件已经被消费时**

在上半部分，我描述了在 Wix 将联系人导入到 Wix CRM 平台的业务流程。后端包括两个服务。一个是作业服务，我们提供一个 CSV 文件，它会生成作业事件到 Kafka。还有一个联系人导入服务，它会消费并执行导入作业。

![7180eab3de12ea6aff7a744a4cefe08b.png][]

假设 CSV 文件有时非常大，将工作负载分割成更小的作业，每个作业中需要导入的联系人就会更少，这个过程就会更高效。通过这种方式，这项工作可以在 Contacts Importer 服务的多个实例中并行。但是，当导入工作被拆分为许多较小的作业时，该如何知道何时通知最终用户所有的联系人都已导入？

![062b7e495eeb06207badd0c9ddd9b3a1.png][]

显然，已完成作业的当前状态需要持久化，否则，内存中哪些作业已完成的记录可能会因为随机的 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。

![b47681fd12642d86e2b15fb3f9611a10.png][]

端到端更新流示例

让我们回到 Contacts Importer 服务流。一旦这个服务实例完成了某些作业的处理，它将更新 Job-Completed KVAtomicStore（例如，请求 Id 为 YYY 的导入作业 3 已经完成）：

![189904ab29a96dbdf25549486b0ee843.png][]

Atomic Store 将生成一条新消息到 job-completed-commands 主题，键为 YYY-6，值为 Job 3 Completed。

接下来，Atomic Store 的消费者 - 生产者对将消费此消息，并增加 KV Store 主题中键 YYY-6 的已完成作业计数。

![343f108cdb434c6630f295cfc5c3504d.png][]

恰好一次处理

注意，“命令”请求处理必须只发生一次，否则完成计数器可能不正确（错误增量）。为消费者 - 生产者对创建一个 Kafka 事务（如上文的模式 4 所述）对于确保统计准确至关重要。

AtomicKVStore 值更新回调

最后，一旦 KV 最新生成的已完成作业计数的值与总数匹配（例如 YYY 导入请求有 6 个已完成作业），就可以通知用户（通过 WebSocket，参见本系列文章第一部分的模式 3）导入完成。通知可以作为 KV-store 主题生成动作的副作用，即调用用户提供给 KV 原子存储的回调。

![bb9a76e5261f884910a848ee10a67513.png][]

注意事项：

*  完成通知逻辑不一定要在 Contacts Importer 服务中，它可以在任何微服务中，因为这个逻辑完全独立于这个过程的其他部分，只依赖于 Kafka 主题。
 *  不需要进行定期轮询。整个过程都是事件驱动的，即以管道方式处理事件。
 *  通过使用基于键的排序和恰好一次的 Kafka 事务，避免作业完成通知或重复更新之间的竞态条件。
 *  Kafka Streams API 非常适合这样的聚合需求，其特性包括 groupBy（按 Import Request Id 分组）， reduce 或 count（已完成作业计数）和 filter (count 等于总作业数)，然后是副作用 Webhook 通知。对于 Wix 来说，使用现有的生产者 / 消费者基础设施更有意义，这对我们的微服务拓扑影响更小。

7总结

这里的一些模式比其他的模式更为常见，但它们都有相同的原则。通过使用事件驱动的模式，可以减少样板代码（以及轮询和锁定原语），增加弹性（减少级联失败，处理更多的错误和边缘情况）。此外，微服务之间的耦合要小得多（生产者不需要知道谁消费了它的数据），扩展也更容易，向主题添加更多分区（和更多服务实例）即可。

**原文链接：**

https://medium.com/wix-engineering/6-event-driven-architecture-patterns-part-1-93758b253f47

https://medium.com/wix-engineering/6-event-driven-architecture-patterns-part-2-455cc73b22e1

![9b756dee11385e2cba379bed85ca8451.gif][]

[1. JavaScript 重温系列（22篇全）][1. JavaScript _22]

[2. ECMAScript 重温系列（10篇全）][2. ECMAScript _10]

[3. JavaScript设计模式 重温系列（9篇全）][3. JavaScript_ _9]

4. [正则 / 框架 / 算法等 重温系列（16篇全）][_ _ _ _ _16]

5. [Webpack4 入门（上）][Webpack4]|| [Webpack4 入门（下）][Webpack4 1]

6. [MobX 入门（上）][MobX] || [MobX 入门（下）][MobX 1]

7. 120[\+篇原创系列汇总][Link 1]

![b13b4626b7fa99ad28543e7c4e1b6b02.gif][]

回复“**加群**”与大佬们一起交流学习~

点击“**阅读原文**”查看 120+ 篇原创文章

[584906a74eade7a8f545cc461e26a510.png]: /images/20221004/86dd65a1ebcd4f13bb694e28bb7b5550.png
[cf8266fa23de39cc1a7d22d14dd6ec0c.png]: /images/20221004/3ab39b7b36bb4596b2b809df42e45081.png
[caae0dcb7355086d50e6bda593d88b6b.png]: /images/20221004/f4248f86d9cd4b829969d9b8f34b821e.png
[4564f78bf68750272aa85892164e93ba.png]: /images/20221004/804d9d17a6b8463c807cb57779964a63.png
[9f7f586cc6c6804cfda7f984eae533a5.png]: /images/20221004/ccdf5f605024407786b2cfc1eee4eb25.png
[2684420e5a7007855aeefab20d37a02b.png]: /images/20221004/79a1b8cf2b2e4df2976114de66256096.png
[6eb3f8f3e93fe7cef9fda7c5bf61d478.png]: /images/20221004/c8272a66357741b9acc8ee11410fa816.png
[c1ff7826fa56d248585d4a83e4322282.png]: /images/20221004/5e0a6505828547179d4a1ff68007e727.png
[ed9c4d7e0da27489fa44215da8e5223a.png]: /images/20221004/f5285210f4274078aeda313d9e587bcd.png
[ed5277e1b9d79cd2415b3797195d3f91.png]: /images/20221004/d53fcad4f59b4085826616af63e81b97.png
[c02fdf757ae9e6906bf1a32399f6c215.png]: /images/20221004/23c392f9fb17415b988372e6ac689603.png
[50639f3599d59bed9dd7c27c51aeaf6b.png]: /images/20221004/529f24e3333b430d88e826f6b6d94fb6.png
[8fb575d4ef18918f93cc4321f7f0cbbd.png]: /images/20221004/cd8b2e10b99349c0a794e21d2dca005c.png
[56c59e03edc3137d5e00b4ff7e53abf7.png]: /images/20221004/64e47ccdc9134da4a6ac623ef28185bd.png
[d2226ca244d61e2f0d1a682739f079ce.png]: /images/20221004/c3cdbb99d00a4633aa130ca4986d7a0a.png
[ba36056359149b75cd7f00d4fad85044.png]: /images/20221004/5f6908edbca04a2ca83e5a536743d7e6.png
[044b4887fdfb9491b99c32b73fa20329.png]: /images/20221004/8e58b65a72eb47199b616b54a38c417d.png
[7630ed8312d590581e0f90c6d3ca70c8.png]: /images/20221004/3e1de9c58d764e7db559ee50f2337067.png
[71fd31eb46c90f2ef69aef71db9e458f.png]: /images/20221004/2b7925d862534dd18dee278e5609a86f.png
[cad2509b7038a4a5effc2cc3beb5ade0.png]: /images/20221004/b2be4ee66c224a9f966f719f09c18947.png
[7180eab3de12ea6aff7a744a4cefe08b.png]: /images/20221004/d18343c417e74cf587ab273ac85f3cd7.png
[062b7e495eeb06207badd0c9ddd9b3a1.png]: /images/20221004/7fa7b4af002c4bdfb2a33ba2b4a54165.png
[b47681fd12642d86e2b15fb3f9611a10.png]: /images/20221004/7f99a9220f1f4a7781b52902b6a900c9.png
[189904ab29a96dbdf25549486b0ee843.png]: /images/20221004/74e6539d9a154f9db228e95458322d0a.png
[343f108cdb434c6630f295cfc5c3504d.png]: /images/20221004/b43df8b054c545ca85cdc3d648afbf8a.png
[bb9a76e5261f884910a848ee10a67513.png]: /images/20221004/b7113c2ef45f4e6698fec1313d571b36.png
[9b756dee11385e2cba379bed85ca8451.gif]: /images/20221004/48b9cffeba4c4cf0affa31c802528e45.png
[1. JavaScript _22]: http://mp.weixin.qq.com/s?__biz=MjM5MDc4MzgxNA%3D%3D&chksm=b1c224ea86b5adfc10c3aa1841be3879b9360d671e98cc73391c2490246f1348857b9821d32c&idx=1&mid=2458453187&scene=21&sn=a69b4d7d991867a07a933f86e66b9f55#wechat_redirect
[2. ECMAScript _10]: http://mp.weixin.qq.com/s?__biz=MjM5MDc4MzgxNA%3D%3D&chksm=b1c224e086b5adf6dad41a0d36b77a9bfb4bc9f0d29a816266b3e28c892e54274967dbce380b&idx=1&mid=2458453193&scene=21&sn=e5392cb77bc17c9e94b6c826b5f52a83#wechat_redirect
[3. JavaScript_ _9]: http://mp.weixin.qq.com/s?__biz=MjM5MDc4MzgxNA%3D%3D&chksm=b1c224e386b5adf554ab928cdeaf7ee16dbb2d895be17f2a12a59054a75b913470ca7649bbc7&idx=1&mid=2458453194&scene=21&sn=e7f0734b04484bee5e10a85a7cbb85c1#wechat_redirect
[_ _ _ _ _16]: http://mp.weixin.qq.com/s?__biz=MjM5MDc4MzgxNA%3D%3D&chksm=b1c224e286b5adf432850f82db18cc8647d639836798cf16b478d9a6f7c81df87c6da5257684&idx=1&mid=2458453195&scene=21&sn=1e0c8b7ea8ddc207b523ec0a636a5254#wechat_redirect
[Webpack4]: http://mp.weixin.qq.com/s?__biz=MjM5MDc4MzgxNA%3D%3D&chksm=b1c2251f86b5ac09dbbbb7c8e1d80c6cbd793a523cdfa690f8734def57812e616b9906aeec79&idx=1&mid=2458453302&scene=21&sn=904e40a421024ea0d394e9850b674012#wechat_redirect
[Webpack4 1]: http://mp.weixin.qq.com/s?__biz=MjM5MDc4MzgxNA%3D%3D&chksm=b1c2251e86b5ac08464872cd880811423e0d1bbcebbe11dcac9d99fa38c5332c089c06d65d95&idx=1&mid=2458453303&scene=21&sn=422f2b5e22c3b0e91a8353ee7e53fed9#wechat_redirect
[MobX]: http://mp.weixin.qq.com/s?__biz=MjM5MDc4MzgxNA%3D%3D&chksm=b1c2264c86b5af5aa7300a04d55efead6223e310d68e10222cd3577a25c783d3429f00767960&idx=1&mid=2458453605&scene=21&sn=0a506769d5eeb7953f676e93fb4d18eb#wechat_redirect
[MobX 1]: http://mp.weixin.qq.com/s?__biz=MjM5MDc4MzgxNA%3D%3D&chksm=b1c2264086b5af5611524eedb0d409afe86d859dce6ceff1c17ddab49d353c385e45611a73fa&idx=1&mid=2458453609&scene=21&sn=f0c22e82f2537204d9b173161bae6b82#wechat_redirect
[Link 1]: http://mp.weixin.qq.com/s?__biz=MjM5MDc4MzgxNA%3D%3D&chksm=b1c224dd86b5adcbd98189315e60de6a0106993690b69927cc1c1f19fd8f591fefce4e3db51f&idx=2&mid=2458453236&scene=21&sn=daf00392f960c115463c5aaf980620b4#wechat_redirect
[b13b4626b7fa99ad28543e7c4e1b6b02.gif]: /images/20221004/dc3852aaf77a4a96843f3bba6446c4f6.png