分布式与集群的区别是什么？
- 知乎用户
从三种结构上来讲
作者：大闲人柴毛毛
链接：https://www.zhihu.com/question/20004877/answer/282033178
来源：知乎
著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。
三种结构：
- 单机结构
- 集群结构
-
分布式结构
- 单机结构： 单机结构我想大家最最最熟悉的就是单机结构，一个系统业务量很小的时候所有的代码都放在一个项目中就好了，然后这个项目部署在一台服务器上就好了。整个项目所有的服务都由这台服务器提供。这就是单机结构。
那么，单机结构有啥缺点呢？我想缺点是显而易见的，单机的处理能力毕竟是有限的，当你的业务增长到一定程度的时候，单机的硬件资源将无法满足你的业务需求。此时便出现了集群模式，往下接着看。
- 集群结构：
单机处理到达瓶颈的时候，你就把单机复制几份，这样就构成了一个“集群”。集群中每台服务器就叫做这个集群的一个“节点”，所有节点构成了一个集群。每个节点都提供相同的服务，那么这样系统的处理能力就相当于提升了好几倍（有几个节点就相当于提升了这么多倍）。
但问题是用户的请求究竟由哪个节点来处理呢？最好能够让此时此刻负载较小的节点来处理，这样使得每个节点的压力都比较平均。要实现这个功能，就需要在所有节点之前增加一个“调度者”的角色，用户的所有请求都先交给它，然后它根据当前所有节点的负载情况，决定将这个请求交给哪个节点处理。这个“调度者”有个牛逼了名字——负载均衡服务器(Load balancing server)。
集群结构的好处就是系统扩展非常容易。如果随着你们系统业务的发展，当前的系统又支撑不住了，那么给这个集群再增加节点就行了。但是，当你的业务发展到一定程度的时候，你会发现一个问题——无论怎么增加节点，貌似整个集群性能的提升效果并不明显了。这时候，你就需要使用微服务结构了。
- 分布式结构：
分布式结构就是将一个完整的系统，按照业务功能，拆分成一个个独立的子系统，在分布式结构中，每个子系统就被称为“服务”。这些子系统能够独立运行在web容器中，它们之间通过RPC方式通信。
举个例子，假设需要开发一个在线商城。按照微服务的思想，我们需要按照功能模块拆分成多个独立的服务，如：用户服务、产品服务、订单服务、后台管理服务、数据分析服务等等。这一个个服务都是一个个独立的项目，可以独立运行。如果服务之间有依赖关系，那么通过RPC方式调用。
这样的好处有很多：
-
系统之间的耦合度大大降低，可以独立开发、独立部署、独立测试，系统与系统之间的边界非常明确，排错也变得相当容易，开发效率大大提升。
-
系统之间的耦合度降低，从而系统更易于扩展。我们可以针对性地扩展某些服务。假设这个商城要搞一次大促，下单量可能会大大提升，因此我们可以针对性地提升订单系统、产品系统的节点数量，而对于后台管理系统、数据分析系统而言，节点数量维持原有水平即可。
-
服务的复用性更高。比如，当我们将用户系统作为单独的服务后，该公司所有的产品都可以使用该系统作为用户系统，无需重复开发。
从饭店到Q&A
作者：张鹏飞
链接：https://www.zhihu.com/question/20004877/answer/112124929
来源：知乎
著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。
小饭店原来只有一个厨师，切菜洗菜备料炒菜全干。后来客人多了，厨房一个厨师忙不过来，又请了个厨师，两个厨师都能炒一样的菜，这两个厨师的关系是集群。为了让厨师专心炒菜，把菜做到极致，又请了个配菜师负责切菜，备菜，备料，厨师和配菜师的关系是分布式，一个配菜师也忙不过来了，又请了个配菜师，两个配菜师关系是集群
Q: 所以可以理解为，一起干同样的事叫集群，分工合作的叫分布式?
A: 是的
Q: 想请教，分布式的几个角色之间是否一定要有前后关系，比如是不是备菜备料的没完成后面的任务就无法开始进行。还是说只是一件事分成多个部分，前后没有依存关系，但是各自无法替代其他人的职务？
A: 谢谢提醒，我的例子确实强调了先后顺序，但是分布式讲的是协作，一个事件发生可以触发多个事件同时进行不同的业务运算，集群中的成员功能是一样的，，分布式中的成员功能不一样。至于依赖要看具体业务，比如银行转账，短信通知模块就不是必须的通知失败也不影响转账
Q: 对于这种注重前后关系的情况，分布式的意义体现在哪里，感觉和不分开没多大变化。
A: 1.稳定业务和多变业务分离：比如转账业务不会变，但转账完成后续动作多变，可能发短信，可能发邮件，还有别的奖励，也可能有个短期活动需要处理，如果每次变化都直接加到转账业务里，那就要频繁改动主业务，甚至需要重启，更甚至直接给主业物代码引入了新的bug 2.新业务老业务分离：一块成熟的业务，拓展出来一块新业务，新的业务只需要从老业务里面获取小部分数据或功能，剩下大部分都是很独立的逻辑，老业务模块根本不需要了解新业务模块，如果都堆积到老业务模块里面，笨重又混乱 3.团队隔离：核心业务系统由核心团队管理和维护，非核心业务系统由另外一个独立团队维护，互相暴露少量接口互通，互有边界控制 4.不同硬件需求：有的业务需要大内存，有的需要大硬盘，有的需要更强cpu，有的需要更多集群，根据不同需求分布到更适合的物理设备上，而不是统一配置爱用不用 5.还有更多理由需要分布式，即便是有先后顺序，也会把业务拆分成多个独立子系统，更多知识请百度“分布式”“微服务”“组件化”“模块化” 6.如果你的业务本来就很简单，拆分反而成了负担，也有拆分不合理后面重构合并到一起的 7.“分布式架构”在一体化系统里面相对应的概念是“接口分离原则”，对应的问题就应该是“一个方法就能解决问题，为什么要分开好几个方法或接口” 以上不知道是不是你要的答案
