本文以即时通讯软件（IM）为例，介绍单机、集群、分布式的区别，以及它们各自的优缺点。
假设现在开发一款IM，刚开始业务比较简单，用户量也较少，我们将服务部署在一台单机服务器上足矣。软件开发过程中为了让程序更加清晰，便于维护，采用模块化编程。一款IM服务大致包括：用户管理、好友管理、群组管理、消息管理、后台管理。
之后随着用户数量的增长，渐渐发现，单机性能有限，支持的用户并发量较小。并且，我们的代码只是采用模块化方式编写，一个模块出现问题，往往需要将整个项目重新编译，部署，耗时耗力。再之，系统中有些模块属于CPU密集型，有些模块属于I/O密集型，各模块对硬件资源的需求不一样，所以在进行服务器选型时只能综合各模块，可能会导致资源的浪费或过剩。
所以，针对单机性能瓶颈的问题，提出了集群的概念，每一台服务器独立运行一个工程的所有模块，事实上集群就是再多加几台服务器提供服务，比如：
服务器数量的增加自然解决了单机性能瓶颈的问题，但项目部署在多台机器上，代码修改后仍然需要花费大量的精力重新部署项目。并且对于不常用的后台管理模块没必要每台机器上都部署。因此，水平扩充机器的集群方式，仍然存在一些问题。
下面再来看看分布式模式，一个工程拆分了很多模块，每一个模块独立部署运行在一个服务器主机上，所有服务器协同工作共同提供服务，每一台服务器称作分布式的一个节点，根据节点的并发要求，对一个节点可以再做节点模块集群部署。
将模块部署到不同的主机，这样修改单独的模块，不影响其他主机模块的运行，并且对于单机性能瓶颈的问题，也可以通过增加节点集群的方式提高性能。
但要实现分布式的模式，对我们的要求就更高，比如，系统要划分模块，怎么划分合理？CPU密集型和I/O密集型模块部署在不同性能的机器上？模块之间会不会存在大量重复的代码？模块之间的调用如何进行等等。模块运行在不同的主机上，模块之间的调用自然就会涉及到网络通信，因此，我们必须实现一个分布式网络通信框架来做支撑。
可见，随着业务增长，程序框架也必须随之改变，而一个好的框架设计往往能在开发、维护方面节约大量成本。
