大数据分析：浅谈分布式架构

一．什么是分布式

简单的说，“分工协作，专人做专事”就是分布式的概念。就好比你是你们公司唯一的码农，那么前后端都需要你自己来开发（单体架构），但随着业务的增长，你确实忙不过来了，老板给你招来了一个前端，那么你就只需要专注后端开发就行了（分布式）。但是软件的分布式搭建远远不像现实例子中这么简单，需要考虑和处理很多方面的问题，我们先了解以下几个常见的概念：

集群：你们公司业务增长的非常快，老板发现你一个后端忙不过来了，就又招了几个后端开发来协助你，这就是后端集群；再往后，发现前端也忙不过来了，又配备几个前端，就是前端集群。所以也不难看出，将应用拆分后，你可以有针对性地扩展单个服务，做成集群，这就是分布式的好处之一。

节点：这个也非常好理解，一个服务就是一个节点，比如你就是后端集群中的一个节点，而集群本身也可以看成是整个应用的一个集群节点。

副本：副本就是为服务和数据提供的冗余，保证高可用。

中间件：为开发者提供便利，屏蔽复杂的底层的一类框架组件。如服务管理通信、序列化、负载均衡等组件。

上图就是一个简单的分布式架构，但并不是所有的应用一开始就要设计为分布式架构，因为一开始业务量并不大，没有必要耗费大量的时间和成本去完成一个分布式架构，甚至有可能到最后都用不上，因此在设计时我们应该遵循演进原则，由简入深。

二、分布式集群架构

1、纯负载均衡形式

在集群前面，前置一个流量分发的组件进行流量分发，整个集群的机器提供无差别的服务，这在常见的 web 服务器中是最最常见的。目前比较主流的方式就是整个集群机器上云，根据实时的调用量进行云服务器弹性伸缩。常见的负载均衡有硬件层面的 F5、软件层面的 nginx 等。

2、领导选举型

整个集群的消息都会转发到集群的领导这里，是一种 master-slavers，区别只是这个 master 是被临时选举出来的，一旦 master 宕机，集群会立刻选举出一个新的领导，继续对外提供服务。使用领导选举型架构的典型的应用有 ElasticSearch，zookeeper。

3、区块链型

整个集群的每一个节点都可以进行记录，但是记录的内容要得到整个集群 N 个机器的认可才是合法的。典型的应用有 Bit Coin，以及 Hyperledger。

4、master-slaver型

整个集群以某台 master 为中枢，进行集群的调度。交互是这样，一般会把所有的管理类型的数据放到 master 上，而把具体的数据放到 slaver 上，实际进行调用的时候，client 先调用 master 获取数据所存放的 server 的 信息，再自行跟 slave 进行交互。典型的系统有 Hadoop。集群，HBase 集群，Redis 集群等。

5、规则型一致性Hash

这种架构类型一般出现在数据库分库分表的设计中。按照规则进行分库分表，在查询之前使用规则引擎进行库和表的确认，再对具体的应用进行访问。为什么要用一致性 Hash ？其实用什么都可以，只是对于这类应用来说一致性 Hash 比较常见而已。

三、分布式系统面临的问题

通信异常

分布式系统需要在各个节点之间进行网络通信，因此网络通信都会伴随着网络不可用的风险或是系统不可用都会导致最终分布式系统无法顺利完成一次网络通信。另外，即使分布式系统各节点之间的网络通信能够正常进行，其延时也会远大于单机操作，会影响消息的收发的过程，因此消息丢失和消息延迟变得非常普遍。

网络分区

当网络由于发生异常情况，导致分布式系统中部分节点之间的网络延时不断增大，最终导致组成分布式系统的所有节点中，只有部分节点之间能够进行正常通信，而另一些节点则不能——我们将这个现象称为网络分区，就是俗称的“脑裂”。当网络分区出现时，分布式系统会出现局部小集群，在极端情况下，这些局部小集群会独立完成原本需要整个分布式才能完成的功能，这就对分布式一致性提出类非常大的挑战。

三态

分布式系统的每一次请求与响应，存在特有的“三态”概念，即成功、失败与超时。当出现超时现象时，网络通信的发起方是无法确定当前请求是否被成功处理的。

节点故障

节点故障则是分布式环境下另一个比较常见的问题，指的是组成分布式系统的服务器节点出现的宕机或“僵死”现象。

四、分布式架构的高可用设计

在分布式架构中，常常面临的两个矛盾的问题是一致性和高可用，这两个是无法同时满足的，那我们舍谁取谁呢？从用户的角度分析，我们宁可获取到旧数据，也不愿意等半天都打不开应用，所以常常是保证高可用，让数据达到最终一致性，那么如何设计高可用的分布式架构呢？主要从以下几个方面：

搭建服务集群，提高负载，避免单点故障。尤其是特别重要的服务，如访问量较高的服务和核心服务（一旦挂掉就会导致整个应用不可用的服务）。

应对灾难，搭建异地灾备，预防地区因发生地震、台风等自然灾害导致地区的集群服务器都不可用。

接口限流以及服务降级。为防止过高的并发量造成服务器负载过高而出现故障，应对接口限流，同时，当某个或多个服务出现故障时，应当服务降级，避免拖累整个应用。比如支付时因网络故障等导致无法支付，但搜索商品和下单仍然可用。

故障监控报警。