微服务是什么？
微服务架构风格是一种将单个应用程序作为一套小型服务开发的方法，每种应用程序都在自己的进程中运行，并与轻量级机制（通常是HTTP资源API）进行通信。 这些服务是围绕业务功能构建的，可以通过全自动部署机制独立部署。 这些服务的集中管理最少，可以用不同的编程语言编写，并使用不同的数据存储技术 项目案例 www.1b23.com 。
单体架构是我们通常使用的mvc架构，所有的业务子系统都在这一个应用程序中。
这种模式的优点是便于管理，所有的代码都在一个项目中。
同样缺点也很明显：
1、项目过于臃肿当大大小小的功能模块都集中在同一项目的时候，整个项目必然会变得臃肿，让开发者难以维护。
2、资源无法隔离，整个单体系统的各个功能模块都依赖于同样的数据库、内存等资源，一旦某个功能模块对资源使用不当，整个系统都会被拖垮。
3、无法灵活扩展当系统的访问量越来越大的时候，单体系统固然可以进行水平扩展，部署在多台机器上组成集群，但是这种扩展并非灵活的扩展。比如我们现在的性能瓶颈是支付模块，希望只针对支付模块做水平扩展，这一点在单体系统是做不到的。
微服务能解决什么问题？
微服务解决了单体架构模式下的难维护，技术架构不能按需重构，不能技术创新等问题。
微服务有什么特点？
1、独立部署，灵活扩展传统的单体架构是以整个系统为单位进行部署，而微服务则是以每一个独立组件（例如用户服务，商品服务）为单位进行部署。
2、资源的有效隔离微服务设计的原则之一，就是每一个微服务拥有独立的数据源，假如微服务A想要读写微服务B的数据库，只能调用微服务B对外暴露的接口来完成。这样有效避免了服务之间争用数据库和缓存资源所带来的问题。
3、团队组织架构的调整微服务设计的思想也改变了原有的企业研发团队组织架构。传统的研发组织架构是水平架构，前端有前端的团队，后端有后端的团队，DBA有DBA的团队，测试有测试的团队。而微服务的设计思想对团队的划分有着一定的影响，使得团队组织架构的划分更倾向于垂直架构，比如用户业务是一个团队来负责，支付业务是一个团队来负责。
4、每个微服务之间使用的技术实现方式可以不同，按具体业务逻辑而定，可减少成本。
5、部署时，可实现模块服务按不同的需求选择服务器机器，如cpu密集型服务，就选择好一点的cpu就可以了；如io密集型，就选择ssd盘服务器就好了。