一文网罗分布式架构原理和方法( 二 ) _分布式架构

文章插图

目前流行的 Service Mesh 开源软件有 Linkerd、Envoy 和 Istio，而最近 Buoyant（开源 Linkerd 的公司）又发布了基于 Kubernetes 的 Service Mesh 开源项目 Conduit 。
关于微服务和服务网格的区别，我这样理解：微服务更注重服务之间的生态，专注于服务治理等方面，而服务网格更专注于服务之间的通信，以及和 DevOps 更好的结合等。
服务网格的特征

应用程序间通讯的中间层
轻量级网络代理
应用程序无感知
解耦应用程序的重试/超时、监控、追踪和服务发现

六、分布式架构的基本理论在说 CAP、BASE 理论之前，我们先要了解下分布式一致性的问题。实际上对于不同业务的服务，我们对数据一致性的要求是不一样的，如 12306，它要求数据的严格一致性，不能把票卖给用户以后却发现没有座位了;再比如银行转账，我们通过银行转账的时候，一般都会收到一个提示 : 转账申请将会在 24 小时内到账。实际上这个场景满足的是最终钱只要转账成功了即可，同时如果钱没汇出去还要保证资金不丢失。所以说，用户在使用不同的服务的时候对数据一致性的要求是不一样的。
关于分布式一致性问题
分布式系统中要解决的一个非常重要的问题就是数据的复制。在我们的日常开发经验中，相信大多数开发人员都遇过这样的问题 : 在做数据库读写分离的场景中，假设客户端 A 将系统中的一个值 V 由 V1 变更为 V2，但客户端 B 无法立即读取到 V 的最新值，而需要在一段时间之后才能读取到。这再正常不过了，因为数据库复制之间存是在延时的。

文章插图

所谓分布式一致性的问题，就是指在分布式环境中引入数据复制机制后，不同数据节点之间可能会出现的、且无法依靠计算机应用程序自身解决的数据不一致的情况。简单来说，数据一致性就是指在对一个副本数据进行变更的时候，必须确保也能够更新其它的副本，否则不同副本之间的数据将出现不一致。那么如何去解决这个问题呢？按照正常的思路，我们可能会想到既然是网络延迟导致的问题，那么我们就把同步动作进行阻塞，用户 2 在查询的时候必须要等数据同步完成以后再来做。但这个方案会非常影响性能。如果同步的数据比较多或比较频繁，那么阻塞操作可能会导致整个新系统不可用。故我们没有办法找到一种既能够满足数据一致性、又不影响系统性能的方案，所以就诞生了一个一致性的级别:

强一致性 : 这种一致性级别是最符合用户直觉的，它要求系统写入的是什么，读出来的也要是什么，用户体验好，但实现起来往往对系统的性能影响较大。
弱一致性 : 这种一致性级别约束了系统在写入成功后，不保证立即可以读到写入的值，也不保证多久之后数据能够达到一致，但会尽可能地保证到某个时间级别(如秒级别)后，数据能够达到一致状态。
最终一致性 : 最终一致性其实是弱一致性的一个特例，系统会保证在一定时间内，能够达到数据一致的状态。这里之所以将最终一致性单独提出来，是因为它是弱一致性中非常推崇的一种一致性模型，也是业界在大型分布式系统的数据一致性上用的比较多的一致性模型。

CAP 理论
它是一个经典的分布式系统理论。CAP 理论告诉我们 : 一个分布式系统不可能同时满足一致性(C:Consistency)、可用性(A:Availability)及分区容错性(P:Partition tolerance) 这三个基本要求，最多只能同时满足其中两项。CAP 理论在互联网界有着广泛的知名度，也被称为“帽子理论”，它是由 Eric Brewer 教授在 2000 年举行的 ACM 研讨会提出的一个著名猜想: 一致性(Consistency)、可用性(Availability)、分区容错 (Partition-tolerance)三者无法在分布式系统中被同时满足，并且最多只能满足两个!

一致性 : 所有节点上的数据时刻保持同步
可用性 : 每个请求都能接收一个响应，无论响应成功或失败
分区容错 : 系统应该持续提供服务，即使系统内部(某个节点分区)有消息丢失。比如交换机失败、网址网络被分成几个子网，形成脑裂、服务器发生网络延迟或死机，导致某些 server 与集群中的其他机器失去联系。

分区是导致分布式系统可靠性问题的固有特性，从本质上来看，CAP 理论的准确描述不应该是从 3 个特性中选取两个，所以我们只能被迫适应，根本没有选择权。CAP 并不是一个普适性原理和指导思想，它仅适用于原子读写的 NoSql 场景中，并不适用于数据库系统。