Spring Cloud作为一套微服务治理的框架，几乎考虑到了微服务治理的方方页面。
1 传统架构发展史
1.1 单体架构
应用场景：小微企业；
典型架构：一个应用、一个数据库、一个web容器；
选择原因：快速上线，快速跟进市场，简单灵活；传统企业垂直度较高，访问压力小，技术要求较低；
架构图：
2.1 垂直架构
业务拆分：后台系统、前端系统、交易系统；
架构图：
3.1 服务化架构
面向服务（SOA）：将应用程序根据不同的职责划分为不同的模块，不同的模块直接通过特定的协议和接口进行交互；
服务特点：服务内部高内聚，服务之间低耦合；
架构图：
2 SOA和微服务架构
2.1 SOA和微服务的区别
1、微服务业务系统需要彻底组件化和服务化，一个组件就是一个产品，可以独立对外提供服务；
2、微服务不再强调传统SOA架构里面比较重的ESB企业服务总线；
3、独立的运行空间；
4、采用HTTP Rest API；
5、切分粒度更小；
2.2 Spring Cloud
1、来源Spring，质量、稳定性、持续性都可以得到保证；
2、天然支持Spring Boot，更加便于业务落地；
3、发展非常快；
4、Java领域最合适做微服务的框架；
5、周边环境的支持力度最大；
6、使用门槛低；
2.3 Spring Cloud核心特性
1、分布式、版本化配置；
2、服务注册和发现；
3、路由；
4、服务和服务之间的调用；
5、负载均衡；
6、断路器；
7、分布式消息传递；
3 微服务构架
服务治理，将服务之间的直接依赖转化为服务对服务中心的依赖；Spring Cloud核心组件Eureka用于解决这类问题。
3.1 Eureka
Eureka提供服务注册和发现，Eureka是一个服务中心，将所有的服务注册到它这里来管理，其它各调用者需要的时候去注册中心获取，然后再进行调用，避免了服务之间的直接调用，方便后续的水平扩展、故障转移。
特点：
1、注册中心；
2、高可用性；
3、负载均衡；
4、故障转移；
3.2 Hystrix
用于解决多个服务层调用，基础服务的故障可能会导致级联故障，进而造成整个系统不可用的情况，即服务雪崩效应。
Hystrix会在某个服务连续调用N次不响应的情况下，立即通知调用端调用失败，避免调用端持续等待而影响了整体服务。Hystrix间隔时间会再次检查此服务，如果服务恢复将继续提供服务。
Hystrix-dashboard：对Hystrix进行实时监控；
Hystrix Turbine：汇总系统内多个服务的数据并显示；
3.3 配置中心
Spring Cloud Config 是一个解决分布式系统的配置管理方案。
Server：提供配置文件的存储、以接口的形式将配置文件的内容提供出去；
Client：通过接口获取数据、并依据此数据初始化自己的应用。
注意：运行期间改变配置文件，服务不会得到最新的配置信息，需要在服务的运行期间重新加载配置文件。
3.4 Spring Cloud Bus
解决N多的服务需要更新配置的问题。
3.5 服务网关
通过引入 API Gateway 作为轻量级网关，简化前端的调用逻辑，同时API Gateway中也会实现相关的认识认证逻辑从而简化内部服务之间相互调用的复杂度。
Zuul：提供动态路由、监控、弹性、安全等边缘服务。它的具体作用是服务转发，接收并转发所有内外部的客户端调用。使用Zuul可以作为资源的统一访问入口，同时也可以在网关做一些权限检验等类似的功能。
3.6 链路路口跟踪
监控服务和服务之间通讯的各项指标，这些数据将是我们改进系统架构的主要依据。
Spring Cloud Sleuth：为服务之间调用提供链路追踪。通过Sleuth可以很清楚的了解到一个服务请求经过了哪些服务，每个服务处理花费了多长时间。从而让我们可以很方便的理清各微服务间的调用关系。
Zipkin：各个服务上的监控数据，并提供查询接口。
4 Spring Cloud构架
4.1 微服务架构
1、Eureka负责服务的注册与发现；
2、Hystrix 负责监控服务之间的调用情况，连续多次失败进行熔断保护；
3、Hystrix dashboard,Turbine 负责监控 Hystrix的熔断情况，并给予图形化的展示；
4、Spring Cloud Config 提供了统一的配置中心服务；
5、当配置文件发生变化的时候，Spring Cloud Bus 负责通知各服务去获取最新的配置信息；
6、所有对外的请求和服务，我们都通过Zuul来进行转发，起到API网关的作用；
7、监控我们使用Sleuth+Zipkin+springAdmin将所有的请求数据记录下来，方便我们进行后续分析
