单体架构：一个归档包（可以是JAR、WAR、EAR或其它归档格式）包含所有功能的应用程序，通常称为单体应用。即所有功能都在一个应用里。
优点：
开始简单，前期开发成本低，周期短，小型项目的首选；
进程间延迟低，开发效率高，模块之间交互采用本地方法调用；
一个代码库，一个部署对象，运维成本小；
当规模小时，资源利用率高。
缺点：
协调成本随团队规模增加；
模块划分不清晰；
全部功能集中在一个应用中，不容易扩展；
部署要么全面成功，要么彻底失败（停机，故障）；
构建时间长，修改一个地方就要将整个应用编译、部署、启动；
微服务架构: 微服务架构是一种将一个单一应用程序开发为一组小型服务的方法，每个服务运行在自己的进程中，服务间通信采用轻量级通信机制。这些服务围绕业务能力构建并且可通过全自动部署机制独立部署。这些服务共用一个最小型的集中式的管理，服务可用不同的语言开发，使用不同的数据存储技术。
微服务架构强调的一个重点是“业务需要彻底的组件化和服务化”，原有的单个业务系统会拆分为多个可以独立开发、设计、运行的小应用。这些小应用之间通过服务完成交互和集成。
优点：
每个服务单元都是简单的，一个微服务只会关注一个特定的业务功能，所以业务清晰、代码量较少，易于开发和维护；
可扩展性和性能都是独立的；
独立的测试和部署，对某个微服务进行修改后，只需要重新部署这个服务即可；
更容易做性能的调优。
缺点：
交互单元很多，使用微服务构建的是分布式系统。对于一个分布式系统，系统容错、网络延迟、分布式事务等都会带来巨大的问题；
接口调整成本高，微服务之间通过接口进行通信。如果修改某一个微服务的API，可能所有用到这个接口的微服务都需要进行调整；
需要更复杂的工具和依赖项管理。
总结：
对于紧耦合的单体架构来说，每当试图提交代码到主干或将代码部署到生产环境时，都可能导致整个系统的故障，部署工作也困难重重，即便是进行小规模的部署变更，也可能需要数天或数周的大量协调和沟通工作。集成和测试工作也会变得更复杂。
而对于微服务架构来说，服务拆分后，各个服务可以独立并行开发、测试、部署，交付效率大大提升。产品的更新速度会变快，用户体验更好。代码量越大，为服务的优势越明显。
