微服务的目标是去中心化

微服务的目标是去中心化

亿仁网

百家号17-09-2416:02

单块应用的一个主要缺点就是将所有的事物集中在单个（或少量）软件组件和数据库中。这样做多半会产生超大的数据存储以及对工作流的集中式控制。而该数据存储是需要根据公司业务成长的需求不断复制与扩容的。

微服务的目标是去中心化。相比于构建超大的数据库，它选择根据前文提到的业务单元来对数据进行拆分。

一些读者会将事务性作为主要的理由从而拒绝使用微服务。先来看看下面的场景：

1.一个客户在面向微服务的网店中购买了一件商品。

2.当进入支付环节时，系统发出了如下调用：

（1）向公司的财务系统发起请求，创建了一个支付的事务。

（2）向仓储系统发起请求，通知对客户购买的书籍进行发货操作。

（3）向邮件系统发起请求，为客户订阅新闻邮件。

在一个单块软件中，所有的调用都被包装在一个事务中。因此，如果有某些原因导致任何一个调用失败，其他调用涉及的所有数据都不会持久化到数据库中。

当你开始学习数据库设计时，首先接触到的一个重要原则便是ACID，它是以下四个属性的缩写。

原子性：每一个事物要么全部生效，要么全部回滚。只要有一部分失败，不会有任何变更持久化到数据库中。

一致性：事务中产生的数据变更会得到一致性保证。

隔离性：事务并发执行产生的系统状态将与事务串行执行产生的状态保持一致。

持久性：一旦事务被提交，数据将被持久化。

在一个面向微服务的软件中，ACID原则是无法得到全局保证的。微服务将会在本地提交事务，但是并没有机制能保证100%完整的全局事务。在上面的场景中，可能会出现没有处理支付就已经发货的情况，除非我们提前制定了特定的规则来防止这样的情况发生。

在一个面向微服务的架构中，数据的事务性是无法保证的，所以我们要在实现中考虑到失败的因素。一种解决该问题的方式（或者称之为一种变通的方案更为合适）是将管理与数据存储去中心化。

在构建微服务的时候，我们需要对下面的因素进行考量并将应对方案纳入设计之中。即一个或多个组件可能会发生失败，而我们需要根据软件的可用性来对功能进行降级。

让我们来看看下面这幅图。

该图表示了单块软件中的一组执行序列。不管怎样，这一系列调用的执行都应当遵守ACID原则：要么所有调用（事务）都成功，要么什么都不做。为此，框架和数据库引擎的设计者提出了事物的概念来保障数据的事务性。当我们与微服务打交道时，不得不提及一个概念，工程师们称之为最终一致性。当事务的一部分发生失败后，每个微服务实例都应该将用于恢复事务的信息存储下来，以便于这些信息能达到最终一致性。根据前面提到的例子，如果我们对书籍执行发货操作而没有处理好支付，那么支付网关将会产生一个失败的事务，并需要有机制在事后进行补偿处理，从而再次达成数据的一致性。

来源：https://baijiahao.baidu.com/s?id=1579407210993836352&wfr=spider&for=pc