一、传统单体架构的缺陷

传统的单体应用，将所有功能的表示层、业务逻辑层，数据访问层，包括静态资源等等全部糅合在一个工程里面，编译，打包，部署在单台服务器上上线，比如打成war包放在Tomcat的webapp目录中部署项目。这样的项目开发部署适合小型项目，系统功能不复杂，访问量不大的情况下有绝对的优势。开发速度快，运维方便。但是当业务越来越复杂，功能越来越多，参与的开发人员越来越多，就暴露出问题了：

• 业务变复杂，代码量增大，代码可读性，可维护性，可扩展性下降。万一要新同事接手代码，理解起来花很多时间
• 测试难度增大
• 单体应用并发能力有限，访问量高了用户体验差
• 单体应用容错率低，万一哪里出错，可能导致整个项目就崩了

将单体应用做集群部署，添加负载均衡服务器（例如Nginx反向代理转发请求）可稍微缓解以上3，4条缺点，但是还是不能完美解决问题。

---

二、何为微服务

微服务架构：就是将原来的单体应用按义务范围来进行划分，划分为多个小model，每个微服务运行在自己的进程中，不相互影响，通过完全自动化部署来独立部署。并使用轻量级机制通信，通常是HTTP RESTUFUL API。可对各个微服务进行集中管理。这些小model可以使用不同的编程语言，以及不同的存储技术。微服务架构是分布式架构。

微服务架构的优点：

• 按业务划分的微服务单元独立部署，运行在独立的进程中，服务与服务之间没有任何耦合，有很好的扩展性和复用性
• 服务与服务之间通常采用HTTP通信，这种通信机制与平台和语言无关(可以使用不同的编程语言和存储方法)。也可以采用轻量级的消息总线来通信，如RabbitMQ、Kafaka消息队列等等，数据格式一般都采用JSON
• 每个微服务有自己的数据库，服务之间数据库是独立的
• 微服务一般采用自动化部署工具部署。Docker容器技术是微服务最佳部署的容器。
• 服务集中化管理(服务注册与发现Eureka、Zookeeper、Consul)，监控(服务运行状况监控Spring-Boot-Admin-Server)
• 微服务架构是分布式架构

微服务架构的缺点：

• 项目构建复杂程度远高于单体应用
• 分布式系统中难保证数据一致性，一般情况下，少用分布式事物
• 服务部署比单体应用复杂

微服务架构难题及解决办法：

• 服务之间故障传播影响：譬如A服务调用了B服务，但是B服务因为网络或其他原因迟迟没有响应，容易引起服务的雪崩效应 — >采用“熔断机制”，快速报错
• 分布式事物：事物失败容易导致数据不一致 — >采用“两阶段提交”

---

三、SpringCloud简介

Spring Cloud是最常用的微服务框架，依赖于Spring Boot，有快速开发，持续交付，容易部署等优点。
主要功能组件有：

• 服务的注册与发现，注册中心统一管理微服务实例，查看各个服务的健康状态
• 服务负载均衡，为了保证服务高可用，要集群化部署
• 服务容错–熔断机制
• 网关–路由，过滤，
• 各个服务配置文件的统一管理
• 服务之间相互调用的流程链路追踪
• 实时日志.