分布式系统服务框架Zookeeper介绍与原理实现

分布式数据管理之痛点

为了确保微服务之间松耦合，每个服务都有自己的数据库, 有的是关系型数据库（SQL），有的是非关系型数据库（NoSQL）。

开发企业事务往往牵涉到多个服务，要想做到多个服务数据的一致性并非易事，同样，在多个服务之间进行数据查询也充满挑战。

我们以一个在线B2B商店为例，客户服务 包括了客户的各种信息，例如可用信用等。

管理订单，提供订单服务，则需要验证某个新订单与客户的信用限制没有冲突。

在单体应用中，订单服务只需要使用传统事务交易就可以一次性检查可用信用和创建订单。

相反微服务架构下，订单和客户表分别是相应服务的私有表，如下图所示：

订单服务不能直接访问客户表，只能通过客户服务发布的API来访问或者使用分布式事务, 也就是众所周知的两阶段提交 (2PC)来访问客户表，2PC意义图如下所示：

这里存在两个挑战，第一个挑战是2PC除要求数据库本身支持外，还要求服务的数据库类型需要保持一致。

但是现在的微服务架构中，每个服务的数据库类型可能是不一样的，有的可能是MySQL数据库，有的也可能是NoSQL数据库；

第二个挑战是如何实现从多个服务中查询数据。假设应用程序需要显示一个客户和他最近的订单。如果订单服务提供用于检索客户订单的API，那么应用程序端可以通过JOIN方式来检索此数据，即应用程序首选从客户服务检索客户，并从订单服务检索客户的订单。

然而，如果订单服务仅支持通过其主键查找订单（也许它使用仅支持基于主键的检索的NoSQL数据库）， 在这种情况下，就没有方法来检索查询所需的数据。

为解决这两大痛点，就需要我们使用到分步式数据管理了。

分布式数据管理之举措

在介绍分布式数据管理（CRUD）解决方案之前，有必要介绍下CAP原理和最终一致性相关概念。

CAP原理和最终一致性

CAP原理(CAP Theorem)

在足球比赛里，一个球员在一场比赛中进三个球，称之为帽子戏法(Hat-trick)。在分布式数据系统中，也有一个帽子原理(CAP Theorem)，不过此帽子非彼帽子。CAP原理中，有三个要素：