springCloud整体架构--基于http协议

1.基础应用：

Eureka注册中心    

集成Rest实现Ribbon负载均衡

Fegin 声明式服务调用

Hystrix 服务熔断及接口降级

Zuul网关整合Redis实现统一用户登录中心

Config 统一配置中心

Bus 消息总线

分布式链路跟踪器ZipKin 

2.Spring Cloud简介

Spring Cloud是一个相对比较新的微服务框架，2016才推出
1.0的release版本. 但是其更新特别快，几乎每1-2个月就有
一次更新，虽然Spring Cloud时间最短, 但是相比Dubbo等RPC
框架, Spring Cloud提供的全套的分布式系统解决方案。
Spring Cloud为开发者提供了在分布式系统（配置管理，服务
发现，熔断，路由，微代理，控制总线，一次性token，全局锁
，leader选举，分布式session，集群状态）中快速构建的工具
，使用Spring Cloud的开发者可以快速的启动服务或构建应用、
同时能够快速和云平台资源进行对接。

3.架构图

4.Eureka注册中心

Spring Cloud Eureka 是 Spring Cloud Netflix微服务套件中
的一个重要部分。他基于Netflix Eureka 做了二次封装，主要负
责完成微服务架构中的服务治理与服务发现功能。
我们只需要简单的遵循Spring的配置文件配置即可完成微服务的服
务治理和发现组件。
Eureka分为服务治理、服务发现。
1 首先我们需要在pom.xml中引入对应的依赖配置。
2 在主入口（application类 ）加入@EnableEurekaServer注解。
3 我们需要在配置文件里对服务中心进行对应的配置。
4 最后我们运行Helloworld示例程序 我们来体验一下Eureka服务发现。
我们可以查看Eureka的信息，访问地址：http://localhost:8001/

5.服务提供者

我们刚刚实现了服务发现注册中心，接下来我们需要把自己的应用服务注册
到Spring Cloud Eureka 注册中心上。
1 对pom.xml进行配置
2 在主入口（application类 ）加入@EnableDiscoveryClient注解
3 我们需要在配置文件里把目标服务中心进行对应的设置。
4 最后先运行Eureka服务，再运行Provider服务提供者。然后观察Eureka
的信息。

6.服务消费者

服务消费者也可以注册到注册中心中，也可以当作服务提供者
使用RestTemplate 调用接口

@Bean
    @LoadBalanced  // 如果加了这个注解 , 那么就说明 具有了服务发现的特性
 //负载均和的机制：意味着可以通过服务名请求数据
    public RestTemplate restTemplate(){
        return new RestTemplate();
    }

7.高可用注册中心

Spring Cloud 高可用Eureka 服务注册中心
在微服务架构环境中，一个非常关键部分就是高可用性，我们需要充分
考虑发生故障的情况，所以在生产环境中必须对各个组件进行高可用的
部署，对于微服务注册中心也应该是如此，如何实现高可用呢？非常简
单，只需要建立两个Eureka服务，把两个注册中心地址相互配置都进行
配置到对方地址即可，相互配置对方。

 这个时候我们看控制台里eureka有2个服务，此时我们的高可用注册中心已经搭建完成，以后即使宕机一个Eureka，另外一个也可以进行服务。

服务发现机制：

 8.服务发现机制说明：

服务注册：服务提供者在启动时会通过发送REST请求的方式将自己注册到Eureka
服务器上，同时带上了自身服务的一些元素信息。Eureka 收到这个Rest请求后，
将元数据信息存储在一个双层结构Map中，其中第一层的key是服务名，第二层的
key是具体服务实例名。
服务同步：如架构图中所示，这里两个服务提供者分别注册到了两个不同的注册
中心上，也就是说他们的信息分别被两个服务注册中心所维护，此时由于服务注
册中心之间因为相互注册服务的关系，当服务提供者发送注册请求到一个服务注
册中心的时候，它会将该请求转发给集群的其他注册中心，从而实现注册中心之
间的服务同步过程。通过服务同步，两个服务提供者的服务信息就可以通过这两
台服务注册中心的任意一台获取到。
服务续约：服务注册完成后，服务提供者会维护一个心跳来持续告诉注册中心
“我还活着”以防止注册中心“剔除该服务”也就是将服务列表中排除出去。
获取服务：当我们启动消费者的时候，它会发送一个Rest请求给注册中心获取
上面所有的服务清单，并且为了性能考虑，返回给客户端的清单缓存默认每隔
30s更新一次。
服务调用：消费者获得清单后，通过服务名可以获得具体提供服务的实例名和
改实例的元数据信息。因为有这些服务实例的详细信息，所以客户端可以根据
自己的需要决定调用那个服务示例，在ribbon中会默认采用轮训的方式进行服
务调用，从而实现负载均衡机制。
服务下线：在系统运行中必然会出现关闭或重启某个实例的情况，在关闭服务
期间，我们自然不希望调用到已经下线的服务实例，所以在客户端程序中，当
服务实例正常关闭操作时，它会触发一个服务下线的Rest请求给Eureka，通知
其下线，当然注册中心收到该请求后把其服务列表状态改为下线，并把该事件
传播给集群其他节点。当出现非正常下线（由于系统内部故障，如内存溢出、
服务器宕机等问题）时，注册中心可能并没有收到正常的下线通知请求，而这
种情况，我们的Eureka自己会有一个内部的定时任务，每隔一段时间定时检查
超时的清单进行剔除（如果没有续约）。

9.负载均衡

负载均衡对于一个系统架构来说非常重要，是必须要有的一个基础设施，
它能够有效的缓解网络压力和流量扩容。我们知道的负载均衡可能分为两
种，一种是硬件的负载均衡，比如F5服务器或者SLB负载设施；另外一种
是软件负载均衡设施，比如我们耳熟能详的Nginx反向代理负载均衡、Lvs
负载均衡、Haproxy负载均衡等等。但是只要是负载均衡服务都是能以类
似的架构方式来构建。

10.负载均衡实现：ribbon

Spring Cloud Ribbon是一个基于HTTP和TCP的客户端复杂均衡工具。他基于
Netflix Ribbon实现。通过Spring Cloud的封装，可以让我们轻松的将面向
服务的Rest模板请求自动转换成客户端负载均衡的服务调用。在服务架构中，
以后我们学习的API网关以及Feign代理都是通过Ribbon为基础进行调用服务
的。

对于Spring Cloud Ribbon 的负载均衡我们基于RestTemplate去使用，
只需要在配置BEAN中加入注解@LoadBalanced即可， Ribbon负载均衡器：



注意问题：我们的RestTemplate加上@LoadBalanced注解后会走这个类
（轮训策略类）RibbonLoadBalancerClient，serverid必须是我们访问
的服务名称 ，当我们直接输入ip的时候获取的server是null，就会抛出
异常

 Spring Cloud Ribbon Retry机制:

当我们使用Spring Cloud Ribbon实现客户端负载均衡的时候，通常都会利
用@LoadBalanced来让RestTemplate具备客户端负载功能，从而实现面向服
务名的接口访问。
大多数情况下，上面的实现没有任何问题，但是总有一些意外发生，比如：
有一个实例发生了故障而该情况还没有被服务治理机制及时的发现和摘除，
这时候客户端访问该节点的时候自然会失败。所以，为了构建更为健壮的应
用系统，我们希望当请求失败的时候能够有一定策略的重试机制，而不是直
接返回失败。这个时候就需要开发人员人工的来为上面的RestTemplate调用
实现重试机制。
不过，从Spring Cloud Camden SR2版本开始，我们就不用那么麻烦了。从
该版本开始，Spring Cloud整合了Spring Retry来实现重试逻辑，而对于开
发者只需要做一些配置即可。

简单配置ribbon与retry重试机制：

 

对于ConnectTimeout与ReadTimeout这两个配置，底层代码似乎有bug，代码
发现并没有对超时处理进行生效，所以我建议使用RestTemplate原始配置即可。
hystrix.command.default.execution.isolation.thread.timeoutInMilliseconds：
断路器的超时时间需要大于ribbon的超时时间，不然不会触发重试。（对于D版
本及以前有效）

11.断路器：Spring cloud hystrix 断路器的产生

在微服务架构中，我们将系统拆分成了一个个的服务单元，各单元应用间通过
服务注册与订阅的方式互相依赖。由于每个单元都在不同的进程中运行，依赖
通过远程调用的方式执行，这样就有可能因为网络原因或是依赖服务自身问题
出现调用故障或延迟，而这些问题会直接导致调用方的对外服务也出现延迟，
若此时调用方的请求不断增加，最后就会出现因等待出现故障的依赖方响应而
形成任务积压，线程资源无法释放，最终导致自身服务的瘫痪，进一步甚至出
现故障的蔓延最终导致整个系统的瘫痪。如果这样的架构存在如此严重的隐患，
那么相较传统架构就更加的不稳定。为了解决这样的问题，因此产生了断路器
等一系列的服务保护机制。

针对上述问题，在Spring Cloud Hystrix中实现了线程隔离、断路器等一系列的
服务保护功能。它也是基于Netflix的开源框架 Hystrix实现的，该框架目标在于
通过控制那些访问远程系统、服务和第三方库的节点，从而对延迟和故障提供更强
大的容错能力。Hystrix具备了服务降级、服务熔断、线程隔离、请求缓存、请求
合并以及服务监控等强大功能。

Spring cloud hystrix 断路器使用：

首先我们需要引入断路器的依赖：

 接下来我们可以使用注解@EnableCircuitBreaker    //开启断路器功能 配置断路器的超时时间，

默认是1秒： hystrix.command.default.execution.isolation.thread.timeoutInMilliseconds: 10000

12：Spring cloud Feign 代理

代码实现请求失败时服务降级策略：

 代码实现请求异常时服务降级策略：

 Spring cloud hystrix 断路器使用

当然我们的断路器功能非常强大，不仅仅只是这些属性和使用方式，还有非常牛掰
的功能，深入学习断路器非常的必要。
比如还可以单独设置某个服务的http调用断路器超时时间等：使用commandKey与
commandProperties属性相互结合使用，可以单独的控制特殊需求的实现。
再比如断路器执行的隔离策略，对应着并发量剧增的场景下使用限流的方式，比
传统的限流策略、限流组件有天然的优势。
还有强大的缓存功能，可以结合着spring cache配合使用 缓存http请求的结果。
断路器为我们提供了批量请求合并的功能，可以将多少频率的http请求批量合并在
一起，发送一个http请求到对应的服务端，节省了http访问的次数，在超高频访问
的场景中非常的有效。

 

由于断路器功能太过强大，这里仅仅举一个栗子说明：高并发限流系统/限流组
件应用.
在断路器的配置限流策略中，execution.isolation.strategy
有两种方式进行处理：THREAD 通过现程池隔离的策略，它会独立在一个线程上
执行，并且他的并发量受线程池中的数量所限制。SEMAPHONE 它则实现在调用
的线程上，通过信号量的方式进行隔离，这种则是类似java中的限流了，受到
信号量计数器的限制所约束。

线程的策略方式：

 信号量的策略方式：

 Hystrix总结：

类似的高大上功能，我们仅仅只需要几个配置项就可以实现其功能，hystrix非常的强大，我们如果掌握了hystrix。可以说对于微服务之间的访问限流控制就做到了极致。

Hystrix Dashboard 监控架构图

顾名思义，仪表盘就是为了监控的。监控什么? 当然是我们断路器服务的并发量、请求率、错误率等信息，为了更好的，方便我们对服务接口进行测试和排查。架构如下：

 

Hystrix dashboard 仪表盘查看图

引入响应的jar包：spring-cloud-starter-hystrix-dashboard；

并且所要监控的服务必须依赖： spring-boot-starter-actuator这个jar才可以监控hystrix.stream 并且启用仪表盘注解配置：@EnableHystrixDashboard

我们通过访问：http://localhost:2001/hystrix即可看到流量监控台：

在下面输入框输入所要监控的服务地址即可（也就是hystrix.stream）：

Hystrix dashboard 仪表盘查看图：

 https://github.com/Netflix/Hystrix/wiki

 

Hystrix turbine 集群监控：

我们已经学会了如何去使用dashboard监控一个断路器所在的服务，那么对于集
群的情况，我们光靠dashbroad是不行的，这里需要引用一个收集组件turbine
进行汇总数据，最后流入到我们的监控台（dashboard）中去，引入
spring-cloud-starter-turbine依赖，并添加注解@EnableTurbine在我们的
项目中，最后我们需要对turbine的yml文件进行相关配置。

 

Turbine与dashboard整合架构图如下所示：