忘川彼岸|我只是下了个订单，鬼知道我在微服务里经历了什么？( 四 ) 【51CTO.com原创稿件】面试的时候

基础服务一般属于互联网平台基础性的支撑服务，比方说，电商网站的基础服务有订单服务，商品服务，用户服务等。
这些都属于比较基础和原子性，下沉一个公司的基础设施的低层，向下承接存储，向上提供业务能力，有些公司叫基础服务，中间层服务，公共服务， Netflix 成为中间层服务。我们暂且统称为基础服务。
②微服务聚合服务层
已经有了基础服务能提供业务能力，为什么还需要聚合服务，因为我们有不同的接入端，如 App 和 H5 ， PC 等等，它们看似调用大致相同的数据，但其实存在很多差异。
例如 PC 需要展示更多信息， App 需要做信息裁剪等等。一般低层服务都是比较通用的，基础服务应该对外输出相对统一的服务，在抽象上做得比较好。
但是对不同的外界 App 和 PC 的接入，我们需要作出不同的适配，这个时候需要有一个层去做出聚合裁剪的工作。
例如一个商品详情在 PC 端展示和 App 端的展示， PC 可能会展示更多的信息，而 App 则需要对信息作出一些裁剪。
如果基础服务直接开放接口给到 PC 和 App ，那么基础服务也需要去做成各种设配，这个很不利于基础服务的抽象。
所以我们在基础层之上加入聚合服务层，这个层可以针对 PC 和 App 做成适当的设配进行相应的裁剪。
那么我们的微服务中，又增加了一个服务，属于聚合服务。
好了，接下来可以愉快的 Coding...

等等，貌似不对，如果是单块应用加上事务应该没问题，这里是分布式，恐怕得考虑加分布式事务。
分布式事务
我们来理一理创建订单和扣件库存模块之间的关系：
可以发现，因为微服务的原因，我们把服务进行了分布式，随着各个数据库也随着变成分布式每个数据库不一定存在相同的物理机中。
那么这个时候单个数据库的 ACID 已经不能适应这种情况，而在这种集群中想去保证集群的 ACID 几乎很难达到，或者即使能达到那么效率和性能会大幅下降，最为关键的是再很难扩展新的分区了。
这个时候如果再追求集群的 ACID 会导致我们的系统变得很差，这时我们就需要引入一个新的理论原则来适应这种集群的情况，就是 CAP 。
CAP 定理
CAP 必须满足以下的 3 个属性：

一致性(C)：在分布式系统中的所有数据备份，在同一时刻是否同样的值。 (等同于所有节点访问同一份最新的数据副本)
可用性(A)：在集群中一部分节点故障后，集群整体是否还能响应客户端的读写请求。 (对数据更新具备高可用性)
分区容错性(P)：以实际效果而言，分区相当于对通信的时限要求。系统如果不能在时限内达成数据一致性，就意味着发生了分区的情况，必须就当前操作在 C 和 A 之间做出选择。

简单的来说，在一个分布式系统中，最多能支持上面的两种属性。但显然既然是分布式注定我们是必然要进行分区，既然分区，我们就无法百分百避免分区的错误。因此，我们只能在一致性和可用性去作出选择。