共计 1105 个字符，预计需要花费 3 分钟才能阅读完成。
前言
注：单体架构到分布式架构更多的是从我的项目的零碎架构层面进行的探讨，故不要将单体架构与业务分层（如 mapper、dao、controller……）相混同
本文将以一个简略的商城我的项目为导引，解说单体架构与分布式架构
我的项目蕴含了订单模块、用户模块、领取模块和商品模块等
单体架构
什么是单体架构？
简略来说就是 把业务的所有性能集中在一个我的项目中去开发，打成一个包部署
在开发单体架构我的项目时，只须要创立一个我的项目，而后依据相应性能一直在我的项目各业务层中沉积代码就 OK 了，不须要思考简单的架构设计。在大多数初学者初学 web 后端时所做的 demo 大多数都是单体架构
单体架构的长处是 架构简略、部署成本低（把我的项目打成包部署到 tomcat 上，用户就能够拜访了，当用户减少后，能够通过加机器造成负载平衡的集群），
劣势
随着程序的一直迭代，程序复杂度会越来越高，业务模块越来越多，在开发的过程中，这些个代码你中有我，我中有你，它们之间的边界也越来越含糊，未来你改了一个中央的代码，可能会导致其余几个模块代码都跟着受到影响，所以 单体架构并不利于大型项目开发，此时分布式架构应运而生
分布式架构
所谓分布式架构，会依据业务性能对系统做拆分，每个业务模块作为 独立我的项目 去开发，称为 服务
比方说这个商城，它里边有四个业务模块，那我就会依照业务拆分，拆成四个独立的我的项目，而后来用户拜访时，依据须要拜访相应模块。
分布式架构我的项目因为须要思考简单的架构设计、对服务（模块）的大量拆分，会较大减少保护老本，故多用于企业级大型项目的开发
微服务
微服务实质上就是一种分布式架构计划，只不过是人们在设计分布式过程中踩坑，各种总结经验，失去了一种最佳实际
特色
- 繁多职责 ： 服务拆分力度要小 ，服务要干本人该干的事件，不能像打工人一样大包大揽，以 防止反复开发
- 面向服务 ：不同的服务间要实现互相通信获取数据等，故 服务要对外裸露业务接口
- 自治 ，自治其实就是独立，咱们的各个服务要做到、技术独立、数据独立和部署独立，这样能力尽可能的对数据、程序进行解耦。值得注意的是： 服务独立须要做到隔离性 ，以防止其余服务宕机导致的 级联问题
最终的目标就是为了实现高内聚耦合，升高服务之间的影响，或者说升高服务它所能产生影响的范畴，防止整个集群的故障
总结
单体架构：适宜于简略、小型我的项目
- 长处：架构简略，部署不便
- 毛病：耦合度高
分布式架构：适宜大型企业级我的项目
- 长处：升高耦合
- 毛病：相较于单体我的项目，架构简单
- 最佳实际：微服务 – 繁多职责、面向服务、独立自治
参考资料
https://www.bilibili.com/video/BV1LQ4y127n4?p=4
（本文首发于 自己掘金）
