单体架构的痛点：
比如传统MVC架构，所有业务子模块都集成在一个很重的JVM进程当中。这种单体架构的好处是便于管理，所有代码都在同一个项目当中。但是当产品规模越来越大，其坏处也很明显。
缺点一：项目过于臃肿
当大大小小的功能模块都集中在同一项目的时候，整个项目必然会变得臃肿，让开发者难以维护。
缺点二：资源无法隔离
整个单体系统的各个功能模块都依赖于同样的数据库、内存等资源，一旦某个功能模块对资源使用不当，整个系统都会被拖垮。
缺点三：无法灵活扩展
当系统的访问量越来越大的时候，单体系统固然可以进行水平扩展，部署在多台机器上组成集群：
但是这种扩展并非灵活的扩展。比如我们现在的性能瓶颈是支付模块，希望只针对支付模块做水平扩展，这一点在单体系统是做不到的（因为单体系统中这四个模块是在一起的，不能单独拆分出来）。
什么是微服务？
微服务（Microservice Architecture）是近几年流行的一种架构思想，关于它的概念很难一言以蔽之。究竟什么是微服务呢？我们在此引用 ThoughtWorks 公司的首席科学家 Martin Fowler 的一段话：
微服务架构风格是一种将单个应用程序作为一套小型服务开发的方法，每种应用程序都在自己的进程中运行，并与轻量级机制（通常是HTTP资源API）进行通信。 这些服务是围绕业务功能构建的，可以通过全自动部署机制独立部署。 这些服务的集中管理最少，可以用不同的编程语言编写，并使用不同的数据存储技术。
1.独立部署，灵活扩展
传统的单体架构是以整个系统为单位进行部署，而微服务则是以每一个独立组件（例如用户服务，商品服务）为单位进行部署。
用一张经典的图来表现，就是下面这个样子：
图中左边是单体架构的集群，右边是微服务集群。
什么意思呢？比如根据每个服务的吞吐量不同，支付服务需要部署20台机器，用户服务需要部署30台机器，而商品服务只需要部署10台机器。这种灵活部署只有微服务架构才能实现。
而近几年流行的Docker，为微服务架构提供了有效的容器。
2.资源的有效隔离
微服务设计的原则之一，就是每一个微服务拥有独立的数据源，假如微服务A想要读写微服务B的数据库，只能调用微服务B对外暴露的接口来完成。这样有效避免了服务之间争用数据库和缓存资源所带来的问题。同时，由于每一个微服务实例在Docker容器上运行，实现了服务器资源（内存、CPU资源等）的有效隔离。
3.团队组织架构的调整
微服务设计的思想也改变了原有的企业研发团队组织架构。传统的研发组织架构是水平架构，前端有前端的团队，后端有后端的团队，DBA有DBA的团队，测试有测试的团队。
而微服务的设计思想对团队的划分有着一定的影响，使得团队组织架构的划分更倾向于垂直架构，比如用户业务是一个团队来负责，支付业务是一个团队来负责。
当然，这种垂直划分只是一个理想的架构，实际在企业中并不会把团队组织架构拆分得这么绝对。
微服务与面向服务架构SOA的区别
SOA架构是一种粗粒度、松耦合的服务架构，其更多的是强调异构系统之间的服务通信。
SOA是什么样子呢？可以是下面这样的Web Service：
也可以是下面这样的ESB企业服务总线：
总之，SOA架构强调的是异构系统之间的通信和解耦合，而微服务架构强调的是系统按业务边界做细粒度的拆分和部署。
无论是Dubbo还是Spring Cloud都是框架和组件，SOA和微服务是架构思想，它们不是同一个层面的概念。我们可以说Dubbo和
Spring Cloud很好地支持了SOA和微服务架构，但是不能说Dubbo是SOA，Spring Cloud是微服务。
微服务架构的不足
1、微服务把原有的项目拆分成多个独立的工程，增加了开发和测试的复杂度。如某个项目拆分的过细，导致添加一个小功能就需要修改四五个工程，这显然是糟糕的设计。
2、微服务架构需要保证不同服务之间的数据一致性，引入了分布式事务和异步补偿机制，为设计和开发带了一定挑战。
所以说架构设计没有绝对的好坏，关键还要看应用场景。