分布式系统是支持分布式处理的软件系统，是由通信网络互联的多处理机体系结构上执行任务的系统。包括分布式操作系统、分布式程序设计语言及其编译系统、分布式文件系统分布式数据库系统等，当然这些也是分布式的关键技术。

优势：

1.增大系统容量。我们的业务量越来越大，而要能应对越来越大的业务量，一台机器的性能已经无法满足了，我们需要多台机器才能应对大规模的应用场景。所以，我们需要垂直或是水平拆分业务系统，让其变成一个分布式的架构。

2.加强系统可用。我们的业务越来越关键，需要提高整个系统架构的可用性，这就意味着架构中不能存在单点故障。这样，整个系统不会因为一台机器出故障而导致整体不可用。所以，需要通过分布式架构来冗余系统以消除单点故障，从而提高系统的可用性。

3.因为模块化，所以系统模块重用度更高

4.因为软件服务模块被拆分，开发和发布速度可以并行而变得更快

5.系统扩展性更高

6.团队协作流程也会得到改善

现在的架构很多，各种各样的，如高并发架构、异地多活架构、容器化架构、微服务架构、高可用架构、弹性化架构等，还有和这些架构相关的管理型的技术方法，如 DevOps、应用监控、自动化运维、SOA 服务治理、去 IOE 等等，还有很多。

那什么是分布式系统？分布式系统是支持分布式处理的软件系统，是由通信网络互联的多处理机体系结构上执行任务的系统。包括分布式操作系统、分布式程序设计语言及其编译系统、分布式文件系统分布式数据库系统等，当然这些也是分布式的关键技术。

现在的互联网项目是分布式的时代，到底什么是分布式呢，分布式是怎样的结构，又解决了写什么问题呢，这里转载一篇宏观文章:http://www.cnblogs.com/Survivalist/p/8012266.html#3863158

传统项目的架构:(很老了，现在起码都是mvc架构了，服务数据分开)

特点:1.all in one(所有模块在一起，技术也不分层)，2.servlet(jsp)缺点:1.并发量差2.容错性差(不具有高可用性)

注:不具有高可用性的意思是，比如当用户访问时，服务器后台因为一些原因导致服务器崩溃，用户就能直接看到错误页面，服务器也因为错误从而停止运行(宕机)，这就叫做不具有高可用性。

解决方案:1.分层开发(可以提高并发量)2.mvc架构3.服务器的分离部署如图是改进结构:

image 集群架构:

image

特点:

1.项目采用多台服务器集群部署

2.mysql数据库采用多台服务器集群部署

优势:

1.并发量提高(1000 )

2.容错性提高(具有高可用性)

注:一般的it公司，基本都是采用集群架构，因为这种架构方式已经基本能满足需求了，但是一些大型项目，这种方式就显然是力不从心了，只能采用分布式的架构方式

但是，通过上图我们发现这种集群部署存在两个问题，

session如何共享?选择哪个作为解释请求的服务器呢?session如何共享

我们都知道，session是会话，即一个用户访问服务器的时候，就会产生一个session，这个session会一致伴随着这个用户的访问全程，直到用户关闭浏览器结束这次会话，那么问题来了，问，挖掘技术哪家强?咳咳，错了，是如果用户访问服务器时，这台服务器挂掉了(宕机)，那么原先保存在这台服务器上的session也肯定挂掉了，那么就会产生一个后果，就是这个用户原本访问好好的，现在突然session没有了，而session没有了就意味着需要用户重新登陆才能进行一些相应操作，这显然是不行的，这样的服务用户体验实在太差了，根本不能满足互联网行业的用户需求，那么这就涉及到一个session共享的问题，即怎么把原有的session从一台服务器转移到另一台服务器上，但是怎么解决呢?有多种方案，常用的两种是:

第一种解决方案:用Tomcat集群复制(广播模式)来共享session:

这种解决方案是利用Tomcat来进行集群复制，把每个服务器上的session都共享式的都复制一遍，保证每个服务器上都有着一个用户的session数据

应用场景:

在传统项目中一般这么应用，因为传统项目的用户量少，可以承担压力，但当到互联网项目时，这种方式就绝对不可取了，打个比方，比如用户量有100万，那么就需要在每个服务器上都复制这100万个用户的session，这样做显然会极大的消耗系统资源，使系统变得极为臃肿和不稳的，所以在互联网项目里是绝对不会采用这种方式的

缺点:当有大量用户时，服务器的压力会亚历山大，所以只适合用户访问量小的传统项目

第二种解决方案:

用第三方redis服务器来存储session

用这种方式来存储session的话，只需当前正在使用的项目把所有session都放在redis里面，当有其他项目需要使用时，就可以直接从redis中直接获取session，从而解决了这个问题

示例如图:

image 怎么解决选择哪个作为解释请求的服务器呢?

用nginx服务器来分发请求，实现负载均衡。

这种架构的并发量是多少呢?大概是1000 左右，如果服务器更多的话，能达到1000以上，一万以下，但是这能满足互联网的极致要求呢?答案当然是不能了，虽说也可以不断的扩展服务器，但是对于公司的成本和维护成本来说，无疑会达到一个非常高昂的消耗，比如说一台最便宜的服务器的价格大概是3到5万，假如要抵御一万的并发，每台服务器能支持200的并发率，那么需要多少台服务器?50台!这还仅是单击版的，还构建集群呢?比如说构建3台服务器，3*50=150台，服务器构建完了，数据库呢?数据库也需要构建集群呀!这就又是好几百台，这么一算下来大概的费用就是好几百万了，这仅仅是配置的费用，还没有计算维护的成本呢?比如说我们都知道服务器对于机房的要求是非常苛刻的，比如恒温，无尘等等(题外话:阿里之所以把云计算基地定在杭州就是看中了那里气温稳定，适合布置服务器集群)。这样一来又需要布置大型的机房，综合以上所述，虽说集群能后解决部分问题，但并不能解决所有问题，无论是从公司成本还是运营成本来说，显然这种传统的集群架构是不适应现在的互联网行业的，而且对于一般的公司来说也不可能去花大价钱做这种布置。所以，这种情况下我们就必须对我们的架构来进行优化了，那么如何在服务器只有一定数量的情况下，让我们的项目的成本能达到一定控制，并且让我们的项目达到一个最优化的并发的访问量呢?那么就需要对现有的这种架构进行再次拆分，让我们的项目成为面向服务的分布式架构。

面向服务的分布式架构(SOA):

远程框架:

image

如图所示，第一种方式还是有着明显的缺点的，如服务层的网路抖动或是服务层进程繁忙，可能有人对这两个名词不太理解，这里就解释一下:

网络抖动:当有大量用户访问时，可能会出现service层的延迟现象，而web层因为长期得不到响应，则会抛出时间超出异常

进程繁忙:这个的意思和前边的差不多，都是指service层业务太多，顾不上web层的请求，web层的请求就只能一直在那等着，时间长了也就抛出超时异常了

服务治理中间件dubbo image

原理讲解:看了第一种webservice的方法之后，我们采用了第二种方法，即dubbo这种中间件的方式，采用这种方式有什么好处呢?

好处:当服务器启动时service会把所有的对象通过dubbo注册给zookeeper，而以后每次需要请求获取对象时，就可以直接从dubbo中异步获取，不需要再去访问service层，这样就解决了服务层网络抖动和服务层进程繁忙的弊端。zeekeeper可以看成是一个数据库，用来存储数据的。

springcloud

这个软件是由外国开发，原理和dubbo差不太大。Spring Cloud是一个基于Spring Boot实现的微服务架构开放工具。它为微服务架构中设计的配置管理、服务治理、断路器、智能路由、微代理、控制总线、全局锁、决策竞选、分布式会话和集群状态管理等操作提供了一种简单的开发方式。

Spring Boot的优点:自动化配置、快速开发、轻松部署、Spring Cloud入门请看:https://blog.csdn.net/spark_guo/article/details/79013009

总结

分布式框架的优点:

大幅提高并发访问量(10000 )可以节省成本(因为这种优化仅是从架构方面进行优化，而不需要去配置大量的服务器)实现了服务层与表现层的解耦合

注:

其实还有一种方式，即是提升带宽，把带宽搞多一点，但前提是服务器能承受这么大的量。集群也不是越多越好的，越多的话就会发现，其实并发的提升是有限的。

目前还有一种比分布式更火的架构模式，叫做微架构，它是通过服务的原子化拆分，以及微服务的独立打包、部署和升级，可以让小团队的交付周期将缩短，运维成本也将大幅度下降，可以预见，这种架构模式将会越来越受到广大企业的应用与喜爱。

分布式应用程序就是指应用程序分布在不同计算机上，通过网络来共同完成一项任务，通常为服务器/客户端模式。更广义上理解“分布”，不只是应用程序，还包括数据库等，分布在不同计算机，完成同一个任务。

优点是可以快速访问、多用户使用。

每台计算机可以访问系统内其他计算机的信息文件；系统设计上具有更大的灵活性，既可为独立的计算机的地区用户的特殊需求服务，也可为联网的企业需求服务，实现系统内不同计算机之间的通信；每台计算机都可以拥有和保持所需要的最大数据和文件；减少了数据传输的成本和风险。

为分散地区和中心办公室双方提供更迅速的信息通信和处理方式，为每个分散的数据库提供作用域，数据存储于许多存储单元中，但任何用户都可以进行全局访问，使故障的不利影响最小化，以较低的成本来满足企业的特定要求。

现在的架构很多，各种各样的，如高并发架构、异地多活架构、容器化架构、微服务架构、高可用架构、弹性化架构等，还有和这些架构相关的管理型的技术方法，如 DevOps、应用监控、自动化运维、SOA 服务治理、去 IOE 等等，还有很多。

那什么是分布式系统？分布式系统是支持分布式处理的软件系统，是由通信网络互联的多处理机体系结构上执行任务的系统。包括分布式操作系统、分布式程序设计语言及其编译系统、分布式文件系统分布式数据库系统等，当然这些也是分布式的关键技术。

使用分布式系统主要有：

1.增大系统容量。我们的业务量越来越大，而要能应对越来越大的业务量，一台机器的性能已经无法满足了，我们需要多台机器才能应对大规模的应用场景。所以，我们需要垂直或是水平拆分业务系统，让其变成一个分布式的架构。

2.加强系统可用。我们的业务越来越关键，需要提高整个系统架构的可用性，这就意味着架构中不能存在单点故障。这样，整个系统不会因为一台机器出故障而导致整体不可用。所以，需要通过分布式架构来冗余系统以消除单点故障，从而提高系统的可用性。

3.因为模块化，所以系统模块重用度更高

4.因为软件服务模块被拆分，开发和发布速度可以并行而变得更快

5.系统扩展性更高

6.团队协作流程也会得到改善

分布式系统的类型有三种：

1.分布式处理，但只有一个总数据库，没有局部数据库

2.分层式处理，每一层都有自己的数据库

3.充分分散的分布式网络，没有中央控制部分，各节点之间的联系方式又可以有多种，如松散的联接，紧密的联接，动态的联接，广播通知式的联接等

然后来对比一下单体应用和分布式架构的优缺点：

1.从上面的表格可以看到，分布式系统虽然有一些优势，但也存在一些问题

2.架构设计变得复杂（尤其是其中的分布式事务）

3.部署单个服务会比较快，但是如果一次部署需要多个服务，部署会变得复杂

4.系统的吞吐量会变大，但是响应时间会变长

5.运维复杂度会因为服务变多而变得很复杂

6.架构复杂导致学习曲线变大

7.测试和查错的复杂度增大

8.技术可以很多样，这会带来维护和运维的复杂度

9.管理分布式系统中的服务和调度变得困难和复杂

所以总结一下，分布式系统架构的难点在于系统设计，以及管理和运维。所以分布式系统架构在解决了一些问题的同时，也增加了其他的问题，这就需要不断的再用各种各样的技术跟手段去解决这些新增的问题。后续会跟上分布式系统架构的搭建以及使用。

分布式系统是支持分布式处理的软件系统，是由通信网络互联的多处理机体系结构上执行任务的系统。包括分布式操作系统、分布式程序设计语言及其编译系统、分布式文件系统分布式数据库系统等，当然这些也是分布式的关键技术。

分布式系统更准确地说是一种系统构架概念，不是一种技术，简单来说，就是 把操作系统分布放在不同的电脑里，这些电脑共同来管理。

提高安全性和效率。

分布式说明我们做的应用程序需要部署到多台服务器上来满足用户的请求。其实你从我这句话中也不难得出、如果你做的应用并发请求不是很大那么一台服务器就可以满足、如果你做的应用比较大、比如淘宝或者京东、在应对多个用户同时访问的时候、一台服务器就容易出现宕机，所以分布式的优势在于应对多用户同时访问（简称高并发）来达到程序的高可用

分布式系统架构简单的说是运行在多个处理器上的软件构架设计。

分布式系统是建立在网络之上的软件系统。正是因为软件的特性，所以分布式系统具有高度的内聚性和透明性。

网络和分布式系统之间的区别更多的在于高层软件（特别是操作系统），而不是硬件。内聚性是指每一个数据库分布节点高度自治，有本地的数据库管理系统。

架构，又名软件架构，是有关软件整体结构与组件的抽象描述，用于指导大型软件系统各个方面的设计。架构描述语言（ADL）用于描述软件的体系架构。