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

在近期举办的 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 同时也发布了这次演讲的幻灯片。

查看英文原文： Microservices for a Streaming World