SpringCloud个人小总结

1、spring cloud 介绍

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

    spring cloud 对于中小型互联网公司来说是一种福音，因为这类公司往往没有实力或者没有足够的资金投入去开发自己的分布式系统基础设施，使用 spring cloud 一站式解决方案能在从容应对业务发展的同时大大减少开发成本。同时，随着近几年微服务架构和 docker 容器概念的火爆，也会让 spring cloud 在未来越来越“云”化的软件开发风格中立有一席之地，尤其是在目前五花八门的分布式解决方案中提供了标准化的、一站式的技术方案，意义可能会堪比当年 servlet 规范的诞生，有效推进服务端软件系统技术水平的进步。

2、spring cloud 技术组成

eureka：微服务治理，服务注册和发现

ribbon：负载均衡、请求重试

hystrix：断路器，服务降级、熔断

feign：ribbon + hystrix 集成，并提供生命式客户端

hystrix dashboard 和 turbine：hystrix 微服务监控

zuul：API 网关，提供微服务的统一入口，并提供统一的权限验证

config：配置中心

bus：配置更新消息总线

sleuth：链路追踪

2.1 eureka注册中心

与zookeeper 类似,维护一组微服务的地址信息

Zookeeper：某一个微服务不可用,会立即删除该服务的注册信息

eureka：某一个微服务不可用,会保护该服务的注册信息,不删除

eureka的设计值认为,服务不可用可能不是服务本身的问题,只是由于微服务和注册中心之间的网络问题,而与其他微服务之间可能仍然可以连接

netflix公司开发的一套微服务框架,并开源,spring cloud集成了netflix 的微服务框架:

eureka

ribbon

hystrix

feign

zuul

客户端每30秒向eureka服务器发送信条数据

如果一个客户端90秒内没有发送心跳数据,认为该服务不可用

客户端每隔30秒,从eureka拉取新的注册信息

2.2 ribbon

作用: 负载均衡和重试

封装 RestTemplate,生成动态代理,来添加负载均衡和重试的代码

单独使用ribbon,开启重试需要自己写代码,添加重试参数配置

后面 ribbon 被feign 和 zuul 封装,不做任何配置,不写任何代码,可以直接使用负载均衡和重试

2.3 hystrix

断路器，降级和熔断

降级:

当服务不可用,或者访问超时,可以执行降级代码,可以返回错误信息,或者返回缓存数据

熔断:

10秒内请求数量达到20个,并且,有50% 出现失败降级的情况,会打开断路器,所有的请求,都直接降级,不再向后台微服务转发

断路器打开5秒后,会处于半开状态,当请求到达时,会尝试向后台符转发,如果成功,会关闭断路器,如果仍然失败,保持打开状态

2.4 feign

声明式客户端、整合 ribbon 和 hystrix

feign整合ribbon

不需要任何配置,已经启用ribbon的负载均衡和重试

 eign整合 hystrix

启用 hystrix

feign.hystrix.enabled=true

添加 hystrix 依赖

暴露 hystrix.stream 监控端点

2.5 zuul

作用：api网关，路由，负载均衡等多种作用

简介：类似nginx，反向代理的功能，不过netflix自己增加了一些配合其他组件的特性。

    在微服务架构中，后端服务往往不直接开放给调用端，而是通过一个API网关根据请求的url，路由到相应的服务。当添加API网关后，在第三方调用端和服务提供方之间就创建了一面墙，这面墙直接与调用方通信进行权限控制，后将请求均衡分发给后台服务端。

过滤器权限过滤：继承 ZuulFilter

降级：实现 FallbackProvider

2.5 config

作用：配置管理

简介：SpringCloud Config提供服务器端和客户端。服务器存储后端的默认实现使用git，因此它轻松支持标签版本的配置环境，以及可以访问用于管理内容的各种工具。

1. 常见面试题

问题一：什么是Spring Cloud？

Spring cloud流应用程序启动器是基于Spring Boot的Spring集成应用程序，提供与外部系统的集成。Spring cloud Task，一个生命周期短暂的微服务框架，用于快速构建执行有限数据处理的应用程序。

 

问题二：使用Spring Cloud有什么优势？

使用Spring Boot开发分布式微服务时，我们面临以下问题

1、与分布式系统相关的复杂性-这种开销包括网络问题，延迟开销，带宽问题，安全问题。

2、服务发现-服务发现工具管理群集中的流程和服务如何查找和互相交谈。它涉及一个服务目录，在该目录中注册服务，然后能够查找并连接到该目录中的服务。

3、冗余-分布式系统中的冗余问题。

4、负载平衡 --负载平衡改善跨多个计算资源的工作负荷，诸如计算机，计算机5、集群，网络链路，中央处理单元，或磁盘驱动器的分布。

6、性能-问题 由于各种运营开销导致的性能问题。

7、部署复杂性-Devops技能的要求。

优点：

Spring Cloud 来源于 Spring，质量、稳定性、持续性都可以得到保证。

Spirng Cloud 天然支持 Spring Boot，更加便于业务落地。

Spring Cloud 发展非常的快，从 2016 年开始接触的时候相关组件版本为 1.x，到现在将要发布 2.x 系列。

Spring Cloud 是 Java 领域最适合做微服务的框架。

相比于其它框架，Spring Cloud 对微服务周边环境的支持力度最大。

对于中小企业来讲，使用门槛较低。

Spring Cloud 是微服务架构的最佳落地方案

问题三：服务注册和发现是什么意思？Spring Cloud如何实现？

    当我们开始一个项目时，我们通常在属性文件中进行所有的配置。随着越来越多的服务开发和部署，添加和修改这些属性变得更加复杂。有些服务可能会下降，而某些位置可能会发生变化。手动更改属性可能会产生问题。 Eureka服务注册和发现可以在这种情况下提供帮助。由于所有服务都在Eureka服务器上注册并通过调用Eureka服务器完成查找，因此无需处理服务地点的任何更改和处理。

问题四：负载平衡的意义什么？

    在计算中，负载平衡可以改善跨计算机，计算机集群，网络链接，中央处理单元或磁盘驱动器等多种计算资源的工作负载分布。负载平衡旨在优化资源使用，最大化吞吐量，最小化响应时间并避免任何单一资源的过载。使用多个组件进行负载平衡而不是单个组件可能会通过冗余来提高可靠性和可用性。负载平衡通常涉及专用软件或硬件，例如多层交换机或域名系统服务器进程。

问题五：什么是Hystrix？它如何实现容错？ 

 Hystrix是一个延迟和容错库，旨在隔离远程系统，服务和第三方库的访问点，当出现故障是不可避免的故障时，停止级联故障并在复杂的分布式系统中实现弹性。

  通常对于使用微服务架构开发的系统，涉及到许多微服务。这些微服务彼此协作。 

问题六：什么是Hystrix断路器？我们需要它吗？ 

由于某些原因，employee-consumer公开服务会引发异常。在这种情况下使用Hystrix我们定义了一个回退方法。如果在公开服务中发生异常，则回退方法返回一些默认值。如果firstPage method() 中的异常继续发生，则Hystrix电路将中断，并且员工使用者将一起跳过firtsPage方法，并直接调用回退方法。 断路器的目的是给第一页方法或第一页方法可能调用的其他方法留出时间，并导致异常恢复。可能发生的情况是，在负载较小的情况下，导致异常的问题有更好的恢复机会 

1. solr-lucene

4.1 solr概念

Solr是一个高性能，基于Lucene的全文搜索服务器。同时对其进行了扩展，提供了比Lucene更为丰富的查询语言，同时实现了可配置、可扩展，并对查询性能进行了优化，并且提供了一个完善的功能管理界面，是一款非常优秀的全文搜索引擎。

4.2 lucene概念

Lucene是apache jakarta项目的一个子项目，是一个开放源代码的全文检索引擎开发工具包，但它不是一个完整的全文检索引擎，而是一个全文检索引擎的架构，提供了完整的查询引擎和索引引擎，部分文本分析引擎。Lucene的目的是为软件开发人员提供一个简单易用的工具包，以方便的在目标系统中实现全文检索的功能，或者是以此为基础建立起完整的全文检索引擎。

4.3 倒排索引

Mysql索引是（B+tree）

我们一般情况下,先找到文档,再在文档中找出包含的词;

 

倒排索引则是这个过程反过来,用词,来找出它出现的文档.

 

实际举例

文档编号	文档内容
1	全文检索引擎工具包
2	全文检索引擎的架构
3	查询引擎和索引引擎

分词结果

文档编号	分词结果集
1	{全文,检索,引擎,工具,包}
2	{全文,检索,引擎,的,架构}
3	{查询,引擎,和,索引,引擎}

1. rabbitMQ

5.1 概念

    MQ全称是Message Queue，可以理解为消息队列的意思，简单来说就是消息以管道的方式进行传递。RabbitMQ是一个实现了AMQP（Advanced Message Queuing Protocol）高级消息队列协议的消息队列服务，用Erlang语言的。

RabbitMQ是一种消息中间件，用于处理来自客户端的异步消息。服务端将要发送的消息放入到队列池中。接收端可以根据RabbitMQ配置的转发机制接收服务端发来的消息。RabbitMQ依据指定的转发规则进行消息的转发、缓冲和持久化操作，主要用在多服务器间或单服务器的子系统间进行通信，是分布式系统标准的配置。

为什么选择RabbitMQ

现在的市面上有很多MQ可以选择，比如ActiveMQ、ZeroMQ、Appche Qpid，那问题来了为什么要选择RabbitMQ？

1、除了Qpid，RabbitMQ是唯一一个实现了AMQP标准的消息服务器；

2、可靠性，RabbitMQ的持久化支持，保证了消息的稳定性；

3、高并发，RabbitMQ使用了Erlang开发语言，Erlang是为电话交换机开发的语言，天生自带高并发光环，和高可用特性；

4、集群部署简单，正是应为Erlang使得RabbitMQ集群部署变的超级简单；

5、社区活跃度高，根据网上资料来看，RabbitMQ也是首选；

5.2 工作模式

5.2.1 简单模式

RabbitMQ是一个消息中间件，你可以想象它是一个邮局。当你把信件放到邮箱里时，能够确信邮递员会正确地递送你的信件。RabbitMq就是一个邮箱、一个邮局和一个邮递员。

发送消息的程序是生产者

队列就代表一个邮箱。虽然消息会流经RbbitMQ和你的应用程序，但消息只能被存储在队列里。队列存储空间只受服务器内存和磁盘限制，它本质上是一个大的消息缓冲区。多个生产者可以向同一个队列发送消息，多个消费者也可以从同一个队列接收消息.

消费者等待从队列接收消息

 

5.2.2 工作模式

 

    工作队列(即任务队列)背后的主要思想是避免立即执行资源密集型任务，并且必须等待它完成。相反，我们将任务安排在稍后完成。

    我们将任务封装为消息并将其发送到队列。后台运行的工作进程将获取任务并最终执行任务。当运行多个消费者时，任务将在它们之间分发。

使用任务队列的一个优点是能够轻松地并行工作。如果我们正在积压工作任务，我们可以添加更多工作进程，这样就可以轻松扩展。

一个生产者，多个消费者，每个消费者获取到的消息唯一。

1、  自动模式    消费者从消息队列获取消息后，服务端就认为该消息已经成功消费。2、  手动模式    消费者从消息队列获取消息后，服务端并没有标记为成功消费    消费者成功消费后需要将状态返回到服务端

5.2.3 发布订阅模式

 

一个生产者发送的消息会被多个消费者获取。 
生产者：可以将消息发送到队列或者是交换机。 
消费者：只能从队列中获取消息。 
如果消息发送到没有队列绑定的交换机上，那么消息将丢失。

Exchanges 交换机（使用fanout交换机）

    RabbitMQ消息传递模型的核心思想是，生产者永远不会将任何消息直接发送到队列。实际上，通常生产者甚至不知道消息是否会被传递到任何队列。

    相反，生产者只能向交换机(Exchange)发送消息。交换机是一个非常简单的东西。一边接收来自生产者的消息，另一边将消息推送到队列。交换器必须确切地知道如何处理它接收到的消息。它应该被添加到一个特定的队列中吗?它应该添加到多个队列中吗?或者它应该被丢弃。这些规则由exchange的类型定义。

    有几种可用的交换类型:direct、topic、header和fanout。我们将关注最后一个——fanout。让我们创建一个这种类型的交换机，并称之为 logs: ch.exchangeDeclare("logs", "fanout");

    fanout交换机非常简单。它只是将接收到的所有消息广播给它所知道的所有队列。这正是我们的日志系统所需要的。

5.2.4 路由模式

 

1. 发送消息到交换机并且要指定路由key 
   2、 消费者将队列绑定到交换机时需要指定路由key

使用直连交换机 Direct exchange

如果将日志消息写入磁盘的程序只接收关键error，而不是在warning或info日志消息上浪费磁盘空间。

前面我们使用的是fanout交换机，这并没有给我们太多的灵活性——它只能进行简单的广播。

我们将用直连交换机(Direct exchange)代替。它背后的路由算法很简单——消息传递到bindingKey与routingKey完全匹配的队列。

5.2.5 主题模式

 

    在上一小节，我们改进了日志系统。我们没有使用只能进行广播的fanout交换机，而是使用Direct交换机，从而可以选择性接收日志。

虽然使用Direct交换机改进了我们的系统，但它仍然有局限性——它不能基于多个标准进行路由。

    在我们的日志系统中，我们可能不仅希望根据级别订阅日志，还希望根据发出日志的源订阅日志。

    这将给我们带来很大的灵活性——我们可能只想接收来自“cron”的关键错误，但也要接收来自“kern”的所有日志。

要在日志系统中实现这一点，我们需要了解更复杂的Topic交换机。

主题交换机 Topic exchange

发送到Topic交换机的消息,它的的routingKey,必须是由点分隔的多个单词。单词可以是任何东西，但通常是与消息相关的一些特性。几个有效的routingKey示例:“stock.usd.nyse”、“nyse.vmw”、“quick.orange.rabbit”。routingKey可以有任意多的单词，最多255个字节。

bindingKey也必须采用相同的形式。Topic交换机的逻辑与直连交换机类似——使用特定routingKey发送的消息将被传递到所有使用匹配bindingKey绑定的队列。bindingKey有两个重要的特殊点:

* 可以通配单个单词。

# 可以通配零个或多个单词。

5.2.6 RPC模式

 

(RPC) Remote Procedure Call Protocol 远程过程调用协议

    在一个大型的公司，系统由大大小小的服务构成，不同的团队维护不同的代码，部署在不同的机器。但是在做开发时候往往要用到其它团队的方法，因为已经有了实现。但是这些服务部署不同的机器上，想要调用就需要网络通信，这些代码繁琐且复杂，一不小心就会写的很低效。RPC协议定义了规划，其它的公司都给出了不同的实现。比如微软的wcf，以及现在火热的WebApi。

回调队列 Callback Queue

使用RabbitMQ去实现RPC很容易。一个客户端发送请求信息，并得到一个服务器端回复的响应信息。为了得到响应信息，我们需要在请求的时候发送一个“回调”队列地址。我们可以使用默认队列。

关联id (correlationId)：

    在上面的代码中，我们会为每个RPC请求创建一个回调队列。 这是非常低效的，这里还有一个更好的方法:让我们为每个客户端创建一个回调队列。

这就提出了一个新的问题，在队列中得到一个响应时，我们不清楚这个响应所对应的是哪一条请求。这时候就需要使用关联id（correlationId）。我们将为每一条请求设置唯一的的id值。稍后，当我们在回调队列里收到一条消息的时候，我们将查看它的id属性，这样我们就可以匹配对应的请求和响应。如果我们发现了一个未知的id值，我们可以安全的丢弃这条消息，因为它不属于我们的请求。

RPC的工作方式是这样的:

对于RPC请求，客户端发送一条带有两个属性的消息:replyTo,设置为仅为请求创建的匿名独占队列,和correlationId,设置为每个请求的惟一id值。

请求被发送到rpc_queue队列。

RPC工作进程(即:服务器)在队列上等待请求。当一个请求出现时，它执行任务,并使用replyTo字段中的队列将结果发回客户机。

客户机在回应消息队列上等待数据。当消息出现时，它检查correlationId属性。如果匹配请求中的值，则向程序返回该响应数据。

5.3 其他

ConnectionFactory（连接管理器）、Channel（信道）、Exchange（交换器）、Queue（队列）、RoutingKey（路由键）、BindingKey（绑定键）。

ConnectionFactory（连接管理器）：应用程序与Rabbit之间建立连接的管理器，程序代码中使用；

Channel（信道）：消息推送使用的通道；

Exchange（交换器）：用于接受、分配消息；

Queue（队列）：用于存储生产者的消息；

RoutingKey（路由键）：用于把生成者的数据分配到交换器上；

BindingKey（绑定键）：用于把交换器的消息绑定到队列上；

5.3.1 消息持久化

    Rabbit队列和交换器有一个不可告人的秘密，就是默认情况下重启服务器会导致消息丢失，那么怎么保证Rabbit在重启的时候不丢失呢？答案就是消息持久化。

当你把消息发送到Rabbit服务器的时候，你需要选择你是否要进行持久化，但这并不能保证Rabbit能从崩溃中恢复，想要Rabbit消息能恢复必须满足3个条件：

    1、投递消息的时候durable设置为true，消息持久化，代码：channel.queueDeclare(x, true, false, false, null)，参数2设置为true持久化；

    2、设置投递模式deliveryMode设置为2（持久），代码：channel.basicPublish(x, x, MessageProperties.PERSISTENT_TEXT_PLAIN,x)，参数3设置为存储纯文本到磁盘；

    3、消息已经到达持久化交换器上；

4、消息已经到达持久化的队列；

持久化工作原理

    Rabbit会将你的持久化消息写入磁盘上的持久化日志文件，等消息被消费之后，Rabbit会把这条消息标识为等待垃圾回收。

持久化的缺点

    消息持久化的优点显而易见，但缺点也很明显，那就是性能，因为要写入硬盘要比写入内存性能较低很多，从而降低了服务器的吞吐量，尽管使用SSD硬盘可以使事情得到缓解，但他仍然吸干了Rabbit的性能，当消息成千上万条要写入磁盘的时候，性能是很低的。

所以使用者要根据自己的情况，选择适合自己的方式。

5.4 常见面试题

1.什么是rabbitmq

   采用AMQP高级消息队列协议的一种消息队列技术,最大的特点就是消费并不需要确保提供方存在,实现了服务之间的高度解耦

2.为什么要使用rabbitmq

1.在分布式系统下具备异步,削峰,负载均衡等一系列高级功能;

2.拥有持久化的机制，进程消息，队列中的信息也可以保存下来。

3.实现消费者和生产者之间的解耦。

4.对于高并发场景下，利用消息队列可以使得同步访问变为串行访问达到一定量的限流，利于数据库的操作。

5.可以使用消息队列达到异步下单的效果，排队中，后台进行逻辑下单。

3.使用rabbitmq的场景

1.服务间异步通信

2.顺序消费

3.定时任务

4.请求削峰

4.如何确保消息正确地发送至RabbitMQ？ 如何确保消息接收方消费了消息？

    发送方确认模式：

将信道设置成confirm模式（发送方确认模式），则所有在信道上发布的消息都会被指派一个唯一的ID。

一旦消息被投递到目的队列后，或者消息被写入磁盘后（可持久化的消息），信道会发送一个确认给生产者（包含消息唯一ID）。

如果RabbitMQ发生内部错误从而导致消息丢失，会发送一条nack（not acknowledged，未确认）消息。

发送方确认模式是异步的，生产者应用程序在等待确认的同时，可以继续发送消息。当确认消息到达生产者应用程序，生产者应用程序的回调方法就会被触发来处理确认消息。

    接收方确认机制

接收方消息确认机制：消费者接收每一条消息后都必须进行确认（消息接收和消息确认是两个不同操作）。只有消费者确认了消息，RabbitMQ才能安全地把消息从队列中删除。

这里并没有用到超时机制，RabbitMQ仅通过Consumer的连接中断来确认是否需要重新发送消息。也就是说，只要连接不中断，RabbitMQ给了Consumer足够长的时间来处理消息。保证数据的最终一致性；

下面罗列几种特殊情况：

如果消费者接收到消息，在确认之前断开了连接或取消订阅，RabbitMQ会认为消息没有被分发，然后重新分发给下一个订阅的消费者。（可能存在消息重复消费的隐患，需要去重）

如果消费者接收到消息却没有确认消息，连接也未断开，则RabbitMQ认为该消费者繁忙，将不会给该消费者分发更多的消息。

5.如何避免消息重复投递或重复消费？

    在消息生产时，MQ内部针对每条生产者发送的消息生成一个inner-msg-id，作为去重的依据（消息投递失败并重传），避免重复的消息进入队列；

在消息消费时，要求消息体中必须要有一个bizId（对于同一业务全局唯一，如支付ID、订单ID、帖子ID等）作为去重的依据，避免同一条消息被重复消费。

6.消息基于什么传输？

    由于TCP连接的创建和销毁开销较大，且并发数受系统资源限制，会造成性能瓶颈。RabbitMQ使用信道的方式来传输数据。信道是建立在真实的TCP连接内的虚拟连接，且每条TCP连接上的信道数量没有限制。

7.消息如何分发？

    若该队列至少有一个消费者订阅，消息将以循环（round-robin）的方式发送给消费者。每条消息只会分发给一个订阅的消费者（前提是消费者能够正常处理消息并进行确认）。

通过路由可实现多消费的功能

8.消息怎么路由？

消息提供方->路由->一至多个队列

消息发布到交换器时，消息将拥有一个路由键（routing key），在消息创建时设定。

通过队列路由键，可以把队列绑定到交换器上。

消息到达交换器后，RabbitMQ会将消息的路由键与队列的路由键进行匹配（针对不同的交换器有不同的路由规则）；

常用的交换器主要分为一下三种：

fanout：如果交换器收到消息，将会广播到所有绑定的队列上

direct：如果路由键完全匹配，消息就被投递到相应的队列

topic：可以使来自不同源头的消息能够到达同一个队列。 使用topic交换器时，可以使用通配符

9.如何确保消息不丢失？

    消息持久化，当然前提是队列必须持久化

RabbitMQ确保持久性消息能从服务器重启中恢复的方式是，将它们写入磁盘上的一个持久化日志文件，当发布一条持久性消息到持久交换器上时，Rabbit会在消息提交到日志文件后才发送响应。

一旦消费者从持久队列中消费了一条持久化消息，RabbitMQ会在持久化日志中把这条消息标记为等待垃圾收集。如果持久化消息在被消费之前RabbitMQ重启，那么Rabbit会自动重建交换器和队列（以及绑定），并重新发布持久化日志文件中的消息到合适的队列。

10.使用RabbitMQ有什么好处？

服务间高度解耦，

异步通信性能高，

流量削峰

11.rabbitmq的集群

    镜像集群模式

你创建的queue，无论元数据还是queue里的消息都会存在于多个实例上，然后每次你写消息到queue的时候，都会自动把消息到多个实例的queue里进行消息同步。

    好处在于，你任何一个机器宕机了，没事儿，别的机器都可以用。坏处在于，第一，这个性能开销也太大了吧，消息同步所有机器，导致网络带宽压力和消耗很重！第二，这么玩儿，就没有扩展性可言了，如果某个queue负载很重，你加机器，新增的机器也包含了这个queue的所有数据，并没有办法线性扩展你的queue

12.mq的缺点

    系统可用性降低

    系统引入的外部依赖越多，越容易挂掉，本来你就是A系统调用BCD三个系统的接口就好了，人ABCD四个系统好好的，没啥问题，你偏加个MQ进来，万一MQ挂了咋整？MQ挂了，整套系统崩溃了，你不就完了么。

    系统复杂性提高：

    硬生生加个MQ进来，你怎么保证消息没有重复消费？怎么处理消息丢失的情况？怎么保证消息传递的顺序性？头大头大，问题一大堆，痛苦不已

    一致性问题：

    A系统处理完了直接返回成功了，人都以为你这个请求就成功了；但是问题是，要是BCD三个系统那里，BD两个系统写库成功了，结果C系统写库失败了，咋整？你这数据就不一致了。