单机、集群和分布式（微服务结构）的区别

 

 

 一、单机结构

　　单机就是所有的业务全部写在一个项目中，部署服务到一台服务器上，所有的请求业务都由这台服务器处理。显然，当业务增长到一定程度的时候，服务器的硬件会无法满足业务需求。自然而然地想到一个程序不行就部署多个喽，就是集群。

二、集群结构

　　单机处理到达瓶颈的时候，你就把单机复制几份，这样就构成了一个“集群”。集群中每台服务器就叫做这个集群的一个“节点”，所有节点构成了一个集群。每个节点都提供相同的服务，那么这样系统的处理能力就相当于提升了好几倍（有几个节点就相当于提升了几倍）。

　　但问题是用户的请求究竟由哪个节点来处理呢？最好能够让此时此刻负载较小的节点来处理，这样使得每个节点的压力都比较平均。要实现这个功能，就需要在所有节点之前增加一个“调度者”的角色，用户的所有请求都先交给它，然后它根据当前所有节点的负载情况，决定将这个请求交给哪个节点处理。这个“调度者”有个牛逼了名字——负载均衡服务器。

　　负载均衡：协调集群里的每个节点均衡地接受业务请求。通俗的讲就是服务A和服务B相同时间段内处理的同类业务请求数量是相似的。

 

 

 　　集群的特点：

　　 扩展性好：集群只是单机的多个复制，没有改变单机的原有的代码结构，每次部署新节点只需要复制部署即可。

        单个节点业务耦合度高、资源浪费：节点是多个业务处理集合（耦合高），每个具体业务的访问量可能差异很大，比如JD上账户管理模块的访问量肯定低于订单模块， 然而账户管理模块和订单模块的部署数量是一样的（因为每个节点里都有这两个模块），相对订单模块来说，部署同样多的账户管理模块就是浪费。

　　那就把单机节点不同的业务处理模块拆开喽，这就是分布式了。

三、分布式（微服务）结构

　　先来对前面的知识点做个总结。

　　从单机结构到集群结构，你的代码基本无需作任何修改，你要做的仅仅是多部署几台服务器，每台服务器上运行相同的代码就行了。但是，当你要从集群结构演进到微服务结构的时候，之前的那套代码就需要发生较大的改动了。所以对于新系统我们建议，系统设计之初就采用微服务架构，这样后期运维的成本更低。但如果一套老系统需要升级成微服务结构的话，那就得对代码大动干戈了。所以，对于老系统而言，究竟是继续保持集群模式，还是升级成微服务架构，这需要你们的架构师深思熟虑、权衡投入产出比。

　　分布式结构就是将一个完整的系统，按照业务功能，拆分成一个个独立的子系统，在分布式结构中，每个子系统就被称为“服务”。

　　这些子系统能够独立运行在web容器中，它们之间通过RPC方式通信。

　　举个例子，假设需要开发一个在线商城。按照微服务的思想，我们需要按照功能模块拆分成多个独立的服务，如：用户服务、产品服务、订单服务、后台管理服务、数据分析服务等等。

　　这一个个服务都是一个个独立的项目，可以独立运行。

　　如果服务之间有依赖关系，那么通过RPC方式调用。

 

 优点：

1. 系统之间的耦合度大大降低，可以独立开发、独立部署、独立测试，系统与系统之间的边界非常明确，排错也变得相当容易，开发效率大大提升。
2. 系统之间的耦合度降低，从而系统更易于扩展。我们可以针对性地扩展某些服务，就是对子系统集群。例如双十一时，订单子系统、支付子系统需要集群，账户管理子系统不需要集群。
3. 服务的复用性更高。比如，当我们将用户系统作为单独的服务后，该公司所有的产品都可以使用该系统作为用户系统，无需重复开发。