自己整理的一些SpringCloud的相关知识点

自己整理的一些SpringCloud的相关知识点

1、常见面试题

1.1、什么是微服务

​ 将单体应用变成多个模块，将单一的应用程序或分成一组小的服务,彻底解耦

1.1.1、微服务与微服务架构的区别

​ 微服务强调服务的大小，是具体解决某个问题/提供落地对应服务的一个服务应用

​ 微服务架构是一种架构模式，

1.2、微服务之间是如何独立通讯的

​ 通过RESTFUL或 RPC

1.3、SpringCloud与Dubhe的区别

1.4、SpringBoot和SpringCloud，请你谈谈对他们的理解

1.5、什么是服务熔断？什么是服务降级

1.6、微服务的优缺点分别是什么？

1.7、你知道的微服务技术栈有哪些

1.8、eureka和zookeeper有什么区别

2、微服务概述

微服务优缺点

优点

• 单一职责
• 每个服务都足够内聚，足够小，代码容易理解
• 开发简单，效率高，一个服务可能就转移做一件事
• 微服务能够被2~5人的小团队单独开发
• 微服务是松耦合的，有功能意义的服务，在开发或部署阶段都是独立的
• 微服务能使用不同的语言开发
• 易于和第三方集成，通过持续集成工具，如jenkins, Hudson ,bamboo
• 微服务易于被一个开发人员理解，修改和维护
• 微服务运去利用融合最新技术
• 微服务只是的业务逻辑代码，不会和HTML，CSS 或其他界面混合
• 每个微服务都有自己的存储能力，可以有自己的数据库，也可以有统一的数据库

缺点

• 开发人员要处理分布式系统的复杂性
• 多服务运维难度高
• 系统部署依赖
• 服务通信成本
• 数据一致性
• 系统集成测试
• 性能监控困难

微服务技术栈

微服务条目	落地技术
服务开发	SpringBoot,Spring,SpringMVC
服务配置与管理	Netflix 公司的 Archaius、 阿里的 Diamond 等
服务注册与发现	Eureka、Zookeeper、Consul等
服务调用	Rest、RPC、gRPC
服务熔断器	Hystrix、Envoy等
负载均衡	Ribbon、Nginx等
服务接口调用（客户端调用服务的简化工具）	Feign等
消息队列	RabbitMQ、Kafka、ActiveMQ
服务配置中心管理	SpringCloudConfig、Chef等
服务路由（API网关）	Zuul等
服务监控	Zabbix、Nagios、Metrics、Specatator等
全链路追踪	Zipkin、Brave、Dapper等
服务部署	Docker、Open Stack、Kubernetes等
数据流操作开发包	SpringCloud Stream （封装与 Redis，Rabbit，Kafka等发送接收消息）
事件消息总线	SpringCloud Bus

等。。。

为什么选择SpringCloud作为微服务架构

选型依据

• 整体解决方案和框架成熟
• 社区热度高
• 可维护性号
• 入门快，好上手

SpringCloud入门概述

SpringCloud和SpringBoot的关系

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

传统互联网架构（没有微服务）

Dubbo 与 SpringCloud

对比

​

	Dubbo	SpringCloud
服务注册中心	Zookeeper	SpringCloud Netflix Eureka
服务调度方式	RPC	REST API
服务监控	Dubbo-monitor	SpringBoot Admin
断路器	不完善	Spring Cloud Netflix Hystrix
服务网关	无	SpringCloud Netflix Zuul
分布式配置	无	SpringCloud Config
服务跟踪	无	SpringCloud Sleuth
消息总线	无	SpringCloud Bus
数据流	无	SpringCloud Stream
批量任务	无	SpringCloud Task

最大区别：SpringCloud抛弃了Dubbo的RPC通信，采用的是基于HTTP的REST方式

严格来说，这两种方式各有优劣。虽然从一定程度上说，后者牺牲了服务调用的性能，但也避免了原生RPC带来的问题。而且REST相比RPC更加灵活，服务提供方和调用方的依赖之一高一纸契约（接口地址），不存在代码级别的强依赖，更适合微服务环境

SpringCloud功能比Dubbo完善，完美支持Spring系列框架

SpringCloud社区支持与更新力度强，Dubbo停更5年，在2017.7月重启

解决的问题域不一样：Dubbo定位是一款RPC框架，SpringCloud的目标是为服务架构下的一站式解决方案

Eureka服务注册与发现

什么是Eureka(尤里卡)

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

对比Zookeeper

CAP原则

RDBMS (Mysql、Oracle、sqlServer) ===> ACID

NoSql (redis、mongdb) ===> CAP

ACID是什么

• A（Atomicity）原子性
• C （Consistency）一致性
• I （Isolation）隔离性
• D（Durability）持久性

CAP是什么

• C（Consistency）强一致性
• A（Availability）可用性
• P（Partition tolerance）分区可容错性

​ CAP只能三选二：CA、AP、CP

CAP理论核心

• 一个分布式系统不可能同时很好的满足一致性，可用性和分区容错性这三个需求
• 根据CAP原理，将NoSQL数据库分成满足CA原则，满足CP原则和满足AP原则三大类
  • CA：单点集群，满足一致性，可用性的系统，通常可扩展性较差
  • CP：满足一致性，分区容错性的系统，通常性能不是特别高
  • AP：满足可用性，分区容错性的系统，通常对一致性要求低一些

Eureka与Zookeeper对比

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

由于分区容错性在分布式系统中必须要保证，因此只能在A和C之间权衡

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

Zookeeper保证的是CP

​ 当向注册中心查询服务列表时,我们可以容忍注册中心返回的是几分钟以前的注册信息,但不能接受服务直接

down掉不可用。也就是说,服务注册功能对可用性的要求要高于一致性。但是Zookeeper会出现这样一种情况,当 master节点因为网络故障与其他节点失去联系时,剩余节点会重新进行 leader选举。问题在于,选举 leader的时间太长,30-120s,且选举期间整个Zookeeper集群都是不可用的，这就导致在选举期间注册服务瘫痪。在云部署的环境下，因为网络问题使得Zookeeper集群失去 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 的客户端组件提供一系列完整的配置项，如：连接超时、重试等等。简单地说，就是在配置文件中列出Load Balancer（简称LB：负载均衡）后面的所有机器，Ribbon 会自动的帮助你基于某种规则（如简单轮询，随机链接等）去连接这些机器。我们也很容易使用Ribbon实现自定义的负载均衡算法！

Ribbon能做什么

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

代码

在消费者客户端导包

配置Rest

使用服务名（Spring的配置）访问

​ 配置负载均衡时name要使用一样的

客户端访问，从Eureka集群获取可用的服务提供者列表，通过列表实现负载均衡

---

Feign（飞in n）负载均衡

简介

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

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

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

​ 1、微服务名字【Ribbon】

​ 2、接口和注解 【Feign】

Feign能做什么

• Feign旨在让编写java Http客户端变得更容易
• 前面使用Ribbon + Rest Temple时，利用Rest Template对Http请求的封装处理，形成了一套模板化的调用方法。但在实际开发中，由于对服务依赖的调用可能不止一处，往往一个接口会被多处调用，所以通常都会针对每个微服务自行封装一些客户端类来包装这些依赖服务的调用。所以，Feign在此基础上做了进一步封装，由他来帮助我们定义和实现以来服务接口的定义，**在Feign的实现下，我们只需要创建一个接口并使用注解的方式配置他们（类似与Dao接口上标注Mapper注解，现在是一个微服务接口上面标注一个Feign注解即可）**既能完成对服务提供方的接口绑定，简化使用Spring Cloud Ribbon时，自动封装服务调用客户端的开发量。

---

Hystrix

分布式系统系统面临的问题

复杂分布式体系结构中的应用程序有数十个依赖关系，每个依赖关系在某些时候将不可避免的失败！

服务雪崩

​ 多个微服务之间调用的时候，假设微服务A调用微服务B和微服务C，微服务B和微服务C又调用其他的微服务，

这就是所谓的“扇出“、如果扇出的链路上某个微服务的调用响应时间过长或者不可用，对微服务A的调用就会占用

越来越多的系统资源，进而引起系统崩溃，所谓的“雪崩效应“。

​ 对于高流量的应用来说，单一的后端依赖可能会导致所有服务器上的所有资源都在几秒中内饱和。比失败更糟

糕的是，这些应用程序还可能导致服务之间的延迟增加，备份队列，线程和其他系统资源紧张，导致整个系统发生

更多的级联故障，这些都表示需要对故障和延迟进行隔离和管理，以便单个依赖关系的失败，不能取消整个应用程

序或系统。

​ 我们需要·弃车保帅

什么是Hystrix (hi s 却克斯)

​ Hystrix是—个用于处理分布式系统的延迟和容错的开源库，在分布式系统里，许多依赖不可避免的会调用失败，比如超时，异常等，Hystrix能够保证在—个依赖岀冋题的情况下，不会导致整体服务失败，避免级联故障，以提高分布式系统的弹性。

​ “断路器”本身是一种开关装置，当某个服务单元发生故障之后，通过断路器的故障监控（类似熔断保险丝），（向调用方返回一个服务预期的，可处理的备选响应（ FallBack），而不是长时间的等待或者抛出调用方法无法处理的异常，这样就可以保证了服务调用方的线程不会被长时间，不必要的占用，从而避免了故障在分布式系统中的蔓延，乃至雪崩

能做什么

• 服务降级
• 服务熔断
• 服务限流
• 接近实时的监控
• 。。。

服务熔断

服务端，某个服务（方法）超时或者异常，而引起熔断

是什么

熔断机制是对应雪崩效应的一种微服务链路保护机制。

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

服务降级

客户端，当某个服务端被关闭，则调用客户端自定义的实现FallbackFactory的类，返回一个缺省值（默认的值）

服务监控

新建一个客户端模块

导入对应依赖

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

需配合服务熔断使用