单体架构和微服务架构的区别

单体架构的优点：
1.部署简单：由于是完整的结构体，可以直接部署在一个服务器上即可
2.技术单一：项目不需要复杂的技术栈，往往一套熟悉的技术栈就可以完成开发
3.用人成本低：单个程序员可以完成业务接口到数据库的整个流程

便于共享：单个归档文件包含所有功能，便于在团队之间以及不同的部署阶段之间共享。
易于测试：单体应用一旦部署，所有的服务或特性就都可以使用了，这简化了测试过程，因为没有额外的依赖，每项测试都可以在部署完成后立刻开始。
易于部署：只需将单个归档文件复制到单个目录下。

单体架构的缺点：
1.系统启动慢，一个进程包含了所有的业务逻辑，涉及到的启动模块过多，导致系统的启动，重启周期边长；
2.系统错误隔离性差，可用性差，任何一个模块的错误可能导致整个系统的宕机；
3.可伸缩性差，系统的扩容只能对整个应用扩容，不能做到对整个功能点进行扩容；
4.线上问题修复时间长，任何一个线上问题修复需要对整个应用系统进行全面升级；

复杂性高：由于是单个归档文件，所以整个项目文件包含的模块非常多，导致模块的边界模糊、依赖关系不清晰、代码的质量参差不齐，混乱的堆在一起，使得整个项目非常复杂。以致每次修改代码，都非常小心，可能添加一个简单的功能，或者修改一个Bug都会带来隐藏的缺陷。
技术债务：随着时间的推移、需求的变更和技术人员的更替，会逐渐形成应用程序的技术债务，并且越积越多。
扩展能力受限：单体应用只能作为一个整体进行扩展，无法根据业务模块的需要进行伸缩。
阻碍技术创新：对于单体应用来说，技术是在开发之前经过慎重评估后选定的，每个团队成员都必须使用相同的开发语言、持久化存储及消息系统。

微服务架构概念
微服务架构风格是一种将一个单一应用程序开发为一组小型服务的方法，每个服务运行在自己的进程中，服务间通信采用轻量级通信机制。这些服务围绕业务能力构建并且可通过全自动部署机制独立部署。这些服务共用一个最小型的集中式的管理，服务可用不同的语言开发，使用不同的数据存储技术。

微服务的优点：
1.易于开发和维护：一个服务只关注一个特定的业务功能，所以它业务清晰，代码量少。开发和维护单个微服务相当简单。而整个应用是若干个微服务构建而成的，所以整个应用在被维持在一个可控的状态；
2.单个服务启动快：单个服务代码量少，所以启动快；
3.局部修改易部署：单个应用只要有修改，就得重新部署整个应用，微服务解决了这个问题。一般来说，对某个微服务进行修改，只需要重新部署这个服务即可；
4.技术栈不受限：在微服务架构中，可以结合业务和团队的特点,合理选用技术栈。例如有些服务可以使用关系型数据库Mysql，有的服务可以使用非关系型数据库redis。甚至可根据需求，部分服务使用JAVA开发，部分微服务使用Node.js开发
5.按需收缩：可根据需求，实现细粒度的扩展。例如，系统中的某个微服务遇到了瓶颈，可以结合微服务的特点，增加内存，升级CPU或增加节点。

易于开发和维护：一个微服务只会关注一个特定的业务功能，所以业务清晰、代码量较少。开发和维护单个微服务相对简单。
单个微服务启动较快
局部修改容易部署：单体应用只要有修改，就得重新部署整个应用。微服务解决了这样的问题。一般来说，对某个微服务进行修改，只需要重新部署这个服务即可。
技术栈不受限制：在微服务架构中，可以结合项目业务及团队的特点，合理的选择技术栈。
按需伸缩：可根据需求，实现细粒度的扩展。
 

微服务的缺点：
运维要求高：更多的服务意味着更多的运维投入。在单体架构中，只需要保证一个应用的运行即可，在微服务中，需要保证几十甚至几百个服务器正常运行和协作，这给运维带来了巨大的挑战；
分户式固有的复杂性：使用微服务架构的是分布式系统。对于一个分布式系统，系统容错，网络延迟都会带来巨大挑战。
接口调整成本高：微服务之间通过接口进行通信

运维要求高：更多的服务意味着要投入更多的运维。
分布式固有的复杂性：使用微服务构建的是分布式系统。对于一个分布式系统，系统容错、网络延迟、分布式事务等都会带来巨大的问题。
接口调整成本高：微服务之间通过接口进行通信。如果修改某一个微服务的API，可能所有用到这个接口的微服务都需要进行调整。
————————————————