Joh*_*ohn 8 event-sourcing microservices grpc
我正在尝试了解微服务，但对服务编排和事件溯源（服务编排）之间哪种方法更好感到困惑。似乎很少有框架允许您使用事件溯源来构建您的应用程序。相反，似乎您必须自己构建整个框架，这非常困难。
此外，网络上关于实际从事微服务的公司的大多数讨论似乎都在使用 gRPC（或其他一些 rpc）和服务之间直接调用的编排，而不是使用 sagas/events 进行事件溯源。
实施微服务的最佳方式是什么？将 gRPC 与服务编排一起使用，还是实际尝试使用服务编排和异步事件来实现事件源系统？
用于检索数据和消息传递以表达意图（命令）并提供集成/副作用（事件）的 RPC。
\n分布式系统的分解和集成有两种方法。一种很容易，另一种则更好。最简单的做事方法是精心策划或声明式。编排系统的基本思想是一个实体告诉另一个实体做什么。组织服务的另一种方法是通过编排和/或反应。编排解决了我们在声明性系统中面临的问题，例如高耦合和低内聚。
\n\n\n下游服务的变化可能不会干扰上游服务。
\n
消息传递重复数据删除器和重新排序器以及分布式事务是来自声明性系统和/或业务能力分解的一些遗产。在这种情况下，每个Entity仅由一个模型来表示所有服务，这需要分布式事务和阻塞请求来处理“有界上下文之间的事务信息”；
\n另一方面，子域分解（DDD）的主要特征之一是自治，其中每个聚合保留它需要对每个副作用（业务事实/域事件）进行隔离响应的所有实体；
\n响应式 DDD（领域驱动设计）是一种软件开发方法，它结合了领域驱动设计和响应式编程的原理来构建高度可扩展、可伸缩和弹性的系统。响应式 DDD 专注于对分布式、事件驱动、本质上响应式系统中的域行为进行建模。
\n子域分解是 DDD 的重要组成部分，在响应式 DDD 中，子域被分解以支持编排的事件驱动架构。每个子域负责管理自己的状态，并且该状态的更改通过事件进行传达。
\n考虑到设计的最终性质，事件溯源是这里最有效/最合适的持久性策略。
\n在事件发生时间、代理发送事件的频率以及订阅者处理事件的顺序等最终且不可预测的环境中，反应式 DDD 可以通过对此类“不确定性”进行建模，帮助确保系统保持响应能力和弹性。
\n通过将域建模为一组通过事件进行通信的反应性组件，系统可以设计为处理大量请求，保持一致性和可靠性，并从容地从故障中恢复。
\n响应式 DDD 是一种现代且时尚的方法，在构建复杂的分布式系统方面越来越受欢迎。它提供了一种将域分解为更小、更易于管理的部分并设计它们以支持反应式架构的方法。这可以带来更具响应性、可扩展性和弹性的系统，并且可以更好地处理最终环境的需求。
\n如果您对使用反应性域驱动设计 (DDD) 建模不确定性感兴趣，以下一些资源可能会有所帮助：
\n