有关分布式状态和微服务的讨论
CQRS应该是实现分布式状态的一种挑战性实现，挑战点在于：对于站在数据前面的微服务，我们如何能连接到这些数据集？我们如何获得服务的同意达成分布式一致的状态？
CAP理论提供分布式状态的模型实现，给定的可用性 一致性和分区性，只能三个之中选择两个，如果你能够降低要求，则同时这三个都可以获得，降低要求的一个办法是引入临时解耦体也就是时间，以牺牲一点点时间的代价获得一致性和可用性的保证，大部分系统就会ok。
1.X/Open协议/分布式事务（在Java中是通过JTA API支持），这是一个可怕的注意，这引入了巨大的SPOF(单一故障点)，大部分今天我们工作的资源都没有实现这个协议，比如HTTP API 消息API，AMQP或Kafka。
2.最终一致性：这是消息，使用消息作为引入的临时解耦体，通过降低时间要求破解CAP，RabbitMQ或Apache Kafka这么做。
3.Saga模式：产生于上个世纪80年代，适合长任务事务，定义一个交错事务集合，所谓交错事务是：第二个事务开始于第一个事务结束之前，Saga通过语义补偿返回系统在语义上一致状态，但是补偿式事务必须是幂等的，系统必须能够反复重试直至补偿事务成功完成。
4.CQRS：是最终一致性的复杂版本，实则是分离数据的读写，读写数据之间的同步引入消息机制，通过消息将写操作数据发送到读数据一边重播，这也就是Event SOurcing，事件存储保存是一系列事件，每次有新事件，发送新消息给总线，发给那些订阅的消费者，从而更新读这边的缓存数据或数据库。
那么，微服务如何从CQRS获得好处？微服务代表有界的上下文，
数据是在API后面，客户端和API交互，是直接和数据交互，API能够隐藏数据操作细节，微服务仅仅知道，这个数据属于其领域，如果我们遭遇来自不同数据源的数据需要以事务方式操作，那么CQRS是符合逻辑上这种需要，特别是结合Event Sourcing。