SpringCloud微服务

SpringCloud微服务：

什么是微服务

微服务就是分布式 将一个大工程差分成多个模块。
比如优乐选项目，改变一个模块代码只需要重启这个模块的Tomcat就行。像之前阶段的项目，改变任何模块代码都得重启整个工程。
微服务与分布式的细微差别是：
1.微服务的应用不一定是分散在多个服务器上，也可以是同一个服务器；
2.微服务集成在各种现有框架中，有其特有的使用方式，一般都比较简单。
目前的微服务并没有一个统一的标准，一般是以业务来划分将传统的一站式应用，拆分成一个个的服务，彻底去耦合，一个微服务就是单功能业务，只做一件事。

微服务与微服务架构

微服务是一种架构模式或者一种架构风格，提倡将单一应用程序划分成一组小的服务，独立部署，服务之间相互配合、相互协调，每个服务运行于自己的进程中。
服务与服务间采用轻量级通讯，如HTTP的RESTful API等
避免统一的、集中式的服务管理机制

微服务的优缺点

优点
每个服务足够内聚，足够小，比较容易聚焦
开发简单且效率高，一个服务只做一件事情
开发团队小，一般2-5人足以（当然按实际为准）
微服务是松耦合的，无论开发还是部署都可以独立完成
微服务能用不同的语言开发
易于和第三方集成，微服务允许容易且灵活的自动集成部署（持续集成工具有Jenkins,Hudson,bamboo等）
微服务易于被开发人员理解，修改和维护，这样可以使小团队更加关注自己的工作成果，而无需一定要通过合作才能体现价值
微服务允许你融合最新的技术
微服务只是业务逻辑的代码，不会和HTML,CSS或其他界面组件融合
每个微服务都可以有自己的存储能力，数据库可自有也可以统一，十分灵活

缺点
开发人员要处理分布式系统的复杂性
多服务运维难度，随着服务的增加，运维的压力也会增大
依赖系统部署
服务间通讯的成本
数据的一致性
系统集成测试
性能监控的难度

SpringCloud

Spring的三大模块：SpringBoot（构建），Spring Cloud（协调），Spring Cloud Data Flow（连接）

SpringCloud是什么？

1.Spring Cloud为开发者提供了快速构建分布式系统的通用模型的工具（包括配置管理，服务发现，熔断器，智能路由，微代理，控制总线，一次性令牌，全局锁，领导选举，分布式会话，集群状态等）。
2.Spring Cloud基于Spring Boot实现
3.SpringCloud是微服务的一种。其余还有ZeroC IceGrid微服务架构、基于消息队列的微服务架构、Docker Swarm微服务架构等。

Spring Cloud是一系列框架的有序集合。它利用Spring Boot的开发便利性巧妙地简
化了分布式系统基础设施的开发，如服务发现注册、配置中心、消息总线、负载均衡、
熔断器、数据监控等，都可以用Spring Boot的开发风格做到一键启动和部署。Spring并
没有重复制造轮子，它只是将目前各家公司开发的比较成熟、经得起实际考验的服务框
架组合起来，通过Spring Boot风格进行再封装屏蔽掉了复杂的配置和实现原理，最终给
开发者留出了一套简单易懂、易部署和易维护的分布式系统开发工具包。
Spring Cloud项目的官方网址：https://spring.io/projects/spring-cloud

SpringCloud和SpringBoot的关系

Spring Boot 是 Spring 的一套快速配置脚手架，可以基于Spring Boot 快速开发单
个微服务，Spring Cloud是一个基于Spring Boot实现的云应用开发工具；Spring Boot专
注于快速、方便集成的单个微服务个体，Spring Cloud关注全局的服务治理框架；
Spring Boot使用了默认大于配置的理念，很多集成方案已经帮你选择好了，能不配置就
不配置，Spring Cloud很大的一部分是基于Spring Boot来实现，可以不基于Spring Boot
吗？不可以。
Spring Boot可以离开Spring Cloud独立使用开发项目，但是Spring Cloud离不开
Spring Boot，属于依赖的关系。

SpringCloud主要框架

服务发现——Netflix Eureka
服务调用——Netflix Feign
熔断器——Netflix Hystrix
服务网关——Netflix Zuul
分布式配置——Spring Cloud Config
消息总线 ——Spring Cloud Bus

SpringCloud版本

目前课程采用的SpringCloud版本为Finchley.M9 。版本号命名初看很奇怪。
SpringCloud由于是一系列框架组合，为了避免与包含的自框架版本产生混淆，采
用伦敦地铁站的名称作为版本名，形式为版本名+里程碑号。 M9为第9个里程碑版本。
以下是SpringBoot与Spring Cloud版本的对照表。
服务发现组件Eureka

Eureka简介

Eureka是Spring Cloud Netflix微服务套件中的一部分，是一套成熟的服务注册和发现组件，可以与Springboot构建的微服务很容易的整合起来。
Eureka包含了服务器端和客户端组件。
Eureka服务器用作服务注册服务器。
Eureka客户端是一个java客户端，用来简化与服务器的交互、作为轮询负载均衡器，并提供服务的故障切换支持

Eureka高可用

即集群
EurekaServer可以是一个集群，形成高可用的Eureka注册中心
多个Eureka Server之间也会互相注册为服务，当服务提供者注册到Eureka Server集群中的某个节点时，该节点会把服务的信息同步给集群中的每个节点，从而实现数据同步。
因此，无论客户端访问到Eureka Server集群中的任意一个节点，都可以获取到完整的服务列表信息。

服务调用组件

即负载均衡
之前我们启动了一个服务作为生产者，通过DiscoveryClient来获取服务实例信息，然后获取ip和端口来访问。
但是实际环境中，往往会开启很多个服务的集群。获取的服务列表中就会有多个，一般这种情况下我们就需要编写负载均衡算法，在多个实例列表中进行选择该访问哪一个服务。
但SpringColud中已经帮我们集成了一系列负载均衡组件：LoadBalancerClient、Ribbon、Feign，简单修改代码即可使用。

服务调用基于LoadBalancerClient
使用LoadBalancerClient等负载均衡组件，原理如下：

服务调用基于Ribbon

在上一步LoadBalancerClient实现了负责均衡的基础上，Ribbon可配置调度规则

Ribbon介绍
Spring Cloud Ribbon是基于Netflix Ribbon实现的一套客户端负载均衡的工具。它是一个基于HTTP和TCP的客户端负载均衡器。

负载均衡规则配置
默认情况下Ribbon的负载均衡策略是轮训，Ribbon常用的负载均衡规则：
1、简单轮询负载均衡（RoundRobin）
以轮询的方式依次将请求调度不同的服务器
2、随机负载均衡 （Random）
随机选择状态为UP的Server
3、加权响应时间负载均衡 （WeightedResponseTime）
根据响应时间分配一个weight，响应时间越长，weight越小，被选中的可能性越低。
4、区域感知轮询负载均衡（ZoneAware）
复合判断server所在区域的性能和server的可用性选择server
5、最空闲连接
选择一个最小的并发连接请求的server
6、重试规则
对选定的负载均衡策略机上重试机制

重试机制配置
当选择轮询负载均衡策略的时候，如果一个服务停掉，因为服务剔除的延迟，消费者并不会立即得到最新的服务列表，此时再次访问会得到错误提示。
1.效果演示
修改配置文件，改回轮询机制

#配置指定服务的负载均衡策略
#NFLoadBalancerRuleClassName: com.netflix.loadbalancer.RandomRule #配置规则 随机
#NFLoadBalancerRuleClassName: com.netflix.loadbalancer.RoundRobinRule #配置规则 轮询
#NFLoadBalancerRuleClassName: com.netflix.loadbalancer.RetryRule #配置规则 重试
#NFLoadBalancerRuleClassName: com.netflix.loadbalancer.WeightedResponseTimeRule #配置规则 响应时间权重
#NFLoadBalancerRuleClassName: com.netflix.loadbalancer.BestAvailableRule #配置规则 最空闲连接策略
USERPROVIDER.ribbon.NFLoadBalancerRuleClassName=com.netflix.loadbalancer.RoundRobinRule
#针对每个服务来配置负载均衡规则
#格式是：{服务名称}.ribbon.NFLoadBalancerRuleClassName=具体的负载均衡类

服务调用基于Feign

Feign介绍
Feign是一个声明性的web服务客户端，它使编写web服务客户机变得更容易。使用Feign创建接口并对其进行注释，就可以通过该接口调用生产者提供的服务。Spring Cloud对Feign进行了增强，使得Feign支持了Spring MVC注解
两点：
1、Feign采用的是接口加注解;
2、Feign 整合了ribbon

Feign和Ribbon完成的功能相同
Feign在Ribbon基础进行了封装，所以使用更简单
具体区别如下：
Ribbon和Feign都是用于调用其他服务的，不过方式不同。
1.启动类使用的注解不同，Ribbon用的是@RibbonClient，Feign用的是@EnableFeignClients。
2.服务的指定位置不同，Ribbon是在@RibbonClient注解上声明，Feign则是在定义抽象方法的接口中使用@FeignClient声明。
3.调用方式不同，Ribbon需要自己构建http请求，模拟http请求然后使用RestTemplate发送给其他服务，步骤相当繁琐。
Feign则是在Ribbon的基础上进行了一次改进，采用接口的方式，将需要调用的其他服务的方法定义成抽象方法即可，
不需要自己构建http请求。不过要注意的是抽象方法的注解、方法签名要和提供服务的方法完全一致。
熔断器组件Netflix Hystrix
作用：有些服务出现问题，反应很慢或出现大量超时，熔断器可以主动断掉此服务，防止整体体系被拖垮。情况好转还可自动重连。

熔断器Hystix介绍

Hystix是Netflix开源的一个延迟和容错库，用于隔离访问远程服务、第三方库，防止出现级联失败。
主页：https://github.com/Netflix/Hystrix/

熔断器Hystix的原理和作用
熔断器机制的原理很简单，像家里的电路保险丝，如果电路发生短路能立刻熔断电路，避免发生灾难。
在分布式系统中应用这一模式之后，服务调用方可以自己进行判断某些服务反应慢或者存在大量超时的情况时，能够主动熔断，防止整体系统被拖垮。
不同于电路熔断只能断不能自动重连，Hystrix可以实现弹性容错，当情况好转之后，可以自动重连。
正常工作的情况下，客户端请求调用服务API接口：

优化Ribbon使用Hystix

对比理解：超时、重试、熔断

超时
在接口调用过程中，consumer(如UserWeb02)调用provider(如UserProvdier02)的时候，provider在响应的时候，有可能会慢，如果provider 10s响应，那么consumer也会至少10s才响应。如果这种情况频度很高，那么就会整体降低consumer端服务的性能。
这种响应时间慢的症状，就会像一层一层波浪一样，从底层系统一直涌到最上层，造成整个链路的超时。
所以，consumer不可能无限制地等待provider接口的返回，会设置一个时间阈值，如果超过了这个时间阈值，就不继续等待。
这个超时时间选取，一般看provider正常响应时间是多少

重试
超时时间的配置是为了保护服务，避免consumer(如UserWeb02)服务因为provider(如UserProvdier02) 响应慢而也变得响应很慢，这样consumer可以尽量保持原有的性能。
但是也有可能provider(如UserProvdier02)只是偶尔抖动，一超时就直接放弃也有些浪费。
对于这种偶尔抖动，可以在超时后重试一下，重试如果正常返回了，这次请求就被挽救了，能够正常给前端返回数据，只不过比原来响慢一点。
重试时的一些细化策略：
重试可以考虑切换一台机器来进行调用，因为原来机器可能由于临时负载高而性能下降，重试会更加剧其性能问题，而换一台机器，得到更快返回的概率也更大一些。

熔断
重试是为了应付偶尔抖动的情况，以求更多地挽回损失，可是如果provider(如UserProvdier02)持续的响应时间超长呢?
若provider(如UserProvdier02)是核心的服务，down掉基本就没法提供服务了，那也没话说(也可通过集群解决)。 如果是一个不那么重要的服务，却因为这个服务一直响应时间长导致consumer(如UserWeb02)里面的核心服务也拖慢，那么就得不偿失了。

单纯超时也解决不了这种情况了，因为一般超时时间，都比平均响应时间长一些，现在所有的打到provider的请求都超时了，那么consumer请求provider的平均响应时间就等于超时时间了，负载也被拖下来了。

而重试有可能会加重这种问题：如设置了重试本机100次，本机不通,100次也依然不会通,响应等待时间成百倍增长。
因此就出现了熔断的逻辑，也就是，如果检查出来频繁超时，就把consumer调用provider的请求，直接断掉，不允许调用，等provider服务恢复稳定之后，还可以自动恢复调用。

Hystix监控服务器搭建

配置监控连接情况
断路器是根据一段时间窗内的请求情况来判断并操作断路器的打开和关闭状态的。而这些请求情况的指标信息都是HystrixCommand和HystrixObservableCommand实例在执行过程中记录的重要度量信息，它们除了Hystrix断路器实现中使用之外，对于系统运维也有非常大的帮助。这些指标信息会以“滚动时间窗”与“桶”结合的方式进行汇总，并在内存中驻留一段时间，以供内部或外部进行查询使用，Hystrix Dashboard就是这些指标内容的消费者之一。