SpringCloud基本概念

概述

SpringCloud 本身并不是一个新的框架，只是将现有比较成熟、流行的框架整合在一起，其目的就是提高开发效率。SpringBoot 是使用比较方便的框架，有人说SpringCloud是基于SpringBoot的，其实就是SpringCloud 将SpringBoot 整合到了自己生态圈中。近几年，微服务的流程除了业务需要外，也跟SpringCloud的强大有关。

架构模式

1、单体架构：
一个项目包含了所有的应用程序，这种是最传统的架构风格。
2、SOA 架构：
面向服务的架构，SpringBoot 系列中集成Dubbo 就是典型的SOA架构，controller 和 service 层为独立的两个工程。
3、微服务架构：
简单理解为一个完整的系统由很多单体系统组成。可以围绕项目的业务来划分，每一种业务划分为一个服务，拥有自己的controller、service、dao，独立开发，独立运行。这样的一组微服务共同构建整个系统。

SpringCloud组件

1、Eureka
服务注册中心： 在整个系统中，当微服务的数量越来越多，服务之间的调用越来越复杂，A需要调用B，B 中又依赖着C… 这时集中管理就非常重要了。Eureka 就是完成服务治理的，包含了Eureka Server 和 Eureka Client 两个组件，Eureka Server 为服务端，提供服务注册功能，Eureka Client 为客户端，用户与服务端的交互。当然也可以使用 zookeeper、consul。
Eurake的服务端
@EnableEurekaServer
Eurake的客户端
@EnableEutrkaClient

2、Feign、Ribbon
服务调用组件： 尽管我们的服务按照业务来划分，也避免不了服务之间的交互，例如：用户服务需要调用订单服务查询订单信息。每个服务都是一个独立运行的个体，那么两个服务之间是怎么调用的？Feign、Ribbon 就是用来做服务之间的调用的。RestTemplate也可以。
接口接收端组件，Feign底层依赖Ribbon+Template实现的调用，看不到实际的调用方法，利用接口和注解。负载均衡调用服务的客户端组件，声明式(注解)客户端，使得调用更简单(无需关心底层调用的api getForEntity、getForObject…)，底层基于ribbon+restTemplate(内部整合了Hystrix)

3、Hystrix
熔断器： 一个复杂的业务是需要多个服务层间的调用的，假设有A、B、C、D四个服务，调用关系A_>B>C~>D，此时D服务出错，会随着时间的推移，C、B、A 出错，甚至整个系统都挂掉，这种现象就成为雪崩效应。Hystrix(豪猪)，熔断器，它的出现就是解决多服务层间调用级联故障问题，此处D出错将会熔断C和D将的调用，返回结果由自己开发定制。

4、Getway、Zuul
网关： 每个微服务都是一个独立运行的个体，也就意味着服务地址(ip:port)是不同的，这样对于API的使用者将会非常复杂，所以这时就需要一个中间人，前端发送请求到中间人，由中间人分发请求到对应的微服务上，这样前端就只需要一个 ip:port 即可。这里的中间人即网关，Spring Cloud Zuul 是 Netflix 开源的网关，Spring Cloud Getway 是spring官方开发的网关。

5、SpringCloudConfig
集中配置组件： 由于每个服务都是一个独立个体，所以都有自己的配置文件，当服务众多，配置文件的管理就非常重要，SpringCloudConfig，分布式配置中心组件，分为Config server 和 config client。server 为独立的工程，用于集中管理各个应用程序的配置，默认用git 存储，也可存储到SVN、本地。client 客户端，在每个微服务中配置，微服务启动的时候会请求 server 拿到自己的配置文件启动。

6、SpringCloudBus
消息总线： 每个微服务都启动完成，假设这时修改了某个服务的配置文件，这时可以使用SpringCloudBus 来实现配置的自动更新，不用重启服务。