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