在微服务中保证服务的一致性
当在近期举办的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同时也发布了这次演讲的幻灯片。