深刻理解Spring Cloud与微服务构建【一】 - 1.3 微服务的不足

主要体如今以下方面。

1. 微服务的复杂度（框架知识、服务于服务通讯、服务与服务之间相互依赖）。
2. 分布式事务（重点）。
3. 服务的划分（业务场景划分边界，最好无耦合，都能单独运行和替换）。
4. 服务的部署（可选用Docker、DevOps）。

单独说下分布式事务，其他就很少作解释

1.3.1 分布式事物

• 微服务架构所设计的系统是分布式系统。分布式系统有一个著名的 CAP 理论，即同时知足“一致性”“可用性”和“分区容错”是一件不可能的事。
• Consistency：指数据的强一致性。若是写入某个数据成功，以后读取，读到的都是新写入的数据：若是写入失败，以后读取的都不是写入失败的数据。
• Availability：指服务的可用性。
• Partition-tolerance：指分区容错。

• 在分布式系统中，P 是基本要求，而单体服务是 CA 系统。 微服务系统一般是一个 AP系统，即同时知足了可用性和分区容错。这就有了一个难题：在分布式系统中如何保证数据的一致性？这就是大 家常常讨论的分布式事务。
• 在微服务系统中，每一个服务都是独立的进程单元， 每一个服务都有本身的数据库。 一般状况下，只有关系型数据库在特定的数据引擎下才支持事务，而大多数非关 系型数据库是不支持事务的，例如 MongDB 是不支持事 务的，而 Redis是支持事务的。 在微服务架构中，分布 式事务一直都是一个难以解决的问题，业界给出的解决 办法一般是两阶段提交。

网上购物在平常生活中是一个很是普通的场最，假设我在淘宝上购买了一部手机，须要从个人帐户中扣除 1000 元钱，同时手机的库存数量须要减 1。固然须要在卖方的帐户中加 1000 元钱，为了使案例简单化，暂时不用考虑。
若是这是一个单体应用，而且使用支持事务的 MySQL 数据库 ClnnoDB 数据库引擎才支 持事务），咱们可能这样写代码：

@Transactional  
public void update () throws RuntimeException( 
    updateAccountTable (); 11更新帐户表 
    updateGoodsTable (); 11更新商品表 
}

若是是微服务架构，帐户是一个服务，而商品是一个服务，这时不能用数据库自带的事务，由于这两个数据表不在一个数据库中。所以经常用到两阶段提交，两阶段提交的过程

• 第一阶段， service-account 发起一个分布式事务，交给事务协调器 TC 处理，事务协调器 TC 向全部参与的事务的节点发送处理事务操做的准备操做。 全部的参与节点执行准备操做， 将 Undo 和 Redo 信息写进日志，并向事务管理器返回准备操做是否成功。
• 第二阶段，事务管理器收集全部节点的准备操做是否成功，若是都成功，则通知全部的节 点执行提交操做；若是有一个失败，则执行回滚操做。

两阶段提交，将事务分红两部分可以大大提升分布式事务成功的几率。若是在第一阶段都 成功了，而执行第二阶段的某一个节点失败，仍然致使数据的不许确，这时通常须要人工去处 理，这就是当初在第一步记录日志的缘由。另外，若是分布式事务涉及的节点不少，某一个节 点的网络出现异常会致使整个事务处于阻塞状态，大大下降数据库的性能。因此通常状况下， 尽可能少用分布式事务。