单体应用
单体应用，将所有功能的表示层、业务逻辑层，数据访问层，包括静态资源等等全部糅合在一个工程里面，编译，打包，部署在单台服务器上上线，比如打成war包放在Tomcat的webapp目录中部署项目。
优点
- 适合于中小项目，尤其非互联网项目，如政府、公司网站、OA办公等
- 开发简单直接，集中式管理
- 功能都在本地，没有分布式的管理开销和调用开销
缺点
- 开发效率低：所有的开发在一个项目改代码，递交代码相互等待，代码冲突不断
- 代码维护难：代码功能耦合在一起，新人不知道何从下手
- 部署不灵活：构建时间长，任何小修改必须重新构建整个项目，这个过程往往很长
- 稳定性不高：一个bug，可以导致整个应用挂掉
- 扩展性不够：无法满足高并发情况下的业务需求
集群
相同的服务 部署在 多台服务器上，相当于多个人做同一件事
伸缩性（Scalability）
集群的性能不限制于单一的服务器，新的服务器可以动态的添加到集群，从而增强集群的性能。
高可用性（High availability）
集群当其中一个节点发生故障时，这台节点上面所运行的应用程序将在另一台节点被自动接管，消除单点故障对于增强数据可用性、可达性和可靠性是非常重要的。
负载均衡（Load balancing）
负载均衡把客户端请求按照策略分配到集群下的服务器，以提高数据吞吐量。
缺点
随着业务功能的增加，达到一定程度时，增加节点，提升集群性能也不会明显
分布式
建立在集群基础之上，将一个单体应用拆分多个子模块，每个子模块负责几个功能，部署在不同的服务器上
优点
系统之间的耦合度大大降低，可以独立开发、独立部署、独立测试，系统与系统之间的边界非常明确，排错也变得相当容易，开发效率大大提升。
系统更易于扩展。我们可以针对性地扩展某些服务。假设这个商城要搞一次大促，下单量可能会大大提升，因此我们可以针对性地提升订单系统、产品系统的节点数量，而对于后台管理系统、数据分析系统而言，节点数量维持原有水平即可。
服务的复用性更高。比如，当我们将用户系统作为单独的服务后，该公司所有的产品都可以使用该系统作为用户系统，无需重复开发。
微服务
微服务架构：将原来的单体应用按业务范围来进行划分，划分为多个子模块（拆分成多个子工程，即：微服务），每个子模块只负责一个功能，微服务的核心要素是服务划分的 微小
由于每个服务都比较 微小，多个微服务可以部署在同一台服务器上
微服务 vs 分布式
微服务它的粒度更小，服务之间耦合度更低，由于每个微服务都由独立的小团队负责，因此它敏捷性更高，分布式服务最后都会向微服务架构演化
优点：
- 每个微服务运行在自己的进程中，不相互影响。
- 通过完全自动化部署来独立部署。
- 使用轻量级机制通信，通常是HTTP RESTUFUL API。
- 这些model可以使用不同的编程语言，以及不同的存储技术。
- 微服务架构是分布式架构。
- 可对各个微服务进行集中管理。