服务设计要解决的问题

　　前几天和同事聊天，同事说：

　　“业务的服务（相对于我们基础架构这边的底层技术）在技术上就需要解决三个问题：分布式、通信和存储。”

　　我回忆之前做业务的时光，觉得确实，再加上一个“服务治理”就差不多了。想想“服务设计要解决的问题”这个话题可以把之前静儿写的很多文章做一个归纳概括。今天做一个总结。

分布式

通常要解决的问题是分布式事务的一致性问题。

刚性事务和柔性事务

　　刚性事务：严格遵循ACID原则（原子性、一致性、隔离性、持久性）的事务。基本上指的是本地数据库事务。根据CAP原则，分布式下的事务都不是刚性事务。

　　柔性事务：遵循CAP理论或者其变种BASE理论的事务。分布式事务基本上都是柔性事务。

　　因为刚性事务基本上等价于本地数据库事务，而柔性事务基本上等价于分布式事务。只是一个是按照事务严格性来区分，一个是按使用场景来区分。所以平时除了用来做对比，很少直接提刚性事务和柔性事务的概念。

分布式事务理论

　　分布式事务：在分布式环境下，各个操作步骤并不在同一台机器上，需要保证所有动作都有一个统一的结果的一组操作。

　　CAP原则（记得在之前的博客中多次写过）：分布式环境下，数据一致性、服务可用性、分区容错性三者最多只能满足其中二者。

　　　　数据一致性（consistency）:这里的一致性是强一致性，又叫线性一致性。即一个写操作成功，而读出的必须是写操作后的新数据。而写操作失败读出的必须是写操作前的旧数据。

　　　　服务可用性（availability）:所有的操作在一定时间内都能得到响应。

　　　　分区容错性（partition-tolerance）:在网络分区环境下，被分割的节点仍然能对外提供服务。

选择说明

AP分隔的节点同时对外服务但不能相互通信，将导致状态不一致，即不能满足C

CP网络分区的情况下为达成C，请求只能一直等待，即不满足A

CA在一定时间内要达到节点状态一致，要求不能出现网络分区，则不能满足P

　　BASE理论：这是基于CAP理论权衡之后的结果。核心思想是即使无法做到强一致性，但可以使用一些技术手段达到最终一致。BASE是Basically Available(基本可用)、Soft state(软状态)、Eventually consistent(最终一致性)的缩写。

分布式事务一致性实现方案

　　为了解决分布式一致性问题，前人在性能和数据一致性的权衡过程中总结了许多经典的协议和算法。比较著名的有：2PC、3PC、TCC、Paxos、Raft、Zab、ISR。除了这些之外，业界用的最多的其实是基于MQ实现的。

　　2PC（Two Phase Commit）两阶段提交:一般说的两阶段提交是基于XA协议的。另外JTA协议的也比较常见。

　　XA是一个分布式事务协议。它大致分为两部分：事务管理器和本地资源管理器。其中本地资源管理器往往由数据库实现，比如Oracle、DB2都实现了XA接口。MySQL对XA的支持不是很好。而事务管理器作为全局的调度者，负责各个本地资源的提交和回滚。

两阶段提交的优点是：原理简单、实现方便。缺点是同步阻塞、单点问题、数据不一致。

　　3PC(Three Phrase Commit)三阶段提交：分为CanCommit、PreCommit、Do Commit 三个阶段。就是把两阶段提交的Phase 1分成两个，预提交的时候如果有参与者返回No或者超时则中断事务。

　　三阶段提交的优点是降低参与者阻塞范围，并能够在出现单点故障后继续达成一致。缺点是因为preCommit阶段，在这个阶段如果出现网络分区，协调者无法与参与者正常通信，参与者仍然会进行实物提交，造成数据不一致。

　　TCC(Try-Confirm-Cancel)

　　　　Try:完成所有的检查，预留必须资源

　　　　Confirm:使用Try阶段预留的资源执行业务，如果执行出现异常，要重试

　　　　Cancel:释放Try阶段预留资源

　　　　TCC能够对分布式事务中的各个资源进行分别锁定，分别提交与释放。适用于严格一致、执行时间短、实时性要求高的场景。

　　Paxos算法：之前看过《从Paxos到Zookeeper》那本书，没怎么看明白。实现比较复杂，Zookeeper就是用这个来实现的分布式一致性。Paxos算法、Raft协议和Zab（Zookeeper Atomic Broadcast）协议都是一种通过多数投票来保证主备数据一致性的。

　　ISR（In-Sync Replicas）机制：Kafka使用了这个机制来保证数据一致性。ISR认为对于2f+1个副本来说，多数投票机制要求最多只能允许f个副本发生故障，如果要支持2个副本的容错，则需要至少维持5个副本。

通信……