对于每一个程序员来说，大家一听分布式架构，一般第一反应都是，高端霸气上档次。例如阿里巴巴的各个系统都部署在不同的机器上，并且还分布在杭州、上海、深圳等不同的服务器上。华为的服务器也会分布在世界不同的区域，从而保证满足全球用户的使用。
我们常常在各种招聘广告上面看到，熟悉分布式系统的开发，那么，分布式究竟是怎么一回事，这么讲，小孩子都能听懂。
背景
有人认为，分布式就是分模块进行开发，分模块进行部署，分布式的核心就是分模块。但分模块并不是分布式的概念，早在上世纪90年代，就有人提出了按照模块划分软件功能。这在软件工程上，分模块可以更好地进行解耦，在工作中，分模块也可以更好地进行分工。虽然分模块进行开发，但是他们仍然部署在相同的机器上。随着软件的发展尤其是互联网的发展，传统的单体架构越来越不行了，主要表现为以下三个方面：
- 性能问题，在早起的互联网行业中，硬件的发展非常迅速，几乎每一代新的电脑芯片，都能比上一代性能翻一番，但是，随着摩尔定律的失效，硬件的提升已经更不上软件行业的发展，我们常常说因特尔挤牙膏，因为现在芯片的性能要翻一番需要好几代产品了。所以，单体的架构的性能问题就爆发出来，无法跟上时代的脚步。
- 难以扩展，原来各个模块上只是逻辑上的隔离，但仍然部署在同一台机器。各个模块之间，用着永洋的物理内存，同样的硬盘，同样的网卡，实际上各个模块依赖非常密切，就像一台精密的机器，有成千上万个齿轮，每一个模块的变动都会带动其他齿轮的转动。
- 系统可用性低，不难想象，所有的模块都不熟在同一个机器上，如果有一个模块出问题，例如突然占满整个磁盘、或者内存泄漏，都会影响系统上的其他模块，从而造成整个系统的崩溃。
特点
相对于传统的单体结构，分布式的最重要的有点有下面几点:
- 更容易开发跟实现新功能，在传统的单体结构中，模块之间的依赖是非常严重的，你要实现一个功能，还需要评估对其他模块的影响。而在分布式的设计中，模块与模块之间，是通过接口来进行交互，一个模块的内部实现对另外的模块来说是透明的，影响更小。
- 单点故障的影响氛围更小，传统的单体架构的存在的一个严重问题，就是一个模块的故障容易引起整个系统不可用。举个简单的例子，在电商系统中，评价系统可能不是那么重要，结果有一天评价系统故障内存泄漏，造成机器不断重启，就非常可能影响部署在同一台机器上的其他应用。分布式部署则可以大大地降低故障的概率，当然，分布式也会有故障问题，这就需要优秀的分布式架构师设置合理合适的框架，合理地进行部署，来规避单点故障带来的大面积故障。
- 系统吞吐量更大，以往的单点部署模块，受限于单台机器的性能。在分布式架构中，对于有性能瓶颈的模块，我们可以采用异步或者部署更多的机器，解决单机性能瓶颈的问题又提高了机器的利用率。举个简单的例子，数据库模块，对磁盘的性能及容量要求更高，我们可以部署在磁盘更好的机器，对于缓存这种对CPU、内存容量要求更高的机器，从而达到机器更高的利用率。
分布式虽然解决了很多难题，但也是有不少缺点与难点的，所以需要各位程序员，各位架构师进行攻克与架构。
主要难点
- 异构系统标准不统一，在分布式系统中，每个模块都可以选择自己的开发语言，部署环境，每个系统都可以选择自身的数据结构与通信协议。可能有人喜欢用HTTP协议进行通信，有人是是google公司的gRPC,有人是Twitter公司的thrift。而且协议体、错误代码、错误信息等数据结构都可能不一致，这不仅给开发带来不便，还给统一监控跟治理带来不少麻烦。
- 故障概率更大，因为机器数量变多，单机的性能与质量可能就没之前的那么好了，同时维护开发的人变多，单机故障的概率反而会大于单机结构。这是必然的现象，一个没有处理过故障的工程师不是一个好码农。这就需要我们设计合理的分布式架构，降低故障的概率跟影响面，同时也要自动化运维，毕竟人总是会犯错的，而且经常犯。
- 服务依赖问题，不要以为一台机器挂了整个程序就挂了只有在单体架构才会发生，在分布式的环境中，也会存在一些关键服务，一旦挂掉，往往会行程多米诺效应，造成雪崩。例如聊天软件中维护用户登录态的Session服务，如果一旦故障，那么所有的服务都可能丢失登录态，从而造成整个服务不可用。
怎么做
为了解决分布式带来的问题，就需要各个程序员跟架构师大展身手了，无论是什么办法，无外乎为了下面两个事情：
- 是提高系统吞吐，
- 是提高系统的可用性。
