分布式：一个业务分拆多个子业务，部署在不同的服务器上
集群：同一个业务，部署在多个服务器上
单机结构
我想大家最最最熟悉的就是单机结构，一个系统业务量很小的时候所有的代码都放在一个项目中就好了，然后这个项目部署在一台服务器上就好了。整个项目所有的服务都由这台服务器提供。这就是单机结构。
那么，单机结构有啥缺点呢？我想缺点是显而易见的，单机的处理能力毕竟是有限的，当你的业务增长到一定程度的时候，单机的硬件资源将无法满足你的业务需求。此时便出现了集群模式，往下接着看。
集群结构
集群模式在程序猿界有各种装逼解释，有的让你根本无法理解，其实就是一个很简单的玩意儿，且听我一一道来。
单机处理到达瓶颈的时候，你就把单机复制几份，这样就构成了一个“集群”。集群中每台服务器就叫做这个集群的一个“节点”，所有节点构成了一个集群。每个节点都提供相同的服务，那么这样系统的处理能力就相当于提升了好几倍（有几个节点就相当于提升了这么多倍）。
但问题是用户的请求究竟由哪个节点来处理呢？最好能够让此时此刻负载较小的节点来处理，这样使得每个节点的压力都比较平均。要实现这个功能，就需要在所有节点之前增加一个“调度者”的角色，用户的所有请求都先交给它，然后它根据当前所有节点的负载情况，决定将这个请求交给哪个节点处理。这个“调度者”有个牛逼了名字——负载均衡服务器。
集群结构的好处就是系统扩展非常容易。如果随着你们系统业务的发展，当前的系统又支撑不住了，那么给这个集群再增加节点就行了。但是，当你的业务发展到一定程度的时候，你会发现一个问题——无论怎么增加节点，貌似整个集群性能的提升效果并不明显了。这时候，你就需要使用微服务结构了。
分布式结构
先来对前面的知识点做个总结。
从单机结构到集群结构，你的代码基本无需要作任何修改，你要做的仅仅是多部署几台服务器，每台服务器上运行相同的代码就行了。但是，当你要从集群结构演进到微服务结构的时候，之前的那套代码就需要发生较大的改动了。所以对于新系统我们建议，系统设计之初就采用微服务架构，这样后期运维的成本更低。但如果一套老系统需要升级成微服务结构的话，那就得对代码大动干戈了。所以，对于老系统而言，究竟是继续保持集群模式，还是升级成微服务架构，这需要你们的架构师深思熟虑、权衡投入产出比。
OK，下面开始介绍所谓的分布式结构。
分布式结构就是将一个完整的系统，按照业务功能，拆分成一个个独立的子系统，在分布式结构中，每个子系统就被称为“服务”。这些子系统能够独立运行在web容器中，它们之间通过RPC方式通信。
举个例子，假设需要开发一个在线商城。按照微服务的思想，我们需要按照功能模块拆分成多个独立的服务，如：用户服务、产品服务、订单服务、后台管理服务、数据分析服务等等。这一个个服务都是一个个独立的项目，可以独立运行。如果服务之间有依赖关系，那么通过RPC方式调用。
这样的好处有很多：
- 系统之间的耦合度大大降低，可以独立开发、独立部署、独立测试，系统与系统之间的边界非常明确，排错也变得相当容易，开发效率大大提升。
- 系统之间的耦合度降低，从而系统更易于扩展。我们可以针对性地扩展某些服务。假设这个商城要搞一次大促，下单量可能会大大提升，因此我们可以针对性地提升订单系统、产品系统的节点数量，而对于后台管理系统、数据分析系统而言，节点数量维持原有水平即可。
- 服务的复用性更高。比如，当我们将用户系统作为单独的服务后，该公司所有的产品都可以使用该系统作为用户系统，无需重复开发。
例子：
有一天，隔壁小王睡前突然有一个大胆的插法，哦不~ 大胆的想法，他要做一个在线B2C的美女网站，突然发现接下来要发了，可以赢取白富美了，不过他又想到了一个问题：
“想法都有了，就差一个程序员了”！
翻了一会通讯录后发现了楼下的小明就是个程序员啊！于是也不管几点就直接从床上跳起来，穿着拖鞋跑到楼下猛敲小明的房门。
小明这时候正在写代码，被连续的敲门声吓得写了一个bug后就去开门了。
“什么事啊？”
“呀，我是你楼上的小王啊，你还没睡啊？有事找你有事找你”
小王不管不顾的走进去，小明一阵错愕！
“小明”，小王放低了声音，“我有一个项目，绝对能发，现在就差开发了，听说你的技术很牛逼！”
“什么项目？”，小明被小王的神秘语气和一种不知哪来的自信引起了兴趣！
“一个B2C的美女网站，用户可以购买美女的时间，比如买11月15号的下午14：00-16：00，然后下订单，美女可以在这两个钟陪用户读书学习 🙂 ……” 小王绘声绘色，小明却一脸无奈。。
小王知道小明的意思，就继续吹：“到时一定赚钱的，你就是我的合伙人啊，你拿30%”。
小明不为所动…
这时候小王冒出了些许冷汗，转念一想，做出了猥琐的表情说道：“我可是楼上小王哦！”
…
总之，在小王的威逼利诱下，小明勉强答应了！
小明跟小王聊了5个晚上的需求，有时候聊着聊着就一起睡着了，慢慢理清了思路，就开始干了。
他像以前的开发那样，建立一个web工程，不断往web里边添加功能，比如订单功能，用户管理功能，商品信息管理功能等都丢到web工程里边。
在小王的催促和监督下，经过两个多月，小明终于搞完第一个初始版本！
小明和小王都测试了一遍发现没什么问题，就打算弄个服务器，然后把web项目和数据库都扔到一个tomcat里去。
上线了！！！
小王很开心，看到了自己的想法实现了，并且已经在网上可以找到！
过了好几天，网站的用户量是2，也就是只有他们2个。小王开始急了 – –
小王发现推广很重要，于是去跟他爸爸拿了几百万投放广告，他爸爸刚开始不肯，说不懂互联网，于是小王把网站发给他爸看，他爸就同意了。
小王有钱之后，就去找广告商了，于是慢慢的电视上的综艺节目有了他的美女网站的广告了！
理所当然的用户量开始越来越高了，小明发现，服务器崩了！！
并发量太大，小明觉得一个tomcat已经不行了，于是小明就告诉小王，咱们用户量越来越多了，一个服务器不行，买多两台服务器吧，小王听到用户量增加，开心的答应了。
小明把项目在每个服务器里边都放了一份，然后用nginx代理转发。
就这样可以顶了一段时间…
最近小王在后台上架了一个非常漂亮的美女，导致太多用户访问，服务器又崩了…
小明对小王说：“我们得加强一下服务器配置了，把带宽，内存和cpu都升级吧！”
于是，又顶了一段时间…
过不久又崩了！
小王开始不爽了，对小明说：“怎么搞的？怎么服务器老是不行？？”
小明说：“我他妈怎么知道你是个富二代？一开始以为你是闹着玩的，谁知道用户量会增多？”
小王发现小明有点生气了，他想着不能得罪程序员，于是轻声说：“那怎么办？”
“我得重构了！每个tomcat都放着整个web工程，后台访问也就我们两个，没有并发的问题，浪费资源了。模块之间耦合度太高了，其中一个功能升级其他的也都得升级，系统扩展性也差，不能够灵活的去部署”,小明如是说！
小王有点似懂非懂的问：“那怎么重构呢？”
“用分布式！我们把整个项目工程拆分成多个子项目，每个子项目负责自己的功能，例如订单这个功能就是一个单独的系统项目，会员系统也是一个单独的系统。” 小明边说边在纸上画了一张图：
小王依然似懂非懂的问：“这样比之前有多好？”
“这样的话，我们把每个模块都拆分出来，可以灵活的部署了，比如美女商品信息这个模块被访问的量比较大，那么我们就可以单独对这个模块进行服务性能的提升，不用全部都一起提升。也降低了代码的耦合度，模块之间互不影响，这样如果以后有人加入开发，他只要负责他的模块去开发就可以了，合作也高效！” 小明说道。
“那有什么缺点没？”
“有吧，就是各个模块之间需要通信，这时候需要开发接口，增加了些工作量！不过这是值得，总比花钱去买更多服务器配置好吧！”
“恩，有道理有道理！”
于是小明就这样开始重构了他的项目，慢慢的项目的稳定性比之前的好多了。
过了6个月，项目开始盈利了，于是小王开始招兵买马，把小明踢出去。
（哈哈，没有啦，开玩笑的，最后他们在一起了！）
