有关分布式状态和微服务的讨论

16-07-07 banq
                   

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。

A Discussion on Distributed State and Microservice