在介绍微服务之前，我们先了解单体架构。
单体架构：应用服务被当作一个单体进行部署，例如：一个Java Web应用仅包含一个运行在Tomcat之类的Web容器上WAR文件。
上图就是传统的MVC单体架构，所有的业务子模块都集成在一个很笨重的JVM进程中。这种单体架构的好处是便于管理，所有的代码都在同一个项目中，但当规模越来越大的时候，弊端渐现：
1、项目过于臃肿：当大大小小的功能模块都集中到同一个项目时，整个项目必然会变的臃肿，维护困难；
2、资源无法隔离：各功能模块都依赖同样的数据库、内存等资源，一旦某个功能对某个资源使用不当，整个系统都会被拖垮；
3、无法灵活拓展：若访问量越来越大，单体系统固然可以进行水平拓展，部署到多台机器上组成集群，但这种拓展并非灵活拓展，因为这种拓展把整个系统都进行了水平拓展，显然这并不是我们所需要的灵活拓展。例如现在性能瓶颈是支付模块，只需要针对支付模块进行水平拓展。
为此，引入微服务架构思想
微服务架构：一种将单个应用程序作为一套小型服务开发的方法，每种应用程序都在自己的进程中进行，并与轻量级机制（通常是HTTP的API）进行通信。这些服务是围绕业务功能构建的，可以通过全自动部署机制独立部署。这类服务集中管理少，可以用不同的编程语言，也可以用不同的存储技术。
微服务架构特点：
1、独立部署，灵活拓展：传统单体架构以整个系统为单位进行部署，而微服务是以每一个独立组件（例如用户服务、商品服务）为单位进行部署。
左边是单体架构的集群，右边是微服务集群。例如根据每个服务的吞吐量不同，支付服务需部署20台机器，用户服务需30台，而商品服务只需10台。这种灵活部署只有微服务架构才能实现。近几年流行的Docker为微服务架构提供了有效容器。
2、资源有效隔离：微服务设计原则之一就是每个微服务拥有独立的数据源，若微服务A需要读写微服务B的数据库，只能通过调用B对外暴露的接口来完成，有效避免了服务之间因争用数据库、缓存资源等所带来的问题；此外由于每个微服务实例在Docker容器上运行，实现了服务器资源（内存、CPU等）的有效隔离。
3、团队组织架构调整：传统研发架构是水平架构，前端有前端团队，后端有后端团队，DBA有DAB团队。微服务架构改变了原组织架构，更倾向与垂直架构，比如用户业务是一个团队（包含前端、后端、DBA等）负责，支付业务是另一个团队负责。
当然，这种垂直划分只是一种理想架构，实际企业中并不会划分的这么绝对
微服务与面向服务架构SOA
两者架构思想好像差不多，但还是有区别的。SOA是一种粗粒度、松耦合的服务架构，更多强调的是异构系统之间的服务通信和解耦合。而微服务架构强调的是系统按照业务边界做细粒度的拆分和部署。
Dubbo框架很好的支持了SOA，而Spring Cloud组件很好的支持了微服务架构。
当然，微服务架构也有其不足之处：
1、把原有项目拆分成多个独立工程，增加开发和测试的复杂度；
2、需要保证不同服务之间数据一致性，引入分布式事务和异步补偿机制，给设计和开发人员带来一定的挑战。
所以，架构设计没有所谓的好与坏，只有适合、更适合或者不适合，关键还是要看应用场景。