一、单体应用架构概念
一个归档包（可以是JAR、WAR、EAR或其它归档格式）包含所有功能的应用程序，通常称为单体应用。
而架构单体应用的方法论，就是单体应用架构。
二、单体架构示意图
三、单体应用架构的优缺点
1. 优点
- 便于共享：单个归档文件包含所有功能，便于在团队之间以及不同的部署阶段之间共享。
- 易于测试：单体应用一旦部署，所有的服务或特性就都可以使用了，这简化了测试过程，因为没有额外的依赖，每项测试都可以在部署完成后立刻开始。
- 易于部署：只需将单个归档文件复制到单个目录下。
2. 缺点
- 复杂性高：由于是单个归档文件，所以整个项目文件包含的模块非常多，导致模块的边界模糊、依赖关系不清晰、代码的质量参差不齐，混乱的堆在一起，使得整个项目非常复杂。以致每次修改代码，都非常小心，可能添加一个简单的功能，或者修改一个Bug都会带来隐藏的缺陷。
- 技术债务：随着时间的推移、需求的变更和技术人员的更替，会逐渐形成应用程序的技术债务，并且越积越多。
- 扩展能力受限：单体应用只能作为一个整体进行扩展，无法根据业务模块的需要进行伸缩。
- 阻碍技术创新：对于单体应用来说，技术是在开发之前经过慎重评估后选定的，每个团队成员都必须使用相同的开发语言、持久化存储及消息系统。
- 因单体应用部署在一台服务器上，很容易出现系统负载过重，内存泄漏等问题，而且出现该种问题由于1)的原因，并不好修改。
四、微服务架构概念
微服务架构风格是一种将一个单一应用程序开发为一组小型服务的方法，每个服务运行在自己的进程中，服务间通信采用轻量级通信机制。这些服务围绕业务能力构建并且可通过全自动部署机制独立部 署。这些服务共用一个最小型的集中式的管理，服务可用不同的语言开发，使用不同的数据存储技术。
五、微服务架构示意图
六、微服务架构的优缺点
1. 优点
- 易于开发和维护：一个微服务只会关注一个特定的业务功能，所以业务清晰、代码量较少。开发和维护单个微服务相对简单。
- 单个微服务启动较快。
- 局部修改容易部署：单体应用只要有修改，就得重新部署整个应用。微服务解决了这样的问题。一般来说，对某个微服务进行修改，只需要重新部署这个服务即可。
- 技术栈不受限制：在微服务架构中，可以结合项目业务及团队的特点，合理的选择技术栈。
- 按需伸缩：可根据需求，实现细粒度的扩展。
2. 缺点
- 运维要求高：更多的服务意味着要投入更多的运维。
- 分布式固有的复杂性：使用微服务构建的是分布式系统。对于一个分布式系统，系统容错、网络延迟、分布式事务等都会带来巨大的问题。
- 接口调整成本高：微服务之间通过接口进行通信。如果修改某一个微服务的API，可能所有用到这个接口的微服务都需要进行调整。
看到CSDN上这位兄弟写的不错，略微加了点实践中自己的感受。
转载地址:https://blog.csdn.net/qinaye/article/details/82840625