分布式架构的发展和演进之路

1、为什么要使用分布式架构

2、分布式基本概念

2.1 高可用

2.2 集群

2.3 负载均衡

2.4 分布式

2.5 正向代理和反向代理

2.6 集群与分布式，SOA与微服务区别和联系

3、分布式架构演进之路

3.1 单体应用架构

3.2 垂直架构

3.3 分布式架构（独立子系统）

3.4 分布式架构（通信子系统，微服务）

4、分布式架构带来的问题

4.1 网络延迟：性能、超时

4.2 网络故障：丢包、乱序、抖动

4.3 一致性问题

4.4 CAP定理

1、为什么要使用分布式架构

1946年,世界上第一台电子计算机在美国的宾夕法尼亚大学诞生,它的名字是：ENICAC ,这台计算机的体重比较大,计算速度也不快,但是而代表了计算机时代的到来,再以后的互联网的发展中也有基础性的意义。

计算机的组成是有五部分完成的,分别是:输入设备,输出设备,存储器,CPU里面有运算器和控制器,有一个冯诺依曼的模型非常形象的对象计算机的组成进行了描述,不过计算机也是有数据流,指令流,控制流来进行计算的和正常运转的。如图:

ENIAC之后,电子计算机进入到了IBM主导的大型机的时代, 在1946年第一台IBM大型机SYSTEM/360诞生,这使得IBM在20世纪50~60年代统治了整个大型计算机的工业，在大型主机时代,计算机架构向两个方向发展CISC(微处理器执行的计算机语言指令集)CPU为架构的价格便宜的个人PC和RISC(精简指令集计算机)价格高的小型UNIX服务器。

大型主机的出现,凭借着计算能力和处理能力,高的稳定性和安全性,在很长的一段时间内引领到计算领域的发展。但是集中式的计算机系统来带来了一些问题,来越来越不能满足用户的需求比如说:

1.大型的主机非常贵,一般的小企业用不起。

2.大型主机比较复杂，培养人才的成本比较高。

3.单点问题,如过大型机出现故障,整个系统都挂掉，运行不了,使企业的损失非常大。

4.随着技术的进步,个人PC电脑的性能越来越高,成本也越来越低。

我们都知道一个成熟的大型网站的系统架构并非一开始就设计的非常完美，也没有一开始就具备高性能、高并发、高可用、安全性等特性，而是随着用户量的增加、业务功能的扩展逐步演变过来的，慢慢的完善的。在这个过程中，开发模式、技术架构等都会随着迭代发生非常大的变化。而针对不同业务特征的系统，各自都会有自己的侧重点

例如：

像淘宝这类的网站，要解决的重点问题就是海量商品搜索、下单、支付等问题;

像腾讯这类的网站，要解决的是数亿级别用户的实时消息传输;

像百度这类的公司所要解决的是海量数据的检索（还得让金主爸爸们的广告放在首页...）。

每一个种类的业务都有自己不同的系统架构。

2、分布式基本概念

在介绍架构之前，为了避免部分读者对架构设计中的一些概念不了解，下面对几个最基础的概念进行介绍：

2.1 高可用

系统中部分节点失效时，其他节点能够接替它继续提供服务，则可认为系统具有高可用性。

还不明白的话，举例：

会所要保证用户的体验性，就必须要保证不能因为某一位技师请假而导致客户不能享受到服务，所以我们需要准备多位可以提供相同服务技师备用

2.2 集群

一个特定领域的软件部署在多台服务器上并作为一个整体提供一类服务，这个整体称为集群。如Zookeeper中的Master和Slave分别部署在多台服务器上，共同组成一个整体提供集中配置服务。在常见的集群中，客户端往往能够连接任意一个节点获得服务，并且当集群中一个节点掉线时，其他节点往往能够自动的接替它继续提供服务，这时候说明集群具有高可用性。

还不明白的话，举例：

会所原来只有一个技师，按摩推拿洗脚DBJ全干。后来客人多了，会所一个技师忙不过来，又请了几十个技师，几十个技师都能提供一样的服务，这些技师的关系就是集群。

2.3 负载均衡

请求发送到系统时，通过这些方式把请求均匀分发到多个节点上，使系统中每个节点能够均匀的处理请求负载，则可认为系统是负载均衡的。

还不明白的话，举例：

现在会所有一群技师进行服务，但是如果没有一定的规则的话，技师服务的效率比较低，服务的效果也比较差，所以我们制定一个策略（比如轮询）：我们将技师进行排号，来了客人后一个个去上钟；当然如果出现了这么一种情况，某位技师DBJ技术比较好，速度比较快，我们会让这个技师挣更多的钱（让她多上钟）----这个就是权重

2.4 分布式

系统中的多个模块在不同的服务器上部署，即可称为分布式系统，如Tomcat和数据库分别部署在不同的服务器上，或两个不同功能的Tomcat 分别部署在不同的服务器上。

还不明白的话，举例：

为了让技师A专心做好其中某一项服务XBJ,把服务做到极致,又请了个技师B专门负责DBJ,技师A和技师B的关系就是分布式的,如果技师B一个负责DBJ也忙不过来,又请了个技师C,那么技师B和技师C的关系就是集群了。所以说有分布式的架构中可能有集群,但集群不等于有分布式。

2.5 正向代理和反向代理

系统内部要访问外部网络时，统一通过一个代理服务器把请求转发出去，在外部网络看来就是代理服务器发起的访问，此时代理服务器实现的是正向代理；

当外部请求进入系统时，代理服务器把该请求转发到系统中的某台服务器上，对外部请求来说，响应它的只有代理服务器，此时代理服务器实现的是反向代理。

简单来说，正向代理是代理服务器代替系统内部来访问外部网络的过程，反向代理是外部请求访问系统时通过代理服务器转发到内部服务器的过程，一般来说反向代理在实际生产中用得比较多，正向代理用得比较少，但是也不是说不用，比如那些年让你们深恶痛绝的校园网就是（学校花一台代理服务器的钱，让你们共享整个外部网络，玩个游戏不卡才怪！）。

还不明白的话，举例：

会所对外的广告肯定不能是自己派那些漂亮性感的技师抛头露面的发传单，可以找黄牛进行宣传找客户，这样对于会所来说，客户只认识黄牛，而不知道会所的具体情况，保证了会所的安全性（万一碰上了便衣，顶多也就损失一位婀娜的MM，但是保护了很多多姿的MM）-----这就是正向代理

相反当客户需要会所技师提供服务时，直接找黄牛带路去会所找到可以为自己提供DBJ服务的会所技师，这样对于客户来说，只需要手握一个黄牛的联系方式，就可以找到各种婀娜多姿的MM的DBJ服务（不需要自己一个个去踩坑，是不是很爽？）-----这就是反向代理

2.6 集群与分布式，SOA与微服务区别和联系

2.6.1 分布式与集群

集群：相同的人干同样的事

分布式：不同的人配合干同一件“大”事

2.6.2 SOA与微服务

2.6.3 分布式和微服务

分布式：分散压力

微服务：分散能力

PS：本身没有严格的区别和关系，一般来说大型的互联网项目都是基于微服务的分布式架构

3、分布式架构演进之路

3.1 单体应用架构

最开始的应用架构，是一台服务器，开着一个web服务，一个数据库服务。这时候的应用性能受服务器性能影响，web服务跟数据库服务共享一个cpu，承受并发有限。

单体应用架构演变：

当应用服务已经无法承受当前流量时，先将web服务与数据库拆分到不同的服务器，能有效的提高web并发和数据库的并发能力。

这个阶段的系统架构如下图所示，应用服务器和数据库服务器完全隔离开来，相互互不影响，大大减少了网站宕机的风险

这样的话，web服务和数据库因为单独使用一台服务器，受压能力提升。但是比如当流量进一步提升时，web服务首先承受不住压力，要么提升服务器配置（垂直扩展），要么多台服务器进行负载均衡（水平扩展）。这时候需要有个分发请求的负载均衡器。

3.2 垂直架构

这个阶段，随着访问量的继续不断增加，单台应用服务器已经无法满足我们的需求。假设我的数据库服务器还没有遇到性能问题，那我们可以通过增加应用服务器的方式来将应用服务器集群化，这样就可以将用户请求分流到各个服务器中，从而达到继续提升系统负载能力的目的。此时各个应用服务器之间没有直接的交互，他们都是依赖数据库各自对外提供服务。

系统架构发展到这个阶段，各种问题也会接踵而至：

用户请求交由谁来转发到具体的应用服务器上(谁来负责负载均衡)
用户如果每次访问到的服务器不一样，那么如何维护session，达到session共享的目的。

那么此时，系统架构又会变成如下方式：

接下来，为了能够缓解数据库压力，这时候就需要对数据库进行水平扩展（读写分离），继续演变成如下架构：

接下来，因为关系型数据库的吞吐上限太小，随着业务量增加，访问量继续增加，我们会引入搜索引擎和缓存来提升服务性能：

整个系统能承受的并发高了，但是发现每个系统可扩展性不高，web服务到底还是一个单一的系统，当系统庞大起来时，难于维护。这时候就需要服务化了。

3.3 分布式架构（独立子系统）

基础服务化后，各个功能比较明细，系统的扩展性比较高，当某个服务承受不住压力时，可以为该服务新增服务器，并且根据每个功能服务的需要进行相应的服务器配置，物尽其用。

这样拆分以后，可能会有一些相同的代码，比如用户操作，在商品和交易都需要查询，所以会导致每个系统都会有用户查询访问相关操作。这些相同的操作一定是要抽象出来，否则就是一个坑。所以通过走服务化路线的方式来解决。

3.4 分布式架构（通信子系统，微服务）

　那么服务拆分以后，各个服务之间如何进行远程通信呢? 通过 RPC 技术，比较典型的有:dubbo、webservice、hessian、http、RMI 等等。前期通过这些技术能够很好的解决各个服务之间通信问题，但是，互联网的发展是持续的，所以架构的演变和优化也还在持续，这个并不是最终的架构形式，就如十年前面对垂直架构一般。

4、分布式架构带来的问题

我们基于网络构建分布式系统，将多个系统连接起来，就要面临我们使用单体架构时不会遇到的问题。

4.1 网络延迟：性能、超时

同机房的网络IO还是比较块的，但是跨机房，尤其是跨IDC（互联网数据中心），网络IO就成为不可忽视的性能瓶颈了。并且，延迟不仅仅只是带宽，带宽可以随便增加，千兆网卡换成万兆，只是成本的问题，物理限制带来的延迟（比如两个相互通信的服务器跨越东西两个半球），基本不可能降低（这也是为什么阿里云，华为云这些云服务提供商需要把服务器划分为几个大区，就是为了尽量避免物理上带来的限制）。

这带来的问题就是系统整体性能的降低，会带来一系列的问题，比如资源的锁住，所以系统调用一般都要设置一个超时时间进行自我保护，但是过度的延迟就会带来系统的RPC调用超时，引发一个令人头疼的问题：分布式系统调用的三态结果：成功、失败、超时。不要小看这个第三态，这几乎是所有分布式系统复杂性的根源。

针对这个问题有一些相应的解决方案：异步化，失败重试。而对于跨IDC数据分布带来的巨大网络因素影响，则一般会采用数据同步，代理专线，区域内网等处理方式。

4.2 网络故障：丢包、乱序、抖动

这个可以通过将服务建立在可靠的传输协议上来解决，比如TCP协议。不过带来的是更多的网络交互。因此是性能和流量的一个条件交换，这个在移动互联网中更需要考虑。

4.3 一致性问题

分布式系统中的一致性指应用系统的一致性和数据的一致性。多个系统之间互相通信，就有可能遇到例如：

(1) 调用超时：系统A调用系统B超时，系统A得到超时反馈，但不确定系统B是否已经处理结束，就会造成不一致。

(2) 掉单：系统A和系统B分别为对方的上下游，如果系统A中存在一个订单，而系统B中不存在，就会导致掉单。

(3) 缓存与数据库的不一致：面对海量的访问请求，我们经常会需要在数据库前加一层缓存，这个缓存与数据库之间如何保证一致性也是我们需要考虑的。

我们解决一致性模型主要分三种：

Strong Consistency（强一致性）：新的数据一旦写入，在任意副本任意时刻都能读到新值。比如：文件系统，RDBMS，Azure Table都是强一致性的。

Week Consistency（弱一致性）：不同副本上的值有新有旧，需要应用方做更多的工作获取最新值。

Evantual Consistency（最终一致性）：一旦更新成功，各副本的数据最终将达到一致。如：订单支付

从这三种一致型的模型上来说，我们可以看到，Weak和Eventually一般来说是异步冗余的，而Strong一般来说是同步冗余的(多写)，异步通常意味着更好的性能，但也意味着更复杂的状态控制。同步意味着简单，但也意味着性能下降。

4.4 CAP定理

CAP定理，指的是在一个分布式系统中，Consistency（一致性）、 Availability（可用性）、Partition tolerance（分区容错性），最多实现两点，三者不可兼得。CAP定理主要是针对分布式系统各节点之间的通信提出的定理。

一致性（C）：在分布式系统中的所有数据备份，在同一时刻是否同样的值。

可用性（A）：在集群中一部分节点故障后，集群整体是否还能响应客户端的请求。

分区容错性（P）：分布式系统中的节点之间的通信有可能失败，在这种情况下，系统要能够容纳这种错误。

分布式系统中必然存在着网络分区，而由于当前的网络硬件肯定会出现延迟丢包等问题，所以分区容错性是我们必须需要实现的。所以CAP定理，C与A我们只能择其一实现。那么为什么实现P的情况下，C与A不可兼得呢，我们来分析一下：

假设节点A与节点B，它们中的数据是一致的，我们发起请求，修改了节点A中的数据，节点B中的数据也要相应的更改，但是出现了网络延迟等问题，节点B中的数据没有更改，依然是旧数据。这时，请求节点B中的数据，但是数据还没有同步，那怎么办呢？

1、如果我们要满足一致性，就应阻塞这次请求，等节点B中的数据得到更改，这样可用性就无法满足；

2、如果我们要满足可用性，那么我们就要返回节点B中的旧的数据，这样一致性就无法满足。

所以我们就需要结合实际情况做出取舍，是满足一致性还是满足可用性。