前言
注：单体架构到分布式架构更多的是从项目的系统架构层面进行的讨论，故不要将单体架构与业务分层（如mapper、dao、controller……）相混淆
本文将以一个简单的商城项目为导引，讲解单体架构与分布式架构
项目包含了订单模块、用户模块、支付模块和商品模块等
单体架构
什么是单体架构？
简单来说就是把业务的所有功能集中在一个项目中去开发，打成一个包部署
在开发单体架构项目时，只需要创建一个项目，然后根据相应功能不断在项目各业务层中堆积代码就 OK 了，不需要考虑复杂的架构设计。在大多数初学者初学web后端时所做的demo大多数都是单体架构
单体架构的优点是架构简单、部署成本低（把项目打成包部署到tomcat上，用户就可以访问了，当用户增加后，可以通过加机器形成负载均衡的集群），
劣势
随着程序的不断迭代，程序复杂度会越来越高，业务模块越来越多，在开发的过程中，这些个代码你中有我，我中有你，它们之间的边界也越来越模糊，将来你改了一个地方的代码，可能会导致其他几个模块代码都跟着受到影响，所以单体架构并不利于大型项目开发，此时分布式架构应运而生
分布式架构
所谓分布式架构，会根据业务功能对系统做拆分，每个业务模块作为独立项目去开发，称为服务
比方说这个商城，它里边有四个业务模块，那我就会按照业务拆分，拆成四个独立的项目，然后来用户访问时，根据需要访问相应模块。
分布式架构项目由于需要考虑复杂的架构设计、对服务（模块）的大量拆分，会较大增加维护成本，故多用于企业级大型项目的开发
微服务
微服务本质上就是一种分布式架构方案，只不过是人们在设计分布式过程中踩坑，各种总结经验，得到了一种最佳实践
特征
- 单一职责：服务拆分力度要小，服务要干自己该干的事情，不能像打工人一样大包大揽，以避免重复开发
- 面向服务：不同的服务间要实现相互通信获取数据等，故服务要对外暴露业务接口
- 自治，自治其实就是独立，我们的各个服务要做到、技术独立、数据独立和部署独立，这样才能尽可能的对数据、程序进行解耦。值得注意的是：服务独立需要做到隔离性，以避免其他服务宕机导致的级联问题
最终的目的就是为了实现高内聚耦合，降低服务之间的影响，或者说降低服务它所能产生影响的范围，避免整个集群的故障
总结
- 单体架构：适合于简单、小型项目
- 优点：架构简单，部署方便
- 缺点：耦合度高
- 分布式架构：适合大型企业级项目
- 优点：降低耦合
- 缺点：相较于单体项目，架构复杂
- 最佳实践：微服务--单一职责、面向服务、独立自治
