传统单体架构的缺陷
传统的单体应用，将所有功能的表示层、业务逻辑层，数据访问层，包括静态资源等等全部糅合在一个工程里面，编译，打包，部署在单台服务器上上线，比如打成war包放在Tomcat的webapp目录中部署项目。这样的项目开发部署适合小型项目，系统功能不复杂，访问量不大的情况下有绝对的优势。开发速度快，运维方便。但是当业务越来越复杂，功能越来越多，参与的开发人员越来越多，就暴露出问题了：
业务变复杂，代码量增大，代码可读性，可维护性，可扩展性下降。万一要新同事接手代码，理解起来花很多时间
测试难度增大
单体应用并发能力有限，访问量高了用户体验差
单体应用容错率低，万一哪里出错，可能导致整个项目就崩了
将单体应用做集群部署，添加负载均衡服务器（例如Nginx反向代理转发请求）可稍微缓解以上3，4条缺点，但是还是不能完美解决问题。
何为微服务
微服务架构：就是将原来的单体应用按义务范围来进行划分，划分为多个小model，每个微服务运行在自己的进程中，不相互影响，通过完全自动化部署来独立部署。并使用轻量级机制通信，通常是HTTP RESTUFUL API。可对各个微服务进行集中管理。这些小model可以使用不同的编程语言，以及不同的存储技术。微服务架构是分布式架构。
微服务架构的优点
- 按业务划分的微服务单元独立部署，运行在独立的进程中，服务与服务之间没有任何耦合，有很好的扩展性和复用性
- 服务与服务之间通常采用HTTP通信，这种通信机制与平台和语言无关(可以使用不同的编程语言和存储方法)。也可以采用轻量级的消息总线来通信，如RabbitMQ、Kafaka消息队列等等，数据格式一般都采用JSON
- 每个微服务有自己的数据库，服务之间数据库是独立的
- 微服务一般采用自动化部署工具部署。Docker容器技术是微服务最佳部署的容器。
- 服务集中化管理(服务注册与发现Eureka、Zookeeper、Consul)，监控(服务运行状况监控Spring-Boot-Admin-Server)
- 微服务架构是分布式架构
