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