单机
单机架构很好理解，例如你要部署一套CRM项目，这个项目包含的服务有：用于应用操作的Web站点、用于存储文件的FTP服务、Oracle数据库服务都部署在一台服务器上。总而言围绕这个项目的所有服务都部署在一台服务器上就是单机架构方式。
结构参考图：
集群
单机架构的硬件资源有限对于业务量比较大的情况是很难适用的，所以便可以在此基础之上实施集群架构方式。例如，部署在IIS上的Web应用随着业务量的增加，应用的处理能力下降，此时可以准备多台新的服务器设备并将Web应用分别部署在新的服务器上，这样的模式就构成了一个“集群”。集群形成那么在集群中的每台服务器就相当于集群中的一个“节点”，每个节点都必须保证提供的是相同的服务。
构建集群后引发的问题，用户通过客户端操作发送请求到服务器，那么会使用集群中哪台服务器处理请求呢？并且选择的依据是什么？那么基于集群的这种问题，诞生了一个“调度者”负载均衡服务器。顾名思义通过负载均衡服务器的调度处理会在集群中选择一个负载较小的服务器来处理用户的请求。
集群的架构的优势在于我们无需改动任何的项目代码，只需要新增服务器部署相同的应用并配置好负载均衡，就可以很好的减轻随着业务增量带来的系统压力，并且可以直接在单机架构上直接进行调整。
结构参考图：
此图在单机架构上针对Web应用服务器实施了集群并通过负载均衡来调度处理请求，并将围绕项目的其他的服务独立到单独服务器上，相比单机架构而言很大程度减少了服务器的压力。
分布式
个人认为集群架构出发点是以增加硬件设备进行扩展，而分布式是以应用系统的业务功能作为出发点，并将每个业务功能拆分成一个完全独立子系统，专业名称称为“服务”。多个子系统通过一个主体容器将它们承载，各个子系统直接使用RPC方式进行通信。
举个例子，假设需要开发一个在线商城。按照微服务的思想，我们需要按照功能模块拆分成多个独立的服务，如：用户服务、产品服务、订单服务、后台管理服务、数据分析服务等等。这一个个服务都是一个个独立的项目，可以独立运行。如果服务之间有依赖关系，那么通过RPC方式调用。
结构参考图：
在前面讲到单机架构到集群并且集群进行扩展都是非常方便的，代码基本无需要作任何修改，你要做的仅仅是多部署几台服务器，每台服务器上运行相同的代码并且配置好负载均衡就行了。但是集群结构演进到微服务结构的时候，之前的那套代码就需要发生较大的改动了。所以对于新系统我们建议，系统设计之初就采用微服务架构，这样后期运维的成本更低。但如果一套老系统需要升级成微服务结构的话，那就得对代码大动干戈了。所以，对于老系统而言，究竟是继续保持集群模式，还是升级成微服务架构，这需要你们的架构师深思熟虑、权衡投入产出比。
个人认为分布式会是主流的架构方式，另外分布式架构最常见最热门的应用场景就是微服务架构。通过分布式架构可以将项目中每个核心功能单元化从而降低耦合程度，项目每个核心功能可以交由专业的供应商进行开发、或者由公司不同的团队开发，总而言专业人做专业事，每个单位可以独立进行、部署、测试，在进度和分工上有很大的优势和效率。并且分布式架构有很好的复用性、移植性，例如开发一个订单服务或者权限服务，可以给其他项目进行使用，无需重复造轮子。
生活场景类比
通过单机、集群、分布式的架构概念我们可以通过生活中的情景进行类比，来更好的理解概念，描述如下：
白手起家时的你在阿里巴巴附近开了一间川菜馆，因为刚刚起步且客流量并不是很大，所以你在厨房你只聘请了一位工作人员，该工作人不不仅炒菜还要负责配菜、切菜等厨房的各种工作，这个时候的场景其实就相当于我们服务器架构中的单机架构。
在开店的第三个月后你的生意开始好了起来，这个时候你打算请多名厨工工作，但是厨工的工作都还是综合的还要负责配菜、切菜等厨房的各种工作，只是人手增加了，这个时候的场景其实就相当于我们服务器架构中的集群架构。
在开店一年后有了很好的口碑和回头客，你打算将业务扩展承接一些酒席。那么此时不光工作量增加工作的类型也多元化，为了使餐馆有条不紊的运作，你将厨房的工作进行职责分工开放不同的岗位，此时就有了专门炒菜的厨师、专门切菜的案头、专门清洁人员，这个时候的场景其实就相当于我们服务器架构中的分布式架构，所有员工各自出力负责各自的工作围绕着相同的生意。