分布式概述

相关定义

分布式（distributed）

分布式（distributed）是为了解决单个物理服务器容量和性能瓶颈问题而采用的优化手段，将一个业务拆分成不同的子业务，分布在不同的机器上执行。服务之间通过远程调用协同工作，对外提供服务。

该领域需要解决的问题极多，在不同的技术层面上，又包括：分布式缓存、分布式数据库、分布式计算、分布式文件系统等，一些技术如MQ、Redis、zookeeper等都跟分布式有关。

分布式两种形式

从理念上讲，分布式的实现有两种形式：

水平扩展：当一台机器扛不住流量时，就通过添加机器的方式，将流量平分到所有服务器上，所有机器都可以提供相同的服务；

垂直拆分：前端有不同业务需求时，一台机器扛不住流量，可以将不同的业务需求分发到不同的机器上，比如A机器处理余票查询的请求，B机器处理支付的请求。

集群（cluster）

集群（cluster）是指在多台不同的服务器中部署相同应用或服务模块，构成一个集群，通过负载均衡设备对外提供服务。

集群两个特点

可扩展性：集群中的服务节点，可以动态的添加机器，从而增加集群的处理能力。

高可用性：如果集群某个节点发生故障，这台节点运行的服务，可以被其他服务节点接管，从而增强集群的高可用性。

集群两大能力

负载均衡：负载均衡能把任务比较均衡地分布到集群环境下的服务节点上。

集群容错：集群服务调用失败后，服务框架能够根据容错策略在底层自动容错，不影响服务的正常提供

微服务（Mocroservice）

微服务就是很小的服务，小到一个服务只对应一个单一的功能，只做一件事。这个服务可以单独部署运行，服务之间通过远程调用协同工作，每个微服务都是由独立的小团队开发，测试，部署，上线，负责它的整个生命周期。

维基上对其定义为：一种软件开发技术- 面向服务的体系结构（SOA）架构样式的一种变体，它提倡将单一应用程序划分成一组小的服务，服务之间互相协调、互相配合，为用户提供最终价值。每个服务运行在其独立的进程中，服务与服务间采用轻量级的通信机制互相沟通（通常是基于HTTP的RESTful API）。每个服务都围绕着具体业务进行构建，并且能够独立地部署到生产环境、类生产环境等。另外，应尽量避免统一的、集中式的服务管理机制，对具体的一个服务而言，应根据上下文，选择合适的语言、工具对其进行构建。

多线程（multi-thread）

多线程（multi-thread）：多线程是指程序中包含多个执行流，即在一个程序中可以同时运行多个不同的线程来执行不同的任务。多线程是为了提高CPU的利用率。

高并发（High Concurrency）

高并发（High Concurrency）是一种系统运行过程中发生了一种“短时间内遇到大量请求”的情况，高并发对应的是访问请求，多线程是解决高并发的方法之一，高并发还可以通过分布式，集群，算法优化，数据库优化等方法解决。

分布式系统设计理念

分布式系统的目标与要素

分布式系统的目标是提升系统的整体性能和吞吐量，另外还要尽量保证分布式系统的容错性（假如增加10台服务器才达到单机运行效果2倍左右的性能，那么这个分布式系统就根本没有存在的意义）。

即使采用了分布式系统，我们也要尽力运用并发编程、高性能网络框架等等手段提升单机上的程序性能。

分布式系统设计两大思路：中心化和去中心化

中心化设计

两个角色：Leader & Worker

中心化的设计思想很简单，分布式集群中的节点机器按照角色分工，大体上分为两种角色：“领导”和“干活的”角色

职责：

“领导”通常负责分发任务并监督“干活的”，发现谁太闲了，就想方设法地给其安排新任务，确保没有一个“干活的”能够偷懒，如果“领导”发现某个“干活的”因为劳累过度而病倒了，则是不会考虑先尝试“医治”他，而是一脚踢出去，然后把他的任务分给其他人。

其中微服务架构Kubernetes就恰好采用了这一设计思路。

“领导”的安危问题

中心化设计的问题中心化的设计存在的最大问题是**“领导”的安危问题**，如果“领导”出了问题，则群龙无首，整个集群就奔溃了。但我们可以同时安排两个“领导”以避免单点问题。

中心化设计还存在另外一个潜在的问题，既“领导”的能力问题：可以领导10个人高效工作并不意味着可以领导100个人高效工作，所以如果系统设计和实现得不好，问题就会卡在“领导”身上。

领导安危问题的解决办法：

大多数中心化系统都采用了主备两个“领导”的设计方案，可以是热备或者冷备，也可以是自动切换或者手动切换，而且越来越多的新系统都开始具备自动选举切换“领导”的能力，以提升系统的可用性。

去中心化设计

众生地位平等：

在去中心化的设计里，通常没有“领导”和“干活的”这两种角色的区分，大家的角色都是一样的，地位是平等的，全球互联网就是一个典型的去中心化的分布式系统，联网的任意节点设备宕机，都只会影响很小范围的功能。

“去中心化”不是不要中心，而是由节点自由选择中心。

（集群的成员会自发的举行“会议”选举新的“领导”主持工作。最典型的案例就是ZooKeeper及Go语言实现的Etcd）

“脑裂”问题

去中心化设计里最难解决的一个问题是**“脑裂”问题**，这种情况的发生概率很低，但影响很大。脑裂指一个集群由于网络的故障，被分为至少两个彼此无法通信的单独集群，此时如果两个集群都各自工作，则可能会产生严重的数据冲突和错误。

“脑裂”问题解决方法

一般的设计思路是，当集群判断发生了脑裂问题时，规模较小的集群就“自杀”或者拒绝服务。