在微服务通信领域，同步和异步交互是作为微服务之间调用架构的关键要素。Dapr不仅简化了应用程序交互，满足同步和异步模式，而且还支持高级编排(Choreograph)和排舞(Orchestration)模式。
编舞(Choreograph)与排舞(Orchestration)之间的争论：
- EDA异步的人喜欢编舞，它是去中心化、事件驱动特性，并将其描绘成未来的趋势。（异步）
- 而工作流引擎供应商则会强调排舞带来的清晰度、控制力和可管理性。（同步）
- 服务网格的倡导者将强调实时请求/响应驱动交互的好处，并隐藏 API 管理所提供的实施细节...（同步）
- 流处理爱好者将增强事件驱动架构和模式注册表的优点。（异步）
微服务交互风格
从整体架构到微服务的转变导致服务通信模式从整体系统中典型的进程内通信转变为微服务中的进程间通信。这一变化带来了新的挑战和考虑，包括性能、耦合、错误处理等，进而导致多种服务交互方式的出现：
- 请求-响应（同步）：一个微服务向另一个微服务发送请求并等待响应。
- 事件驱动（异步）：微服务发出事件供其他服务使用。发射器仍然不知道哪些服务（如果有）消费其事件。
对于基本的交互来说，这些模式已经足够了，但是当涉及到复杂的场景时，例如跨越多个服务的业务事务，则需要更复杂的机制。
Saga模式是一系列本地事务，其中每个事务更新数据库并发布消息或事件以触发下一步，解决了这种跨服务协调问题。它使应用程序能够在多个服务之间维护数据一致性，而无需使用分布式事务。如果本地事务由于违反业务规则而失败，saga 会执行补偿事务以撤消先前事务所做的更改，从而确保系统范围的一致性和协调。
这种模式可以通过两种主要方法来实现：编舞(Choreograph)与排舞(Orchestration)
- 编舞：在这种方法中，每个本地事务都会发布触发其他服务中的本地事务的域事件。该模型对于减少依赖性并允许更灵活和解耦的架构特别有效。
- 排舞：在这里，编排器指示参与者执行哪些本地事务。该模型提供了一个更加受控的环境，其中服务交互、状态维护和错误处理的顺序至关重要。
编舞在没有集中控制的情况下运行，对于有界上下文之间的通信特别有效。在这种方法中，来自一个服务的事件可以触发另一个服务中的操作，而发出服务对其事件使用者而言保持不可知。
相反，排舞在有界上下文中提供了一种结构化方法，确保专注于状态维护和错误处理的服务交互的受控序列。
当开发人员探索这一领域时，他们经常会发现自己利用事件和命令来利用同步和异步交互。根据特定需求和上下文识别适当的模型对于构建可扩展和可扩展的微服务架构至关重要。
实际上，根据业务环境和要求，同步/异步、编舞和排舞都有自己的用武之地。
- 同步交互通常需要一个全面的堆栈，用于服务发现、网络弹性、可观察性和安全性，可选择在网络层运行的服务网格、NAT 或 Consul 或特定语言库，如 Java 的 Hystrix 和 Resilience4j，.Net 的 Polly。
- 另一方面，异步交互需要 Apache Kafka 或 RabbitMQ 等代理，通常还需要搭配模式注册表、连接器、REST 代理、Debezium 等变更数据捕获解决方案以及其他操作和治理工具。
Dapr：分布式应用程序的统一编程模型
Dapr 为服务通信和基础设施使用提供了统一的 API。Dapr的API基于sidecar架构，封装了多种服务交互方式，确保它们和谐共存并适应不断变化的业务需求：
- 服务调用：用于同步服务到服务通信，此 API 为请求/响应模式提供服务发现。它处理跨领域的问题，例如弹性、可观察性和跟踪，以及包括网络加密和访问控制在内的安全功能。
- 发布-订阅：专为事件驱动的交互和编排而设计，该 API 使服务能够发布事件并订阅主题，从底层代理实现细节中抽象出来。它确保松散耦合，同时添加容错功能，例如死信队列、至少一次传递保证、重试、断路器、消息 TTL 和访问策略。
- 工作流：此 API 有助于在分布式环境中定义和管理工作流，通过可用的工作流模式（例如任务链、分支扇出/扇入以及对其他服务的异步调用）确保多个服务的和谐协调。
- 具有事务发件箱的状态存储：此 API 提供状态管理功能并在数据突变时发出事件，确保数据一致性和事件驱动的响应能力。它结合了并发控制、数据隔离、容错和其他横切问题（例如访问控制）。
Dapr 的优势不仅在于其单独的 API，还在于能够将它们有效地组合在单个堆栈和编程模型中。
它为开发人员（无论其语言和框架如何）提供了使用 HTTP 或 gRPC 构建分布式应用程序的工具，同时始终解决横切问题。此外，Dapr 的工作流引擎旨在与其 API 套件协同工作，简化开发流程，并确保应用程序可维护、可扩展且能够适应不断变化的业务动态。