springcloud

回顾之前的知识~

• javase
• 数据库
• 前端
• servlet
• http
• mybatis
• spring
• springMVC
• springboot
• dubbo、zookeeper：分布式基础
• maven，git
• ajax、json
• …

串一下自己会的东西

1. 数据库
2. mybatis
3. spring
4. springMVC
5. springboot
6. dubbo、zookeeper：分布式基础
7. maven，git
8. ajax、json

这阶段该如何学

三层架构 +mvc

框架
	spring：IOC AOP
	
	springboot ：自动装配
	
	模块化~ all in one
	
	模块化的开发 ===all in one，代码没变化
	
微服务架构4个核心问题？
	服务很多，客户端怎么访问----网关
	这么多服务？如何通信----RPC
	如何治理----注册中心
	服务挂了----熔断机制
	
解决方案：
	spring cloud 生态！
	Netflix：一站式解决方案
		api网关：zuul组件
		feign：httpclient：http通信方式，同步，阻塞
		服务注册发现：eureka
		熔断机制：hystrix
	dubbo+zookeeper：半自动需要整合别人的
		api：无，找第三方组件，或者自己实现
		dubbo：
		zookeeper
		熔断机制：没有
		
	springcloudalibaba：最新的一站式解决方案！更简单
	
新概念：服务网格~server mesh
	istio

常见面试题

1. 什么是微服务

   一个完整的项目将其中的几个关键部分模块化独立成个体

2. 微服务之间如何通信

   微服务之间可以通过rpc协议、http协议进行网络连接来互相联系

3. springcloud和dubbo有哪些区别

4. springboot和springcloud，谈谈对他们的理解

5. 什么是服务熔断，什么是服务降级

6. 微服务的优缺点分别是什么

7. 微服务的技术栈

8. eureka和zookeeper的区别

9. …

微服务概述

微服务架构有别于更为传统的单体式方案，可将应用拆分成多个核心功能。每个功能都被称为一项服务，可以单独构建和部署，这意味着各项服务在工作（和出现故障）时不会相互影响。

微服务技术栈

微服务条目	落地技术
服务开发	springboot、spring、springMVC
服务配置与管理	Netflix公司的Archaius、阿里的Diamond等
服务注册与发现	Eureka、consul、zookeeper
服务调用	rest、rpc、grpc
服务熔断器	hystrix、envoy
负载均衡	ribbon、nginx
服务接口调用	feign
消息队列	kafka、rabbitMQ、activeMQ
服务配置中心管理	springcloudConfig、chef
服务路由	zuul
服务监控	zabbix、nagios、metrics、specatator
全链路追踪	zipkin、brave、dapper
服务部署	docker、OpenStack、kubernetes
数据流操作开发包	springcloud stream
时间消息总线	springcloud bus

springcloud

springboot和springcloud关系

• SpringBoot专注于快速方便的开发单个个体微服务。–jar包
• SpringCloud是关注全局的微服务协调整理治理框架，它将SpringBoot开发的一个个单体微服务整合并管理起来，为各个微服务之间提供:配置管理，服务发现，断路器，路由，微代理，事件总线，全局锁，决策竞选，分布式会话等等集成服务。
• SpringBoot可以离开SpringClooud独立使用，开发项目，但是SpringCloud离不开SpringBoot，属于依赖关系
• SpringBoot专注于快速、方便的开发单个个体微服务，SpringCloud关注全局的服务治理框架

dubbo和springcloud技术选型

1：分布式+服务治理dubbo

2：dubbo和springcloud对比

Netflix

服务注册与发现

Eureka是Netflix的一个子模块，也是核心模块之一。Eureka是一个基于REST的服务，用于定位服务，以实现云端中间层服务发现和故障转移，服务注册与发现对于微服务来说是非常重要的，有了服务发现与注册，只需要使用服务的标识符，就可以访问到服务，而不需要修改服务调用的配置文件了，功能类似于Dubbo的注册中心，比如Zookeeper;

导入依赖
编写配置文件
开启这个功能	@Enablexxxxx
配置类

自我保护机制

一句话总结：某时刻某一服务不可用了，eureka不会立刻清理，依旧会对该微服务信息进行保存！

• 默认情况下，如果EurekaServer在一定时间内没有接收到某个微服务实例的心跳，EurekaServer将会注销该实例（默认90秒)。但是当网络分区故障发生时，微服务与Eureka之间无法正常通行，以上行为可能变得非常危险了–因为微服务本身其实是健康的，此时本不应该注销这个服务。Eureka通过自我保护机制来解决这个问题–当EurekaServer节点在短时间内丢失过多客户端时(可能发生了网络分区故障)，那么这个节点就会进入自我保护模式。一旦进入该模式，EurekaServer就会保护服务注册表中的信息，不再删除服务注册表中的数据（也就是不会注销任何微服务)。当网络故障恢复后，该EurekaServer节点会自动退出自我保护模式。
• 在自我保护模式中，EurekaServer会保护服务注册表中的信息，不再注销任何服务实例。当它收到的心跳数重新恢复到阈值以上时，该EurekaServer节点就会自动退出自我保护模式。它的设计哲学就是宁可保留错误的服务注册信息，也不盲目注销任何可能健康的服务实例。一句话:好死不如赖活着
• 综上，自我保护模式是一种应对网络异常的安全保护措施。它的架构哲学是宁可同时保留所有微服务（健康的微服务和不健康的微服务都会保留），也不盲目注销任何健康的微服务。使用自我保护模式，可以让Eureka集群更加的健壮和稳定
  在SpringCloud中，可以使用eureka.server.enable-self-preservation = false 禁用自我保护模式
  【不推荐关闭自我保护机制】

注册中心的CAP原则

CAP是什么?

• C (Consistency)强一致性

• A(Availability)可用性

• P (Partition tolerance)分区容错性

CAP的三进二：CA\CP\AP

作为服务注册中心，Eureka比zookeeper好在哪里?

著名的CAP理论指出，一个分布式系统不可能同时满足C(一致性)、A （可用性)、P(容错性)。

由于分区容错性P在分布式系统中是必须要保证的，因此我们只能在A和C之间进行权衡。

• Zookeeper保证的是CP;
• Eureka保证的是AP;

Zookeeper保证的是CP

当向注册中心查询服务列表时，我们可以容忍注册中心返回的是几分钟以前的注册信息，但不能接受服务直接down掉不可用。也就是说，服务注册功能对可用性的要求要高于一致性。但是zk会出现这样一种情况，当master节点因为网络故障与其他节点失去联系时，剩余节点会重新进行leader选举。问题在于，选举leader的时间太长，30~120s，且选举期间整个zk集群都是不可用的，这就导致在选举期间注册服务瘫痪。在云部署的环境下，因为网络问题使得水集群失去master节点是较大概率会发生的事件，虽然服务最终能够恢复，但是漫长的选举时间导致的注册长期不可用是不能容忍的。

Eureka保证的是AP

​ Eureka看明白了这一点，因此在设计时就优先保证可用性。Eureka各个节点都是平等的，几个节点挂掉不会影响正常节点的工作，剩余的节点依然可以提供注册和查询服务。而Eureka的客户端在向某个Eureka注册时，如果发现连接失败，则会自动切换至其他节点，只要有一台Eureka还在，就能保住注册服务的可用性，只不过查到的信息可能不是最新的，除此之外，Eureka还有一种自我保护机制，如果在15分钟内超过85%的节点都没有正常的心跳，那么Eureka就认为客户端与注册中心出现了网络故障，此时会出现以下几种情况:
1.Eureka不再从注册列表中移除因为长时间没收到心跳而应该过期的服务
2.Eureka仍然能够接受新服务的注册和查询请求，但是不会被同步到其他节点上(即保证当前节点依然可用)

3.当网络稳定时，当前实例新的注册信息会被同步到其他节点中

因此，Eureka可以很好的应对因网络故障导致部分节点失去联系的情况，而不会像zookeeper那样使整个注册服务瘫痪

负载均衡

Ribbon

ribbon是什么?

• Spring Cloud Ribbon是基于Netflix Ribbon实现的一套客户端负载均衡的工具。
• 简单的说，Ribbon是Netflix发布的开源项目，主要功能是提供客户端的软件负载均衡算法，将NetFlix的中间层服务连接在一起。Ribbon的客户端组件提供一系列完整的配置项如:连接超时、重试等等。简单的说，就是在配置文件中列出LoadBalancer(简称LB:负载均衡）后面所有的机器，Ribbon会自动的帮助你基于某种规则(如简单轮询，随机连接等等）去连接这些机器。我们也很容易使用Ribbon实现自定义的负载均衡算法!
• 面试造飞机，面试拧螺丝

ribbon能干嘛

• LB，即负载均衡(Load Balance)，在微服务或分布式集群中经常用的一种应用。
• 负载均衡简单的说就是将用户的请求平摊的分配到多个服务上，从而达到系统的HA（高可用)
• 常见的负载均衡软件有Nginx,Lvs、apache+Tomcat等等
• dubbo、SpringCloud中均给我们提供了负载均衡，SpringCloud的负载均衡算法可以自定义
• 负载均衡简单分类:
  • 集中式LB
    • 即在服务的消费方和提供方之间使用独立的LB设施，如Nginx:反向代理服务器!，由该设施负责把访问请求通过某种策略转发至服务的提供方!
  • 进程式LB
    • 将LB逻辑集成到消费方，消费方从服务注册中心获知有哪些地址可用，然后自己再从这些地址中选出—个合适的服务器。
    • Ribbon就属于进程内LB，它只是一个类库，集成于消费方进程，消费方通过它来获取到服务提供方的地址!

Feign

简介

feign是声明式的web service客户端，它让微服务之间的调用变得更简单了，类似controller调用service。SpritfgCloud集成了Ribbon和Eureka，可在使用Feign时提供负载均衡的http客户端。

只需要创建一个接口，然后添加注解即可!

feign，主要是社区，大家都习惯面向接口编程。这个是很多开发人员的规范。调用微服务访问两种方法

1. 微服务名字【ribbon】
2. 接口和注解【feign 】

Hystrix

服务雪崩

​ 多个微服务之间调用的时候，假设微服务A调用微服务B和微服务C，微服务B和微服务C又调用其他的微服务，这就是所谓的“扇出"、如果扇出的链路上某个微服务的调用响应时间过长或者不可用，对微服务A的调用就会占用越来越多的系统资源，进而引起系统崩溃，所谓的“雪崩效应"。
​ 对于高流量的应用来说，单一的后端依赖可能会导致所有服务器上的所有资源都在几秒中内饱和。比失败更糟糕的是，这些应用程序还可能导致服务之间的延迟增加，备份队列，线程和其他系统资源紧张
导致整个系统发生更多的级联故障，这些都表示需要对故障和延迟进行隔离和管理，以便单个依赖关系的失败，不能取消整个应用程序或系统。
​ 我们需要·弃车保帅·

什么是Hystrix？

Hystrix是一个用于处理分布式系统的延迟和容错的开源库，在分布式系统里，许多依赖不可避免的会调用失败，比如超时，异常等，Hystrix能够保证在一个依赖出问题的情况下，不会导致整体服务失败，避免级联故障，以提高分布式系统的弹性。
“断路器"本身是一种开关装置，当某个服务单元发生故障之后，通过断路器的故障监控(类似熔断保险丝)，向调用方返回一个服务预期的，可处理的备选响应(FallBack)，而不是长时间的等待或者抛出调用方法无法处理的异常，这样就可以保证了服务调用方的线程不会被长时间，不必要的占用，从而避免了故障在分布式系统中的蔓延，乃至雪崩

服务熔断——服务端

服务熔断是什么

​ 熔断机制是对应雪崩效应的一种微服务链路保护机制。
​ 当扇出链路的某个微服务不可用或者响应时间太长时，会进行服务的降级，进而熔断该节点微服务的调用，快速返回错误的响应信息。当检测到该节点微服务调用响应正常后恢复调用链路。在SpringCloud框架里熔断机制通过Hystrix实现。Hystrix会监控微服务间调用的状况，当失败的调用到一定阈值，缺省是5秒内20次调用失败就会启动熔断机制。熔断机制的注解是**@HystrixCommand**。

服务降级——客户端

服务熔断：

​ 服务端

​ 某个服务超时后者异常，引起熔断

服务降级：

​ 客户端

​ 从整体网站请求负载考虑

​ 当某个服务熔断或者关闭之后，服务将不再调用

​ 此时在客户端我们可以准备一个客户端回调，返回一个默认值（缺省值），

​ 整体的服务水平下降了，好歹能用

​ 比直接挂掉强

服务监控——监控服务中的方法

监控网页的配置

1. 添加依赖

   <!--        Hystrix依赖-->
           <dependency>
               <groupId>org.springframework.cloud</groupId>
               <artifactId>spring-cloud-starter-hystrix</artifactId>
               <version>1.4.6.RELEASE</version>
           </dependency>
           <dependency>
               <groupId>org.springframework.cloud</groupId>
               <artifactId>spring-cloud-starter-hystrix-dashboard</artifactId>
               <version>1.4.6.RELEASE</version>
           </dependency>
   

2. 配置端口

   server:
     port: 9001
   

3. 开启监控页面

   @EnableHystrixDashboard //开启监控页面
   

被监控的方法

前提：

需要监控的方法配置了Hystrix熔断的注解 ：@HystrixCommand(fallbackMethod = “xxxMethod”)

1. 添加依赖

   <dependency>
       <groupId>org.springframework.boot</groupId>
       <artifactId>spring-boot-starter-actuator</artifactId>
   </dependency>
   

2. 增加监控所需的servlet

   //增加一个servlet
   @Bean
   public ServletRegistrationBean hystrixMetricsStreamServlet(){
       ServletRegistrationBean register = new ServletRegistrationBean(new HystrixMetricsStreamServlet());
       register.addUrlMappings("/actuator/hystrix.stream");
       return register;
   }
   

结果：

图示讲解：

API网关

Zuul路由网关

什么是Zuul？

​ Zuul包含了对请求的路由和过滤两个最主要的功能:

​ 其中路由功能负责将外部请求转发到具体的微服务实例上，是实现外部访问统一入口的基础，而过滤器功能则负责对请求的处理过程进行干预，是实现请求校验，服务聚合等功能的基础。Zuul和Eureka进行整合，将Zuul自身注册为Eureka服务治理下的应用，同时从Eureka中获得其他微服务的消息，也即以后的访问微服务都是通过Zuul跳转后获得。

注意:Zuul服务最终还是会注册进Eureka

提供:代理＋路由＋过滤三大功能!

springcloud config分布式配置

概述

分布式系统面临的–配置文件的问题

微服务意味着要将单体应用中的业务拆分成一个个子服务，每个服务的粒度相对较小，因此系统中会出现大量的服务，由于每个服务都需要必要的配置信息才能运行，所以一套集中式的，动态的配置管理设施是必不可少的。SpringCloud提供了ConfigServer来解决这个问题，我们每一个微服务自己带着一个application.yml，那上百的的配置文件要修改起来，岂不是要发疯!

​ Spring Cloud Config为微服务架构中的微服务提供集中化的外部配置支持，配置服务器为各个不同微服务应用的所有环节提供了一个中心化的外部配置。

​ Spring Cloud Config 分为服务端和客户端两部分;

​ 服务端也称为分布式配置中心，它是一个独立的微服务应用，用来连接配置服务器并为客户端提供获取配置信息，加密，解密信息等访问接口。

​ 客户端则是通过指定的配置中心来管理应用资源，以及与业务相关的配置内容，并在启动的时候从配置中心获取和加载配置信息。配置服务器默认采用git来存储配置信息，这样就有助于对环境配置进行版本管理。并且可以通过git客户端工具来方便的管理和访问配置内容。

springcloud config分布式配置中心能干嘛

• 集中管理配置文件
• 不同环境，不同配置，动态化的配置更新，分环境部署，比如/dev /test/ /prod /beta /release
• 运行期间动态调整配置，不再需要在每个服务部署的机器上编写配置文件，服务会向配置中心统一拉取配置自己的信息。
• 当配置发生变动时，服务不需要重启，即可感知到配置的变化，并应用新的配置
• 将配置信息以REST接口的形式暴露

与github整合

​ 由于Spring Cloud Config默认使用Git来存储配置文件（也有其他方式，比如支持SVN和本地文件)，但是最推荐的还是Git，而且使用的是http / https访问的形式;

息，这样就有助于对环境配置进行版本管理。并且可以通过git客户端工具来方便的管理和访问配置内容。

springcloud config分布式配置中心能干嘛

• 集中管理配置文件
• 不同环境，不同配置，动态化的配置更新，分环境部署，比如/dev /test/ /prod /beta /release
• 运行期间动态调整配置，不再需要在每个服务部署的机器上编写配置文件，服务会向配置中心统一拉取配置自己的信息。
• 当配置发生变动时，服务不需要重启，即可感知到配置的变化，并应用新的配置
• 将配置信息以REST接口的形式暴露

与github整合

​ 由于Spring Cloud Config默认使用Git来存储配置文件（也有其他方式，比如支持SVN和本地文件)，但是最推荐的还是Git，而且使用的是http / https访问的形式;