在微服务中保证服务的一致性

在近期举办的QCon London大会上,Ben Stopford在他的演讲中极力主张拥抱去集中化的思想、构建基于服务的系统,并通过流处理工具解决分布式状态所引起的问题。

Stopford目前任职于Confluent,参与Kafka的开发工作。对他来说,构建基于服务的系统的理由有很多,包括松耦合、边界上下文、易于扩展等等,这些特性让我们能够构建出可以随着时间的推移而不断改进的系统。但是,通过这种方式,我们实质上是在创建分布式的系统,而分布式系统自有其本身的复杂性,并且在延迟与故障等方面还存在着种种问题。

Stopford描述了分布式系统的两种基本模式:

以请求-响应的方式对服务进行解耦,通常使用REST的服务实现。它很适合于UI以及提问的场景。 事件驱动,这种模式的特征是异步的,或是“fire and forget”的消息传递。它非常适合于设计跨服务的复杂依赖。

这两种模式可以结合使用,例如使用请求-响应模式实现一个REST接口,随后以事件的方式进行后台处理。

Stopford随后对异步与基于事件的通信,例如队列的使用展开了讨论。他认为这种模型非常简单,只要做到一次只取出一条消息,就能够保证消息的次序。即使将这一方式进行一定程度的扩展,仍然可以保证它的次序,但Stopford指出,在某些情况下,我们或许会失去可用性或是次序的保证。他还指出了该方式的另一个缺点,即消息的存在是短期的,因此服务一旦出现故障,就无法回到之前的时间点再次读取这些消息了。

Stopford认为,更好的方法是使用某种分布式日志支持服务的开发,并以Kafka为例。Kafka是基于日志的概念而设计的,而日志是一种只增的数据结构。因此读写操作都非常高效,对于读操作来说,只需定位到某个位置,并进行顺序读取。而对写操作来说,所做的只是简单的添加而已。

分布式的日志系统还能够为微服务带来以下好处:

始终在线,这依赖于某种容错的代理,例如Kafka。 负载均衡,每个服务实例都将从一个代理中读取数据。 容错性,这是因为服务可能会产生故障转移,但消息的次序仍然保持不变。 倒带和回放,当系统发现了某个错误并修复之后,服务可以找回原始的消息,并进行回放。

但这种方式仍然有一个未解决的问题,即保持服务的一致性。因为在系统发生故障等一些情况下,很难避免出现一些重复的消息(“即至少一次”的提交机制)。因此,服务在处理他们收到的消息时必须保证幂等性(idempotent)。从逻辑上说,这相当于创建了一种“正好一次”的提交机制。Stopford表示,这一功能在Kafka中尚未实现(但相关功能已经在开发中了)。

Martin Kleppmann在本次大会的另一场演讲中也提到了服务一致性的问题。

QCon的参会者已经可以欣赏Stopford的演讲了,而InfoQ的读者很快也能够欣赏到演讲的内容。Stopford同时也发布了这次演讲的幻灯片。



本文转自d1net(转载)

上一篇:.NET设计模式(14):代理模式(Proxy Pattern)


下一篇:微服务介绍