---

事件驱动的微服务 - 快速指南

事件驱动的微服务 - 简介

事件驱动的微服务 (EDM) 是使用事件进行交互的微服务。事件表示系统状态的变化，例如处理交易、下订单、完成付款等。

事件驱动的微服务创建一个松散耦合的系统，其中服务不依赖于直接通信，而仅在这些事件发生时才响应事件。我们在需要实时处理的大规模分布式环境中使用 EDM 系统。

事件驱动的微服务的特征

事件驱动的微服务 (EDM) 的一些重要特征如下所列 −

• 异步通信 − 服务在 EDM 系统中异步通信。我们不会等待响应，而是在事件发生时做出反应。它提高了系统的效率和性能。
• 松散耦合 − EDM 服务是解耦的，并通过事件进行通信。这些服务中的每一个都可以独立运行。它降低了级联故障的风险。
• 可扩展性 − 我们可以根据需求独立扩展 EDM 中的服务。
• 实时处理 − 我们可以实时使用 EDM 系统，因为 EDM 会在事件发生时处理这些事件。我们在应用程序中使用 EDM 进行即时反应。例如:支付处理、交易系统和实时监控。
• 事件驱动的工作流 − EDM 使用事件生成服务，而不是直接调用这些服务。因此，服务仅在事件发生时才起作用。

事件驱动微服务的架构

事件驱动微服务的架构中有一些重要术语，例如事件生产者、事件代理、事件消费者和消息队列。这些将在下面解释 −

• 事件生产者 − 它生成事件。当发生操作时，例如客户下订单和正在处理付款。然后，事件生产者将事件发送到事件代理以进行进一步处理。
• 事件路由器 − 它在生产者和消费者之间路由事件。Apache Kafka、RabbitMQ 和 AWS EventBridge 等工具充当代理。事件被传递给正确的消费者。
• 事件消费者 − 它由对事件做出反应的服务组成。这些服务会监听事件并根据事件数据执行操作，例如更新数据库、通知用户和处理付款。
• 消息队列 − 需要消息队列来发送交付。如果服务不可用，则消息队列会将交付发送给消费者。这些队列平衡负载并管理事件流量。

EDM 中的事件类型

EDM 系统中有两种类型的事件 −

• 领域事件 − 这些是业务级事件。它们代表状态的变化，例如下订单、付款完成、用户注册等。
• 集成事件 − 这些事件用于微服务之间的通信。因此，不同的服务可以同步数据并触发整个系统的操作。例如，当下订单时，这些事件会通知运输服务准备交货。

EDM 事件工作流

当事件发生时，例如，事件生产者会生成新的交易。事件代理将其分发给其事件消费者。这些消费者根据其功能处理事件。这是 EDM 系统中的事件工作流 −

• 事件生成 − 客户在电子商务平台下订单。订单事件由生产者生成。
• 事件路由 − 事件代理将订单事件路由到多个服务(消费者)，如库存管理、支付处理和通知服务。
• 事件处理 − 每个服务处理事件。库存管理更新库存。支付服务处理付款。通知服务发送确认电子邮件。
• 实时响应 −系统实时更新所有服务，无需等待任何单个服务完成其任务。

事件驱动微服务的优点和缺点

事件驱动微服务 (EDM) 有各种优点和缺点，其中一些优点和缺点如下 −

事件驱动微服务的优点

以下是使用事件驱动微服务的优点 −

• 实时处理 − 服务仅在 EDM 中发生事件时做出反应。我们将 EDM 用于实时应用程序。
• 可扩展性 − 我们可以扩展每个微服务；它根据需求优化资源使用。
• 松散耦合 −服务是独立的。它降低了级联故障的风险。我们还可以更新任何这些服务。
• 效率 − 由于系统松散耦合，服务不需要等待响应。它提高了系统性能。

事件驱动微服务的缺点

以下是使用事件驱动微服务的缺点 −

• 复杂性 − 我们需要管理许多独立的服务。它会增加系统复杂性。
• 数据一致性 − 我们需要在异步架构中保持跨服务的数据一致性。但这可能具有挑战性。
• 安全性 −我们需要确保服务之间的通信安全，以防止未经授权的访问。

事件驱动架构与微服务架构

下表重点介绍了事件驱动架构与微服务架构的不同之处 −

结论

事件驱动的微服务架构是一种可扩展的实时解决方案，适用于需要立即对不断变化的条件做出反应的现代应用程序。其松散耦合和异步通信使其非常适合大型分布式系统。尽管 EDM 在事件处理和数据一致性方面具有一定的复杂性，但其实时处理和服务独立性等优势足以弥补这些挑战。

事件驱动微服务的架构

我们可以使用事件驱动微服务 (EDM) 发送和接收事件消息。生产者生成并发布事件，以在系统中发生操作和更改时通知其他服务。同时，其他服务会使用这些事件采取相关操作以实时更新。

EDM 系统的主要优势是其异步通信和松散耦合的设计。服务会在事件发生时订阅并做出反应，而不是等待在需要时请求数据。EDM 是松散耦合的，以保持微服务之间的独立性。因此，我们可以单独操作和扩展任何服务而不会相互影响。

EDM 具有松散耦合的架构和事件驱动的基础。EDM 可以解决传统方法的局限性。我们将在本章中讨论这些解决方案。

REST 驱动方法

我们在基于 REST 的同步系统中相互调用组件并等待响应 −

但这种方法存在一些问题，包括以下内容 −

• 对响应的依赖 − 如果模块 1 等待模块 2 的响应。那么如果模块 2 速度慢且不可用，它可能会有延迟。
• 服务停机时间 − 如果服务停机。那么其依赖的服务就会中断。
• 网络延迟 −对于需要分页的大型有效负载，数据传输可能会延迟。
• 重负载影响 − 重负载下的服务可能响应缓慢。因此会降低性能。

当系统由于这些同步连接而变得效率低下时，我们会使用 EDM 解决方案。

事件驱动的微服务示例

假设我们有一个报告应用程序 GIB API，用于向政府发送销售报告。此应用程序从另一个 API 获取所有销售数据。一开始，由于交易量很少，我们使用简单的 REST 方法构建了 API。

但是当数据增长时，交易量会意外增加。 REST 方法存在问题，因此我们需要一个事件驱动的解决方案。

解决方案 1:转换为事件消息传递

我们应用事件驱动方法来高效生成报告。该计划很简单，如下所示 −

• 为新交易生成事件 − 每当创建新交易项时，都会发布事件。
• 异步数据获取 − 获取相关数据并将其转换为报告内容。
• 存储和检索报告 − 报告数据存储在关系数据库 (PostgreSQL) 中。报告字符串被连接起来并保存为文件以供以后访问。

通过这种异步事件消息传递。报告应用程序可以处理数据，而无需不断进行直接 REST 调用。

将流程转换为异步模型后，还存在另一个性能问题。报告 API 仍在超载交易 API，因为它请求每个项目的交易详细信息。

解决方案 2:胖事件

我们可以使用"胖事件"方法来解决上述问题。每条事件消息都包含所有相关的交易详细信息。我们将数据直接嵌入到每个事件中。因此无需进行额外的 REST 调用。它创建了一个完全异步的 EDM 架构。

{
   "identifier": 2,
   "detail": "sale transaction item",
   "created_date": 4587997988425,
   "last_modified_date": 1845298016540
}

完整的事件驱动架构

整个系统对大量事件的响应更快。我们在事件中拥有所有必要的信息。每个服务都可以独立运行，而无需实时依赖其他服务。

解决方案 3:发件箱模式

我们将处理的数据视为金融交易。保持准确性很重要。这需要一种可靠的方法来确保所有事件都得到传递和处理，而不会丢失任何数据。在这里，我们应用了发件箱模式。

什么是发件箱模式?

我们首先在发件箱模式中的数据库表中保存事件消息，而不是直接发布事件消息。然后，作业会将这些事件分批处理并定期发送。

Outbox Pattern 工作流

• 事件生成 − 业务模块发布事件。
• 持久化事件 − 事件服务将事件消息存储在关系数据库 (RDBMS) 中。
• 触发作业 − 调度程序启动发送事件消息作业。
• 发布消息 −事件服务检索存储的事件并使用 RabbitMQ 等消息代理发布这些事件。

发件箱模式的优势

• 持久事件 − 由于事件保存在关系数据库中，因此它具有 ACID 属性，因此数据是持久的。
• 丢失事件的恢复 − 如果事件发布失败。它可以从数据库中重新发送。

发件箱模式的缺点

• 增加了复杂性 − 因为它在架构中添加了另一层管理。
• 延迟发布 −事件可以间隔发布，而不是实时发布。

EDM 架构的优势

下面给出了使用 EDM 架构的一些优势 −

• 松散耦合结构 − 每个微服务都是独立的，因此灵活且模块化。
• 完全隔离 − 每个微服务无需同步调用其他服务即可运行。
• 异步处理 − 它提高了整体系统的响应能力和效率。
• 性能提升 − 服务可以在事件发生时对其做出反应。

EDM 的主要优势是松散耦合。它保留了微服务的独立性。

EDM 存在单点故障

如果您在 EDM 中使用 RabbitMQ 等消息代理，则它可能存在故障点。

但是您可以使用以下技术之一来解决这个问题 −

• 集群配置 − 您可以将 RabbitMQ 设置为集群以防止单点故障。
• 持久队列 − 您可以配置队列以进行持久化。
• 消息持久性 − 您可以存储消息以供以后检索，即使在代理暂时中断的情况下也是如此。

如果发生错误，集群中的其他实例可以接管。因此可以恢复持久化的消息。

重复事件消息

有时，一个事件可能会发布多次。但是您可以使用以下技术来防止重复消息的问题 −

幂等消费者 −消费者应该用来处理重复事件。在采取行动之前，它应该首先检查这些事件是否已经处理过事件。

在微服务架构中，您需要保持松散耦合以实现有效通信。您可以使用事件驱动 (EDM) 方法来减少对直接 REST 调用的依赖。EDM 避免了同步通信的问题，例如等待响应和处理服务中断。

我们设置了一个带有持久消息的 RabbitMQ 集群。服务可以发布事件而无需立即确认。胖事件具有提高效率所需的所有数据。发件箱模式具有可靠的事件传递，即使在出现网络问题和临时中断的情况下也是如此。

结论

EDM 用于保持微服务的独立性和松散耦合。您可以高效且可扩展地在 EDM 中处理实时数据。但是，如果微服务变得相互依赖。那么架构就有转变为分布式整体的风险。因此，您应该使用事件驱动设计保持松散耦合。

事件驱动微服务的用例

事件驱动架构 (EDA) 用于需要灵活性且流程可以实时响应的应用程序。我们可以使用 EDM 创建、检测和处理事件。事件是状态的变化，例如用户输入、系统通知、数据更新等。这些事件会触发系统中的不同响应。

事件生产者生成事件并将其发送到消息代理(也称为事件路由器和事件总线)。消息代理将事件传播给消费者。

EDM 架构中的组件是松散耦合的。以下是 EDM 架构中的组件 –

• 事件生产者 −它们生成事件并将其发送到事件路由器。
• 事件路由器 − 它们在生产者和消费者之间进行事件路由。
• 事件消费者 − 它们接收事件并提供服务。
• 事件存储 − 它记录所有事件以用于审计、调试和重放目的。

事件驱动的微服务有几个用例，其中一些我们将在本章中重点介绍。

电子商务平台的 EDM

我们将 EDA 与微服务结合使用以进行异步通信。它具有优势，因为它是一个松散耦合的系统。因此它在独​​立的服务之间进行通信。传统的请求-响应可能会失败，但 EDM 不会失败，因为 EDM 具有松散耦合的异步系统。服务可以使用 EDM 中的发布-订阅模型独立运行。

例如，假设有一个电子商务平台，您可以在其中销售、开票和仓储服务以完成订单。我们使用 EDM 来处理销售事件，而无需等待下游服务(如开票)的可用性。我们填写服务并暂时下线。服务恢复后，事件将进入队列并进行处理。因此，它避免了对最终用户的干扰。

实时客户的 EDM

我们可以使用 EDA 来支持实时和面向客户的更新。我们将内部事件驱动系统连接到面向客户的界面。当事件发生时，我们会向用户提供反馈。

例如，让我们考虑一家在线商店。如果付款失败，EDA 可以向用户更新原因(例如，信用卡被拒、网络问题)。请求-响应调用不需要依赖。它改善了用户体验。因此我们可以向用户更新重要交易的实时信息。

EDM 用于实时数据分析

我们可以在实时数据分析中使用 EDA。我们在事件发生时处理这些事件。EDM 最大限度地减少了数据处理的延迟，因此我们可以实时分析。例如，事件驱动的仪表板可以为您提供包裹位置、运输延迟等的实时更新。我们可以使用车辆上的 IoT 传感器的数据，监控货运情况，了解最新状态，并向客户和运营商提供更新。

EDM 物联网 (IoT) 应用程序

我们可以在 IoT 应用程序中使用 EDA。设备会生成事件(例如，传感器读数、状态变化)。这些设备可以使用 EDA 将数据发送给订阅的消费者，以进行实时监控和控制。

例如，让我们考虑具有 IoT 的供应链，其中传感器发送有关位置、温度等的更新。我们使用 EDA 来获取这些更新。因此，我们可以实时跟踪货物并应对温度偏差等中断。

EDM 用于欺诈检测和安全监控

EDA 可以检测到可疑活动和模式导致的欺诈。它会对这些活动和模式做出响应。EDM 可防止未经授权的交易和安全漏洞。例如，在银行应用程序中，如果发生异常交易(例如，在陌生位置进行大额提款)。EDA 可以触发事件，提醒用户和银行欺诈检测团队进行验证。

EDM 用于库存和供应链管理

EDA 保持最佳库存水平，因为它会实时触发库存更新。因此，供应链运营将非常高效。

例如，在零售业，EDA 可防止缺货，因为它会实时跟踪库存。当某件商品的数量低于给定阈值时。然后触发事件以订购更多库存并提醒仓库经理。

EDM 用于医疗保健监控和警报

我们可以使用 EDA 医疗保健进行监控。因此医院可以响应关键患者数据。例如，当生命体征超过给定阈值时，患者监控设备会发出事件。EDA 将这些警报发送给医生。因此他们会对危急情况做出反应。

EDM 用于端到端交易跟踪

我们可以在整个生命周期内监控交易。因此它为您提供透明度和主动管理。例如，在支付处理系统中，交易的每个阶段(授权、捕获、结算)都会发出事件。我们可以跟踪和验证这些事件。因此我们可以识别任何阶段的问题，例如付款失败和延迟。

EDM 用于跨区域数据同步

我们可以使用 EDM 跨多个区域进行数据复制。因此分布式系统中将具有一致性和冗余性。例如，视频流平台可以使用 EDA 跨区域同步用户关注列表和进度数据。当一个地区的用户更新他们的关注列表时。然后会触发一个事件，以在其他地区复制此数据。

用于客户通知的 EDM

EDA 在推动实时性方面发挥着重要作用。因此可以在有针对性的营销中响应客户的行为。

例如，在电子商务环境中，如果客户将商品添加到购物车中但离开网站时没有购买。那么 EDA 可以触发后续电子邮件提醒和折扣通知。它鼓励他们完成购买。

结论

我们在各种应用程序中使用 EDA，因为它具有实时服务。它为您提供事件生产者、路由器和消费者之间的异步通信。由于服务松散耦合，每个组件都可以独立运行。

我们可以在电子商务、实时分析、物联网、欺诈检测和医疗保健监控中使用 EDA。应用程序可以在 EDA 中处理事件，因此我们可以实时跟踪交易以优化库存并响应关键患者数据。

事件驱动微服务的通信

事件驱动通信 (EDC) 是分布式系统的基础部分。应用程序中的组件响应特定事件。因此，我们根据事件的发生独立地为这些事件提供服务。我们不需要等待直接命令和连续请求。我们可以在互连环境中实时处理这些事件。我们在电子商务、金融和物联网等各个行业中使用 EDC。

事件驱动通信中有各种核心组件。每个组件都用于与服务交互。生成、路由和处理事件。这些组件是服务这些事件所必需的。我们异步且独立地运营这些服务。

下面列出了事件驱动通信的组件 −

• 事件生成
• 事件路由
• 事件消费
• 事件处理
• 消息存储
• 可扩展性和负载管理
• 监控和可观察性
• 安全管理

我们将在本章中解释这些组件 −

事件驱动通信中的事件生成

事件生成是事件驱动通信的起点。当系统内的状态发生变化时，就会产生事件。这些事件捕获特定操作，例如用户登录、付款处理、下订单等。然后将这些数据发送到系统进行处理。

事件生成组件用于执行以下功能 −

• 监控操作和状态变化，例如已完成的付款、更新的库存等。
• 生成结构化事件以包含相关详细信息。
• 将事件发送到事件代理。这些事件被存储，直到它们被路由到相关服务。

此组件构成事件驱动通信的入口点。因此数据流和反应开始。

事件驱动通信中的事件路由

一旦生成事件。我们将它们路由给他们的消费者。事件路由确保每个事件到达需要处理它的相关服务。它被称为事件代理和消息路由器。例如:Apache Kafka、RabbitMQ、AWS EventBridge 等。我们可以处理大量事件并正确发送这些事件。

EDC 的事件路由组件处理以下功能 −

• 它确保事件从生产者可靠地传递到消费者。
• 它根据定义的条件路由事件。
• 它处理延迟并管理事件流量。

事件驱动通信中的事件消费

事件路由后。服务接收这些事件并采取行动。每个事件消费者等待事件到达并做出相应反应。消费者可以包括任何需要执行操作的服务，例如更新记录、发送通知以及根据事件启动其他流程。

事件消费组件负责以下功能 −

• 它监听与其触发器匹配的事件。
• 它执行预定义的操作，例如数据库更新、通知、API 调用等。
• 它独立运行，不依赖其他服务进行直接通信。

服务松散耦合，仅在收到相关事件时响应。

事件驱动通信中的事件处理

事件处理将原始事件数据转换为可操作的见解和操作。此组件对传入事件使用逻辑，例如验证交易、验证用户操作和过滤信息以进行分析。我们需要实时处理。

事件处理组件处理以下功能 −

• 它使用业务逻辑来分析和处理传入事件。
• 它管理资源以处理大量数据。
• 它对应用程序(如支付处理和监控)具有低延迟处理。

事件驱动通信中的消息存储

消息存储暂时保存事件。它确保它们的可靠性。我们存储消息。系统可以管理到达速度快于处理速度的事件，也可以管理服务暂时中断的情况。此组件充当缓冲区。因此，如果服务可用，我们稍后会通过服务检索这些事件。

以下是消息存储可以处理的一些功能的列表 −

• 它会临时存储事件，直到消费者准备就绪。
• 它确保可靠的事件存储以防止数据丢失。
• 它提供容错能力和跨消费者的负载平衡。

事件驱动通信中的可扩展性和负载管理

由于事件驱动通信系统的可扩展性和负载管理，我们可以在事件驱动通信系统中拥有各种类型的事件。我们可以扩展资源以无延迟地处理流量变化。该组件监督资源分配和工作负载分配，以保持一致的性能。

• 监控事件流量以管理资源分配。
• 在服务之间分配工作负载
• 动态扩展资源以实时匹配事件量。

事件驱动通信中的监控

我们监控事件驱动通信以确保事件在组件之间流动。此组件可深入了解事件处理，识别可能影响系统性能的延迟和问题。

• 跟踪事件流以检测和解决问题
• 生成有关性能、延迟和资源利用率的指标
• 深入研究事件以进行调试

事件驱动通信中的安全管理

安全性在事件驱动通信中非常重要。数据在组件之间移动。可能会发生未经授权的访问和数据泄露。这可能会危及整个系统。因此，安全管理控制可以保护事件数据并确保仅授权访问。

• 对系统进行身份验证和授权访问
• 加密数据以防止未经授权的访问
• 监控异常活动和安全漏洞

EDC 的优点和缺点

下表重点介绍了事件驱动通信的一些优点和缺点 −

结论

事件驱动通信用于实时管理动态应用程序。通过异步消息传递。系统可以独立处理事件。每个服务仅在必要时运行。我们在金融、电子商务、医疗保健和物联网中使用 EDC。

事件驱动微服务的集成

我们可以将现有系统用于事件驱动架构 (EDA)。我们可以构建系统来处理不可预测的工作负载。因此它可以更快地响应客户互动。它还为您提供实时洞察，以做出数据驱动的决策。

为什么要将系统集成到事件驱动模型中?

传统架构以请求-响应为基础运行。它需要服务之间的直接和同步通信。因此，这种结构和可扩展性问题存在局限性。它增加了停机时间并延迟了数据处理。而 EDA 则异步运行。它实时广播和处理事件。例如，当零售商从请求驱动系统转移到 EDA 时。然后，其销售、库存和客户服务功能将实时保持最新状态，而不会使任何单个系统组件过载。

EDA 还提高了可扩展性，因为它在架构中具有解耦的组件。这种松散耦合意味着系统某一部分的故障不会导致级联故障。因此系统的其余部分继续运行。系统获得异步数据流。 EDA 还减少了依赖性。

EDA 与现有系统集成的关键组件

在将 EDA 与现有系统集成时，我们需要引入/更新各种组件。以下是一些重要组件 −

• 事件代理(消息代理) − 事件代理充当中央枢纽。系统中可以进行异步通信。代理的示例包括:Apache Kafka、AWS EventBridge 和 RabbitMQ。它们将传统架构与事件驱动的工作流连接起来。
• 事件路由器 − 根据定义的条件将事件路由到其消费者。它可以防止数据拥塞，因为它将事件定向到正确的系统，同时过滤掉不相关的系统。
• 事件消费者和生产者 − 现有系统和新应用程序通过将事件发布到代理或订阅接收这些事件来充当消费者和生产者。我们需要自定义适配器将数据转换为现代 EDA 的事件格式。
• 事件存储 − 它保留事件的历史记录以供追溯、审计和调试。事件存储，如 Kafka。系统可以根据需要重播事件。它支持数据完整性和恢复。
• 数据同步服务 − 为了实现传统系统和现代系统之间的实时数据一致性，这些服务从现有数据库更改并将其推送到事件总线。因此所有系统都保持最新状态。

将 EDM 与现有系统集成的步骤

以下是将 EDM 与现有系统集成的步骤 −

• 确定集成点 − 首先，我们找到实时数据可以改善业务流程的领域。我们寻找重复性任务和延迟影响客户体验的领域。
• 设置事件代理 − 我们实施事件代理来处理来自数据流的负载。它充当通往新架构的桥梁。我们使用 Kafka 等平台。我们使用连接器与旧系统集成。
• 定义事件和数据模型 − 我们会找到要发布的事件并标准化数据模型。我们可以为旧应用程序和现代应用程序创建模式。我们使用 Confluent Schema Registry for Kafka 或 AWS Schema Registry 等工具。
• 解耦旧流程 − 我们从非关键功能开始，以生成和使用事件。例如，零售公司可能从异步销售交易开始，然后再完全转换库存和供应链系统。
• 实现幂等性和重复数据删除 − 我们管理重复事件。消费者应该是幂等的。因此，多次处理同一事件会产生相同的输出。
• 监控和优化 − 我们使用监控工具来跟踪事件流、延迟和错误率。我们设置了衡量集成成功与否的指标。它会根据需要改进流程。

EDA-传统集成的示例

下面给出了一些 EDA-传统集成的示例 −

• 电子商务平台(销售和库存管理) − Shopify 和 Amazon 等零售商使用 EDA 将库存和销售服务与订购系统分离。因此，销售交易可以异步触发实时库存更新，而无需同步依赖。
• 银行和支付系统 − 花旗商业卡采用 EDA 作为其 API 平台。因此，交易会触发账户余额、报表和欺诈警报的异步更新。
• 物流和供应链 − EDA 支持 UPS 等物流公司管理复杂的供应链。我们可以使用事件驱动的方法集成现有的跟踪系统。

EDA 集成的优势和挑战

以下是 EDA 集成的优势 −

• 提高可扩展性 − 我们可以扩展单个组件而不会影响整个系统。
• 实时响应 − 系统响应数据变化。它改善了客户体验和服务交付。
• 增强的弹性 − 解耦的服务有助于隔离故障并保持系统稳定性。
• 降低操作复杂性 − 我们可以使用 EDA 替换同步流程。因此它改善了服务交互。

以下是 EDA 集成的挑战 −

• 过渡的复杂性 − 我们将 EDA 与旧系统集成。但它需要架构更改和谨慎的数据治理。
• 测试和验证 − 我们可以测试异步交互和事件流。但这些方法比传统的请求驱动方法更难。
• 可靠性和顺序一致性 − 事件应按正确的顺序处理，并且只处理一次。因此，它需要配置和错误处理。

结论

我们可以将现有系统与事件驱动架构集成。EDA 是实现此目的的最佳选择。我们可以将遗留系统集成到现代事件驱动框架中。但它需要规划、战略组件选择和分阶段方法。

---