《Java架构师的第一性原理》61系统架构之分布式基础，通俗易懂CAP

1 分布式基础，通俗易懂CAP？

分布式系统非常关注三个指标：

• 数据一致性

• 系统可用性

• 节点连通性与扩展性 

1）关于一致性

数据“强一致性”，是希望系统只读到最新写入的数据，例如：通过单点串行化的方式，就能够达到这个效果。

关于session一致性，DB主从一致性，DB双主一致性，DB与Cache一致性，数据冗余一致性，消息时序一致性，分布式事务一致性，库存扣减一致性，详见文章《究竟啥才是互联网架构“一致性”》。

2）关于可用性

如果系统每运行100个时间单位，会有1个时间单位无法提供服务，则说系统的可用性是99%。

可用性和可靠性是比较容易搞混的两个指标，以一台取款机为例：

• 正确的输入，能够取到正确的钱，表示系统可靠

• 取款机7*24小时提供服务，表示系统可用 

保证系统高可用的方法是：

• 冗余

• 故障自动转移

反向代理层，站点层，服务层，缓存层，数据库层各层保证系统高可用的方法，详见文章《究竟啥才是互联网架构“高可用”》。

3）关于连通性与扩展性

分布式系统，往往有多个节点，每个节点之间，都不是完全独立的，需要相互通信，当发生节点无法联通时，数据是否还能保持一致，系统要如何进行容错处理，是需要考虑的。

同时，连通性和扩展性紧密相关，想要加机器扩展性能，必须有良好的连通性。当一个节点脱离系统，系统就出现问题，往往意味着系统是无法扩展的。

反向代理层，站点层，服务层，缓存层，数据库层各层保证系统扩展性的方法，详见文章《究竟啥才是互联网架构“可扩展”》。

什么是CAP定理？

CAP定理，是对上述分布式系统的三个特性，进行了归纳：

• 一致性(Consistency)

• 可用性(Availability)

• 分区容忍性(Partition Tolerance)

并且，定理指出，在系统实现时，这三者最多兼顾两点。

一致性，可用性，多节点扩展性三者只能取其二，既然加锁已经加上，常见的最佳工程架构实践是什么呢？

互联网，最常见的实践是这样的：

• 节点连通性，多节点扩展性，连通性异常的处理必须保证，满足P

• 一致性C与可用性A一般二选一

• 选择一致性C，举例：传统单库水平切分，就是这类选型的典型

• 选择可用性A，举例：双主库同步高可用，就是这类选型的典型

强一致很难怎么办？

单点串行化，虽然能保证“强一致”，但对系统的并发性能，以及高可用有较大影响，互联网的玩法，更多的是“最终一致性”，短期内未必读到最新的数据，但在一个可接受的时间窗口之后，能够读到最新的数据。

例如：数据库主从同步，从库上的数据，就是一个最终的一致。

总结

• CAP可以理解为一致性，可用性，联通与扩展性

• CAP三者只能取其二

• 最常见的实践是AP+最终一致性

思路比结论重要。

2 互联网分层架构的本质

2.1 潜移默化的分层结构

 

 

 

上图是一个典型的互联网分层架构：

• 客户端层：典型调用方是browser或者APP

• 站点应用层：实现核心业务逻辑，从下游获取数据，对上游返回html或者json

• 数据-缓存层：加速访问存储

• 数据-数据库层：固化数据存储

如果实施了服务化，这个分层架构图可能是这样：

 中间多了一个服务层。

同一个层次的内部，例如端上的APP，以及web-server，也都有进行MVC分层：

• view层：展现

• control层：逻辑

• model层：数据

可以看到，每个工程师骨子里，都潜移默化的实施着分层架构。

2.2 分层结构的本质

那么，互联网分层架构的本质究竟是什么呢？

如果我们仔细思考会发现，不管是跨进程的分层架构，还是进程内的MVC分层，都是一个“数据移动”，然后“被处理”和“被呈现”的过程，归根结底一句话：互联网分层架构，是一个数据移动，处理，呈现的过程，其中数据移动是整个过程的核心。

如上图所示：

数据处理和呈现要CPU计算，CPU是固定不动的：

• db/service/web-server都部署在固定的集群上

• 端上，不管是browser还是APP，也有固定的CPU处理

数据是移动的：

• 跨进程移动：数据从数据库和缓存里，转移到service层，到web-server层，到client层

• 同进程移动：数据从model层，转移到control层，转移到view层

 

 

 

数据要移动，所以有两个东西很重要：

• 数据传输的格式

• 数据在各层次的形态

先看数据传输的格式，即协议很重要：

• service与db/cache之间，二进制协议/文本协议是数据传输的载体

• web-server与service之间，RPC的二进制协议是数据传输的载体

• client和web-server之间，http协议是数据传输的载体

再看数据在各层次的形态，以用户数据为例：

• db层，数据是以“行”为单位存在的row(uid, name, age)

• cache层，数据是以kv的形式存在的kv(uid -> User)

• service层，会把row或者kv转化为对程序友好的User对象

• web-server层，会把对程序友好的User对象转化为对http友好的json对象

• client层：最终端上拿到的是json对象

结论：互联网分层架构的本质，是数据的移动。

为什么要说这个，这将会引出“分层架构演进”的核心原则与方法：

• 让上游更高效的获取与处理数据，复用

• 让下游能屏蔽数据的获取细节，封装

弄清楚这个原则与方法，再加上一些经验积累，就能回答网友经常在评论中提出的这些问题了：

• 是否需要引入DAO层，什么时机引入

• 是否需要服务化，什么时机服务化

• 是否需要抽取通用中台业务，什么时机抽取

• 是否需要前后端分离，什么时机分离

（网友们的这些提问，其实很难回答。在不了解业务发展阶段，业务规模，数据量并发量的情况下，妄下YES或NO的结论，本身就是不负责任的。）

更具体的分层架构演进细节，下一篇和大家细究。 

总结

• 互联网分层架构的本质，是数据的移动

• 互联网分层架构中，数据的传输格式（协议）与数据在各层次的形态很重要

• 互联网分层架构演进的核心原则与方法：封装与复用

思考

哪一个系统的架构，不是“固定CPU，移动数据”，而是“固定数据，移动CPU”呢？

对于MapReduce系统架构，“固定数据，移动CPU”更为合理。

99 直接读这些牛人的原文

分布式系统原理介绍