大家一听分布式架构，一般第一反应都是，高端霸气上档次。其实，分布式架构在我们平时的开发很常见，也并非那么复杂，今天我们用大白话来讲讲什么是分布式架构。
背景
首先我们要知道，分模块并不是分布式的概念，早在上世纪90年代，就有人提出了按照模块划分软件功能，之间相互依赖，但是他们仍然部署在相同的机器上。随着软件的发展尤其是互联网的发展，传统的单体架构越来越不行了，主要表现为3方面的问题：
1.性能问题，单体架构很难提升性能，很容易因为某一模块的性能瓶颈而照成整个大应用的性能下降。
2.难以扩展，难以扩展，原来的各个模块依赖非常密切，就写一些精度的机器里面，有成千上万个齿轮，每一个模块的变动都会带动其他齿轮的转动。
3.系统可用性低，想想，因为模块之间的紧密联系，就像齿轮一样，所以一旦一个齿轮发生损坏，就会造成整个系统崩溃。
优缺点
相对于传统的单体结构，分布式的最重要的有点有下面几点:
1.容易开发跟实现新功能，与传统的单体结构相比，开发或者变更一个新功能，我们只要跟外部系统约定好接口与协议，内部实现不会对其他功能造成影响。
2.单点故障影响范围更小，分布式不会像传统单体架构一样，一个模块的故障造成全部不可用。当然，分布式也会有故障问题，这就需要优秀的架构师设置合理合适的框架，规避单点故障带来的大面积故障。
3.系统吞吐量大，对于有性能瓶颈的模块，我们可以采用异步或者部署更多的机器，解决单机性能瓶颈的问题又提高了机器的利用率。
分布式虽然解决了很多难题，难也是有不少缺点的，所以需要各位程序员，各位架构师进行攻克与架构。
主要难点
1.异构系统不标准，这个主要体现在通讯协议不标准、数据结构不标准、部署环境不标准等等等，每个系统都可能有自己的数据结构跟通讯协议，可能有人喜欢用Http，有人是自己的Socket,而且协议体、错误代码、错误信息等数据结构都可能不一致，这不仅给开发带来不便，还给统一监控跟治理带来不少麻烦。
2.故障概率更大，因为机器数量变多，维护开发的人变多，单机故障的概率反而会大于单机结构。这是必然的现象，一个没有处理过故障的工程师不是一个好码农。这就需要我们设计合理的分布式架构，降低故障的概率跟影响面，同时也要自动化运维，毕竟人总是会犯错的，而且经常犯。
3.服务依赖问题，不要以为一台机器挂了整个程序就挂了只有在单体架构才会发生，在分布式的环境中，也会存在一些关键服务，一旦挂掉，往往会行程多米诺效应，造成雪崩。
怎么做
为了解决分布式带来的问题，就需要各个程序员跟架构师大展身手了，无论是什么办法，无外乎为了下面两个事情：1是提高系统吞吐，2是提高系统的可用性。由此派生出来非常多的分布式技术跟框架，欢迎大家关注我，后面我会针对分布式的相关技术进行分享，一同学习进步！
閱讀更多 沙茶敏碎碎念 的文章
