什么是微服务

    传统的单体架构所有业务模块都集成在一个JVM进程中，所有代码都在同一个项目中。好处是便于管理，但是随着项目越来越大缺点也很明显：

缺点一：项目过于臃肿。当大大小小的功能模块都集中在同一项目的时候，整个项目必然会变得臃肿，让开发者难以维护。

缺点二：资源无法隔离 。整个单体系统的各个功能模块都依赖于同样的数据库、内存等资源，一旦某个功能模块对资源使用不当，整个系统都会被拖垮。

缺点三：无法灵活扩展。当系统的访问量越来越大的时候，单体系统固然可以进行水平扩展，部署在多台机器上组成集群，但是这种扩展并非灵活的扩展。比如我们现在的性能瓶颈是支付模块，希望只针对支付模块做水平扩展，这一点在单体系统是做不到的。

这时我们需要把单体系统拆分为微服务。微服务架构风格是一种将单个应用程序作为一套小型服务开发的方法，每种应用程序都在自己的进程中运行，并与轻量级机制（通常是HTTP资源API）进行通信。 这些服务是围绕业务功能构建的，可以通过全自动部署机制独立部署。 这些服务的集中管理最少，可以用不同的编程语言编写，并使用不同的数据存储技术。

微服务特点：

1.独立部署，灵活扩展。传统的单体架构是以整个系统为单位进行部署，而微服务则是以每一个独立组件（例如用户服务，商品服务）为单位进行部署。用一张经典的图来表现，就是下面这个样子：

2.资源的有效隔离。微服务设计的原则之一，就是每一个微服务拥有独立的数据源，假如微服务A想要读写微服务B的数据库，只能调用微服务B对外暴露的接口来完成。这样有效避免了服务之间争用数据库和缓存资源所带来的问题。

                                        

3.团队组织架构的调整微服务设计的思想也改变了原有的企业研发团队组织架构。传统的研发组织架构是水平架构，前端有前端的团队，后端有后端的团队，DBA有DBA的团队，测试有测试的团队。而微服务的设计思想对团队的划分有着一定的影响，使得团队组织架构的划分更倾向于垂直架构，比如用户业务是一个团队来负责，支付业务是一个团队来负责。

缺点：微服务把原有项目拆分为独立工程，增加了开发和测试的复杂度。微服务需要保证不同服务间的数据一致性，引入了分布式事物和异步补偿机制，为设计和开发带来一定挑战。